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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Isn't this something that an RT queue would deal with better?

    --Nat

    • 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? (Score:2, Informative)

        by Skud (28) on 2002.01.08 23:28 (#2900) Homepage Journal
        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.
        --
        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
            • 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.
            • 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