>>>>> On Sat, 14 Apr 2001 17:34:37 +0200, [EMAIL PROTECTED] (Johan Vromans) said:
jv> Hello Steve,
jv> [Quoting Steve Traugott, on April 13 2001, 22:46, in "PAUSE Process Change"]
>> Your expectations are sensible, I think, and I'd like to propose (or
>> maybe you've proposed but I haven't seen it?) that the documentation
>> be revised to match them.
jv> Yes, this, and some tactical web forms, would be a big help.
I've made some progress, expect a modules registration form these
days. A user registration form will follow as soon as the modules
registration form works. I figured that the modules registration form
is more urgent because the number of modules is larger than the number
of users and the data associated with them is also larger.
jv> What do we think would be the typical sequence of steps?
jv> 1. A user wants to share a Perl module.
jv> 2. Before sending the module to CPAN things like naming and API must
jv> be discussed. I think comp.lang.perl.modules should be used for
jv> this.
jv> 3. The user applies for a CPAN id.
jv> 4. To allow the people at c.l.p.m. access to the new module, it needs
jv> to be stored somewhere. CPAN would be great, but then we have a
jv> catch-22 situation.
I disagree, I do not see it as a catch 22. It's just that people
should be flexible in the early stages of developing a module. They
need to be open for a change of the namespace in the first months of
the lifecycle.
jv> 5. Upload and registration.
jv> The user registration form would be the first thing to revise. Andreas
jv> is already working out the possibility to make this process
jv> semi-automatic.
jv> I think that it is quite pointless to ask on the user registration
jv> form what the user wants to contribute. Often, this is interpreted as
jv> a request for module registration.
The tieing of user- and modules registration IMHO has the side effect
that people perceive user registration as something that needs to be
carefully considered. It has kept CPAN so much smaller than
sourceforge and perceived as higher quality. It's highly desirable
that we do not lose this.
jv> One way to overcome the catch-22 situation a possibility is to provide
jv> some kind of pre-registration. A pre-registration would reserve the
jv> module name for the user, but also have a timeout value (of several
jv> months, maybe). Preregistration would best be performed via a web form
jv> and in theory could be dealt with automatically. A separate modules
jv> list could be used to enumerate the 'tentative' registrations.
Maybe. But it sounds a bit overcomplicated. I always considered
uploading as some kind of pre-registration.
There are people who have a good proposal and a good grasp for a
namespace before submitting a module. They should be able to register
before uploading.
There are other people who need to write some code before they
understand what they are doing. They should be able to upload before
registering so that they can share their code in early stages.
For both clientels, CPAN always offered the right procedure, I think.
Due to the sheer number of developers and modules the process is now
cumbersome. The new forms must solve that.
jv> After some initial tries and testings the module would be officially
jv> registered and stored in the module lists. This, again, would be a web
jv> form but with a manual approvement (a one-click hyperlink of some
jv> sort).
jv> A nice side-effect is that modules in the 'idea' stage do not get
jv> into the modules list.
The idea stage was not a bad idea (sic!) per se. It just happened that
not all modules left the idea stage within a reasonable time. We could
probably deal with that by giving the idea stage a timeout of three
months or so. I'd like to keep the idea stage, it is good for those
people who prefer a stable namespace before writing the first line of
code.
>> > I think this would be a good requirement anyway: only register
>> > modules that have been uploaded and successfully unpacked and
>> > indexex (see the recent email exchange with the search.perl.org
>> > people).
>>
>> I think this is a good idea -- perhaps even have the unpacking and
>> indexing process trigger a default registration of some sort.
jv> Hmm. That would also be nice!
Yes, I imagined we would reach that stage with a new MakeMaker that is
able to write a .osd (open software description) file. I haven't given
up on the idea. But it is definitely something for "later".
jv> If we can agree on a revised procedure, we can update the docs.
Writing a form *is* already kind of updating the docs. The form gives
a lead, if you want it or not. Let's find out how well our
expectations for the form match so that we find the right wording for
them.
I'm not sure, for example, should we ask a separate question for
related modules and should we send the registration-request-email to
the authors of the related modules? OK, that's also left for "later".
--
andreas
