Forum OpenACS Q&A: Re: Top Ten Priorities for OpenACS ... what are yours?
Offhand, the only addition that quickly comes to mind is to continue our efforts to migrate more API stuff to Tcl to support rapid development. In the past few months we've implemented high-level, declarative approaches to ease the defining of service contracts, portlets and applets and there's a lot that could be done with the content repository that would make the writing of content packages much, much simpler than it is today.
I would like to see us define coding standards and to move existing packages towards using them. I'd love to see all forms created by the templating package, for instance, preferably using ad_form. We can do a lot to cut the learning curve that must be mastered before one can be productive using the toolkit.
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
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.