On 2013-02-01 20:15, Paul D. Anderson wrote:
Another consideration is the process for a package to become "standard".
Current practice is to implement a package and go through a review in
this forum. That's a good thing, but I'd like to see a more interactive
approach, where the community was involved sooner:
1. A package is proposed for future inclusion in the library. Presumably
this is done by someone with an interest in the subject, ideally this is
someone who wants to spearhead the effort and may already have a draft
implementation.
2. If there's enough interest to move forward, community members could
bicker about all the bikeshed stuff: structures, methods,
implementations, API, etc. until there's enough agreement about what the
result should look like.
3. Interested parties could collaborate on the implementation and release.
4. There would have to be time limits. Many (most?) D projects start
with a bang but then fizzle out before they're complete. There would
need to be (monthly?) progress reviews. If the discussion or the
implementation has dwindled, a reconsideration of the project could
occur. If unsuccessful, the project would be moved off the active list.
If there is renewed interest or if somebody else wants to take a crack
at it the previous work can be a resource, but the project should
probably go back to step 1.
You all see the problem with this: the very short attention span of the
D community. But we've got a good start between the DIP process and the
review queue. The only thing really different would be the progress
reviews, which would hopefully prevent projects falling of the end of
the earth.
This is just one possibility and there are probably better ways to do
this. But I think some sort of maintenance of active projects is needed.
Isn't this what the whole community is about and what we're already
doing. Just not very formal or official.
--
/Jacob Carlborg
