Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

use.perl.org

Perl

Dave Rolsky's

idea

More on Wishlist

Also by pudge

Moving modules@perl.org here

posted by pudge on 2002.01.08 8:58   Printer-friendly
Wishlist
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?"

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Moving modules@perl.org here 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Clarification, please (Score:5, Interesting)

    by ziggy (25) on 2002.01.08 9:20 (#2843) Journal
    Are you asking to:
    • move the mechanism by which namespace requests are submitted (use.perl slash plugin vs. modules@perl.org)?
    • increase the number of people who are responsible for responding to (and approving?) namespace requests? (the members of modules@perl.org can't really be blamed for being so busy)
    • make a fundemental change in the management of CPAN namespaces, including the switch to use perl and the increase of namespace monitors?

    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).

    • 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 compl
      • 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?
        • 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
          • 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?
            • 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...
          • 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.
  • Isn't this something that an RT queue would deal with better?

    --Nat

    • 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) ignore

      • 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.
    • 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 ... ;-)

      • 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 any

    • 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?
      • 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
        --
        Kirrily "Skud" Robert perl@infotrope.net http://infotrope.net/
        • 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
        • 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, d

          • 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?" --

            --

            -- 
            Esli epei eto cumprenan, shris soa Sfaha.
            Aettot ibrec epesecoth, spakhea scrifeteis.

            • 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
              • 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.

          • 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

            • 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. :-)

              • 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 :)

          • 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
            • 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 wa

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.