Matts writes "Following up on Dave Rolsky's idea to have book reviews here (or somewhere), what about having modules@perl.org become a channel on use.perl? People complain all the time about the lack of response from modules@perl.org, but that's simply because there aren't enough people on that list to contribute significant resources (the members of modules@perl.org can't really be blamed for being so busy). I think moving it to use.perl would ease some of that by distributing the work to those who have enough spare time to log on and read the requests for new module namespaces.
What do you think?"
I really don't care which goal you have in mind. What I really care about is that this doesn't get mired down into the same old "it's broken"/"no it isn't" type of discussion between frustrated users and status quo. Especially if it's going to span multiple fora (modules@perl.org, p5p, useperl, etc.).
Ideally this is the kind of thing that could be discussed at an annual p5p f2f. However, if we take that approach, we'll be setting ourselves up for a 36 hour meeting about issues impacting the community, about 3 hours of which may actually deal with the stewardship of the perl sources (the true meaning of the p5p f2f).
Re:Clarification, please
Matts on 2002-01-08T14:50:35
Well what I really meant to do was raise some discussion about it:-)
I think number two is the most important thing. People are pointed at modules@perl.org to get ideas for what to name their modules. But for example if an XML person went there with a request, it would fall on deaf ears because I don't think there are many (any?) xml experts on that list.
Once a community has discussed naming, then it might need to feed back into a more formal mechanism to get onto the modules list. But most of the complaints are about timely feedback, not actually getting onto that list.Re:Clarification, please
Thomas on 2002-01-08T15:59:00
I'm wondering if this would create overhead for pudge/other submitters as someone needs to approve the topics that go into a channel? Or am I misunderstanding something?Re:Clarification, please
Matts on 2002-01-08T17:02:23
Yes, but it would be fairly easy to add a few moderators. I mean, slashdot copes with thousands of submissions a day - I'm sure we wouldn't have more than 30 or so, which is about the current daily traffic on modules@perl.org (and they would still have to deal with new user and pauseid requests). And quite a few of that 30 or so is replies. So thinking along the lines of 10 module requests a day, it's not too much work to see which are valid module requests and approve the story... But then I wouldn't want to say it's no work at all and expect pudge to have to remain sole maintainer of the site. You need to scale it somehow.Re:Clarification, please
Thomas on 2002-01-08T18:15:38
True, and it seems like a good idea. At least to get some discussion going. I for one would like to see more stuff happening here on use perl.
But I wonder if PerlMonks would be a better forum for this? (I don't frequent PerlMonks though). Thoughts?Re:Clarification, please
Matts on 2002-01-08T20:14:11
I don't know about PerlMonks. I find their user interface confusing. I get lost every time I go there, and there are no breadcrumbs to let me find my way back out...Re:Clarification, please
pudge on 2002-01-08T19:01:01
The idea is that whoever wanted to do this would have to come up with a plan for how it would work (the same as the books.perl.org thing), and then we could discuss details. The simple answer is "yes, it can be done." Details will get worked out as we go along.
--Nat
Re:use.perl? Or RT?
ziggy on 2002-01-08T18:32:05
I'll ask you the same question I asked Matt: are you trying to fix the mechanics of the modules list, or the nature of the modules list?RT does seem to be a better way to get improved response throughput from the current or an expanded list of CPAN maintainers. But it sounds like it would also fundementally change the "deafening silence implies approval" nature of the modules list. My expectation from using RT or something similar would be that every request get an action of some sort: (actively) ignored, approved, rejected-for-cause, rejected-for-spam, etc.
The merit of the deafening silence behavior is left as an exercise to the reader.
:-) Re:use.perl? Or RT?
autarch on 2002-01-08T18:49:54
Since it often takes a month or so to get a _negative_ response, the whole deafening silence bit is useless. If negative responses usually took 3-5 days or so, that'd be different.Re:use.perl? Or RT?
pudge on 2002-01-08T19:08:46
I have not used RT much, but just so you know I am not the Borg here, while I think the books thing is a natural for use Perl / Slash, I think a real tracking system is probably what modules@ needs.
Of course, we could write a tracking system plugin for Slash... ;-) Re:use.perl? Or RT?
BooK on 2002-01-09T10:07:44
What's an RT queue? Request Tracking?
I'd say a low-tech solution like email is good, since you don't need much bandwidth to send and receive email. Compare with a more or less up to date browser for a web site, with yet another login/pass pair, and so on. I also agree that web interfaces tend to confuse people. Whereas email can be automatically filtered into various folders (PAUSEID request, module discussion, etc.), and processed offline by a human being.
Plus, keeping the email address doesn't break anything. You just have to change the deafening silence behavior into something different.
Naturally, an email interface doesn't forbid the use of advanced tools: procmail to manage a folder of requests/discussions, a web interface for the tracking system, and so on.
Re:use.perl? Or RT?
Matts on 2002-01-08T20:15:17
RT would help things like PAUSEID requests, and requesting to add a module to the module list. But I can't see how it would increase discussion about the naming of a module. Maybe you could detail how that would work with RT?Re:use.perl? Or RT?
Skud on 2002-01-09T04:28:33
I'm a member of modules@perl.org, albeit just as busy as the rest, and just as guilty of getting lagged in responding to posts.
I am a proponent of the RT idea, because it would help me (and probably others) to log into one place and see "HERE are the requests that have been waiting in line longest without a response." As it is at the moment, I would tend to respond to the most recent requests because I can't figure out whether the older ones have been dealt with or not.
Currently the only way to track a request from conception to resolution is by the use of a threaded mail client, and that doesn't even work half the time because mails are sent with no Reply-to by the automated bits of PAUSE that actually do the work. There's no easy way to link a discussion about the merits of a namespace application with its eventual approval and processing, other than by manually noting that the same module name appears in two unrelated emails.
Anyway, RT IMO would be a great thing. I'd love to have it, and I think it would help somewhat with the m@p.o backlog issue. I'm not going to get into the argument of whether m@p.o as the Right Thing For Perl or not, though;)
K.Re:use.perl? Or RT?
jns on 2002-01-09T10:01:26
I'd vote for RT too. I think this and an increase in the number of people involved in the modules@perl.org effort would probably help this thing flow better. I would be quite happy to help despite being as busy as everyone else:)
Another suggestion I would like to make here would be the introduction of a more automated mechanism for introducing existing modules into the module list by their authors - that is to say that alongside the tool to edit the existing entries there could be a list of modules that have been uploaded by the author and not entered on the module list - again I would be quite happy to help with this in some capacity...
/J\Re:use.perl? Or RT?
Tim Bunce on 2002-01-09T11:35:53
I agree that RT would probably be a good idea. At least worth trying.
I also think that splitting out the multiple roles of the modules@perl.org list into several module-foo@perl.org lists might be a good idea.
To those who ask about why "slience means approval" with regard to module naming... it's effectively a veto system.
Module naming can be a very subtle issue. It requires judgement that typically comes from many years experience.
Just because five people can't see any problem with a module name, doesn't mean that the sixth person won't spot a problem later (a problem that the others generally agree with once spotted).
If one of the first five people had approved it then it would be too late (to do without causing upset).
This is also the reason why 'throwing people at the problem' won't help. We need people with the right depth of experience and understanding of the issues.
To automate this would probably need some kind of voting system where at least N people need to have voted for a module name and none objected. I'm not sure if RT would support that concept directly but it could probably be extended to do so.
Tim.Re:use.perl? Or RT?
pne on 2002-01-09T14:16:42
Module naming can be a very subtle issue. It requires judgement that typically comes from many years experience.
[...]
This is also the reason why 'throwing people at the problem' won't help. We need people with the right depth of experience and understanding of the issues.
I confess that I, too, have been frustrated by the "deafening silence" aspect of modules@perl.org (especially when it comes to things which don't need approval but rather guidance -- as in "which name should I use, X or Y?" -- or action -- as in "please add module X to the official module list"). However, when I suggested to someone that modules@perl.org was a busy group of people and that joining might help, Tim wrote back with pretty much the above.
And after reading it, I can understand where he's coming from. Your average Perl developer may not be best qualified to judge which things merit a new namespace and which don't, or whether a module should go under A::B or X::Y::Z.
Apparently, it's also considered Good to have a good sense of historic knowledge about how things were decided in the past -- for example, which hierarchies are considered to be mistakes which should be left alone but under which no more modules should be registered. That sort of thing doesn't come from a set of self-selected "let's help the module people out" people.
Cheers,
Philip.Re:use.perl? Or RT?
Tim Bunce on 2002-01-09T15:49:11
Yes, I'd encourage people to read through the archives.
Here are some recent examples (click Thread Next at the top of each to follow the thread):
http://archive.develooper.com/modules%40perl.org/m sg08666.html
http://archive.develooper.com/modules%40perl.org/m sg09526.html
http://archive.develooper.com/modules%40perl.org/m sg09521.html
http://archive.develooper.com/modules%40perl.org/m sg08744.html
http://archive.develooper.com/modules%40perl.org/m sg08111.html
http://archive.develooper.com/modules%40perl.org/m sg04655.html
I suspect that few people understand the cumulative positive effects that the "Module List approval process" (for want of a better term) has had on the naming of modules over the many years it's been running. I think I first wrote the Module List in 1994 or maybe 1995.
Tim.
p.s. Either my browser or the use.perl.org code has a bug that's adding spurious space chars into the URLs above.Re:use.perl? Or RT?
pudge on 2002-01-09T15:57:26
It's not a bug. It is a feature to prevent abuse, because so many people on Slashdot will string together consecutive characters to mess up the width of a page. It doesn't affect tags (so HREF attribute values are fine), but it does affect HTML entities (that part is a bug indeed).
Call it a somewhat annoying feature.
What I should do, though, is lengthen the limit. It is 50 right now, which I think is too short. I'll see what I can do on that.Re:use.perl? Or RT?
hfb on 2002-01-09T15:43:40
I've been a cheerleader for RT since trying to get P5P to use it more than 2 years ago but...for modules@ it might be adding more complexity than it would really merit. Besides, just because you have a complex ticketing system in place doesn't mean that the problem of silence will be solved...it just means you'll have tickets instead of email.
What might be useful is splitting the list into 2; 1 for module-names@ for naming and 2 for module-accounts@ which would be all the administrative stuff for accounts. I could help with the account admin if Andreas would be agreeable to the suggestion which would then pare down the tedium a bit. As for the naming....patience is a virtue in our instant gratification culture and with the number of requests vs. the volume of them ticketing system or not it still requires a human to approve it. Adding more complexity to this won't really help solve the meat of the complaint which is time and silence.
Re:use.perl? Or RT?
pudge on 2002-01-09T15:52:46
Besides, just because you have a complex ticketing system in place doesn't mean that the problem of silence will be solved...it just means you'll have tickets instead of email.Yes, but it takes more effort to delete tickets than it does email.
:-) Re:use.perl? Or RT?
hfb on 2002-01-09T15:59:09
Right...so just like a Palm Pilot doesn't create more time in the day or make you more organised, RT isn't going to make issues easier to solve or any faster
:) Get a better MUA :) Re:use.perl? Or RT?
jhi on 2002-01-09T16:51:03
Being, like Tim, one of those people behind the "deafening silence", I thought to comment a bit, too. Mainly I'm just 120% in agreement with Tim, but maybe some further examples will help in understanding the issue. A ticketing system will help in account creation, module list surgery, things like that, but not in naming.
- First and foremost, people tend to take module naming very personally. They have toiled away their module in private for a long while, they *know* that their name is perfect, not many people take gladly in any critique. That's human nature, nothing wrong with that.
- People usually either overdo or underdo the naming: people often propose top-level (single-level) names based on a product/project name, often an acronym. Bad: people not knowing the name will never look at your module.
- Cutesy funny ha-ha name, recreational programming? Trust us, the joke will feel much less funny in a month.
- Sys:: and Text:: - bad for their awful non-descriptiveness.
- Trying to introduce modules based on a trademarked name? Unless you work for the trademark owner, please don't. You don't want a call from the lawyers, neither do we.
(Then again, lately I've been practically not reading the modules list at all, I've been *cough* otherwise occupied. Yes, I'm evil.)Re:use.perl? Or RT?
gbarr on 2002-01-09T19:56:20
OK OK, I will own up to being another of those people behind the "deafening silence". And I also completely agree with the comments from Tim and Jarkko.
I think a trial of using RT would be a worth while exercise, even if it did not work out.Re:use.perl? Or RT?
ask on 2002-01-10T05:40:30
You know where to write and we will configure a modules queue in the RT system and make some @perl.org address go there.:-)
- askModule Naming
2shortplanks on 2002-01-10T10:28:21
I don't take module naming personally, infact I came looking for advice from all sides about what to call a module, but I gave up on the whole effort. In the end it was easier for me to leave the module unreleased than try and find a module name that would fit in. It was just taking too long and in the end I couldn't be bothered - and more importantly by the time all this had transpired I had moved on to another project.I know this is my fault. My bad. I am evil. In fact, the last reply I received was a very helpful one from Skud, and I guess I should have done something about it, but I was tired of the whole affair, and I couldn't afford to spend any of my time working on the project. The company was donating my time on this, and I simply couldn't justify keeping dropping my current project to go back to it.
Before I go any further let me say that I don't think this is the module people's fault. My request was annoying, and hard to deal with. They do an outstanding job. If they can service 95% of the requests for help and let 5% slip then they're still better people than me. I just guess I'm trying to say that if we could find a mechanism for advice that could catch another couple of percentages that would be nice too.
Sorry if this sounds like a winge. It's not, honest. The important thing here is that this is all my fault. There are certainly things I should have done differently. Maybe in the end this is a winge - a winge that no-one has shouted back at me and told me where I'm going wrong, that I'm a doofus, and that I was going about it in the wrong way and wasting their time...
