Abstract
This document describes an effective and standard way of letting less
experienced developers and contributors share parts of the workload of
the OCT and other Highly Experienced Developers (HEDs) within the
OpenACS community.
Specification
Persons, who are not members of the OCT, can volunteer to become an
OpenACS Worker Bee (OWB). An OWB accepts to be asked nicely and to the
point by members of the OCT, or persons appointed by them, to work on
a particular OpenACS related sub project within the limits of the
OWB's time, interests and abilities.
Each OWB will get an ETP instance or similar functionality on
openacs.org, where he or she can indicate activity level, interests
and relevant experience as needed. OCT members may search the list of
available OWBs when looking for currently active OWBs likely to be
able to do the subtask needed more or less independently of the OCT
member. Communication between the OCT member and the OWB is through
Email and will be short and to the point. The Emails should be
considered task progress handshaking and not social interaction, and
the subject line of those mails will include [OWB] to indicate as much.
When asked to do a particular subtask, an OWB may refuse
immediately and without stating a reason, though a brief explanation
is encouraged. Alternatively the OWB can accept the tasks proposed,
and is then expected to report back to the task submitter upon
completion, or when having to drop or give up doing the
task. The OWB may be subject to enquiry by the task submitter in order
to gauge progress.
This document does not make any proposals as to the decision
process behind each subtask on part of the OCT member or others. It
only specifies how others could be asked to do it, once the decision
has been made.
Reference Implementation
As an example consider an individual openacs.org user, NN, who
has been given CVS commit, and has volunteered to be an OWB. NN
indicates a willingness to help maintain the source tree through
application of patches and larger changes, like noquote, in the
individual packages needed to implement core architechture changes.
In some agreed upon way the OCT, or their representatives in the
form of package maintainers, decides that the patches X, Y, Z and W
should be applied, and mails NN:
(Subject) [OWB] Please apply these patches.
Hi NN,
Please apply patches X, Y, Z and W to HEAD (but not oacs-4-6).
Regards OCT Member.
to which NN replies
(Subject) Re: [OWB] Please apply these patches.
Hi OCT Member,
I cannot apply Z as it requires testing on an Oracle based setup which
I don't have access to, but I'll have a look at the others.
Regards NN.
and later
(Subject) Re: [OWB] Please apply these patches.
I have applied X and W to HEAD, but on a current checkout I was unable
to reproduce the problem, which Y was supposed to fix.
Regards NN.
OCT Member marks X and W as accepted in the Patch Collector upon
receiving the last mail. Etc.
Rationale
In the above example the benefits would include:
- Faster acceptance or rejection process for relevant patches,
encouraging people to submit more.
- Allow NN to contribute meaningfully to the development process,
according to his level of experience.
- Allow NN to work independently on existing code in the tree by
submitting patches, possibly with reference to a TIP, in the knowledge
that they would be accepted and applied or rejected fairly quickly,
allowing him to work in a progressive fashion even in situations,
where later patches relies on previous ones. All this without having
to borther OCT members or package maintainers directly.
- Lessen the workload on OCT members by allowing them to outsource
the application of the simpler and 'obviously correct' patches,
thereby giving them more time dedicated to the harder problems and
their own projects.
Similar benefits can be listed for other types of typical OWB tasks
like documentation writing, advocacy and more.
