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.
  • by gnat (29) on 2002.01.08 13:10 (#2856) Journal
    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
            • 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