Forum OpenACS Q&A: Re: Top Ten Priorities for OpenACS ... what are yours?

Collapse
Posted by Joel Aufrecht on
If you have thoughts on this, even if they are complete duplicates of
other lists, please post.  Newbies especially, please post.  My
purpose is to generate a sense of what people want urgently, and while
if we put it all together we get a wishlist, if we look at the
commonalities we get priorities.

Of course, the next question is how we execute on those priorities.
My sense is that there are two main ways that OpenACS development
occurs: either a paying client needs something incrementally advanced
from what the toolkit does, or one of the core volunteers dedicates a
few days of furious coding to knock off something.  While we can't
really make demands on our volunteer heroes, we can express the things
that we think are most urgent and most helpful.  I also would like to
see the core team identify some more avenues for work to get into the
code base.  One is code patches, which we've heard before haven't
always been picked up frequently enough for contributors to see
positive results.  Another is package maintainers, a process we
haven't managed to get working yet.  If people have suggestions, or
descriptions of what's working on other open-source projects, please
post.

Collapse
Posted by Roberto Mello on
I agree wholeheartedly with Don and Joel here.

About package maintainership perhaps what we need is to clearly define how to become a package maintainer, or cease to be one.

In the Debian project this is done through submitting bugs. When a Debian developer plans to package a piece of software s/he submits a bug called an ITP (Intent To Package).

When a developer wants to "orphan" a package s/he maintains that s/he no longer can/wants to maintain, s/he sends a "ITO" (Intent To Orphan) bug. When a developer wants to adopt an orphaned package, a (you guessed it) ITA (Intent To Adopt) bug is sent.

All the other developers see these actions. What we need are clear instructions on an easy-to-access place on how one can go about taking maintainership of a package and what that entails. Perhaps we could borrow some ideas from Debian in this regard.

That should probably go in the https://openacs.org/contribute/ page.

-Roberto