-----BEGIN PGP SIGNED MESSAGE-----
Here are my initial thoughts on a process for code contributions (I use "code
contributions" to distinguish from testing/bug report/feature request type
Everything but very minor bugs should have a Jira issue created for them.
Before starting on an issue, email the dev list stating that you starting on
the issue and either state your plan for working (or just ask if anyone
already has a plan). Also, make sure to ask for feedback on your plans. I'm
not sure how to handle strong disagreements on how an issue should be
Issues probably shouldn't be worked on unless they are assigned to a version -
either as a bug fix for an already released version or as development on a
new version. So, if you want to work on an issue not assigned to a version,
ask about what version it should be added to. If you run across a very minor
bug, I think it is ok to fix it without having a Jira issue created for it.
To start with, we'll add all the issue's we have on our (NCSU) roadmap to Jira
and assign them to versions we've determined (at least as much as we've
assigned - there are many features we haven't assigned to versions yet).
After all of that is entered, we'll start a discussion about how the issues
have been assigned to see if people agree with how they've been split up and
adjust things accordingly.
After that initial step, as new issues get created and versions get released,
anyone on the list can suggest (via an email to the list) some issues that
could make up a new version. That list of issues can be vetted on the dev
list to come up with a new version. As development progresses, the set of
issues in the version can change accordingly.
So, share your thoughts on how you think this process should go. If you are
subscribed to this list with any intention of ever contributing, you should
at least say something - even if its just stating you agree with what someone
else said (just make it clear what you are agreeing with).
Once we have this process vetted, we need to create a wiki page containing the
process for reference to us and future members.
Also, please bear with us in trying to migrate our existing development
processes to ASF. There are three of us that have been developing this full
time (well, between meetings and administering our installation of it). Some
of that process is going to be along the lines of "this is what we had
planned - what do you think?". Unfortunately, we can't completely stop
development until all of the community driven processes are created. We'll
try to switch to them as fast as possible, but we do have a production
environment to keep moving along (and the beginning of a semester demanding
some features/fixes to happen ASAP).
Virtual Computing Lab (VCL)
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----