One follow-up:
There are two TLA that float around
CTR - commit then review
RTC - review then commit
for two styles of operation of a project
CTR is commit (to the main codebase) and have people check it afterwards
- a sort of passive agreement process. Jena is more this style. It
works for small projects when enough people can have an overview of the
whole thing; it's lighter weight, the level of analysis is typically
less but eyeballing changes is possible. Having a test suite is
essential, creating a off trunk version to check is not. It does not
work so well for large additions. It is short-timescale.
RTC is review (on JIRA or git pull requests), agree then integrate into
the main code base. Used on large projects (e.g. the Hadoops of this
world) where many areas can be active at once. It is higher overhead
but necessary when the complexity of the code base means things need to
be checked in detail, often by building and running e.g. performance.
It has a lot longer cycle time.
As a small project (and in the scheme of things, Jena is small) we can
choose lighter weight processes and also vary the process to suit on
each item. Small patches can be just do it, things that change
functionality can be brought to dev@. Your judgement.
Rob's excellent list applies.
We ought to be fairly systematic on asking for tests both for bug
reports and contributions. We seem to get waves of "it does not work
messages" and it takes inspired guesswork (well, random guesswork) to
see what might be going wrong.
Andy
