[openspending-dev] Development process

[Tryggvi Björgvinsson]

Hi,

So I'm going to propose a process for us (feel free to voice your
opinions). This is just a proposal, we have a working process now it
seems (Stefan deployed awesome features today) but I still want to
document how we work.

Here is my proposal:

On þri 12.mar 2013 21:46, Tryggvi Björgvinsson wrote:
> 1. What do I do if I want to contribute code?
>
> * Where do I find stuff to work on?
> * From what branch do I base my development?
> * How's the git workflow (merge vs. rebase)?
> * How to I submit my patch?
> * What do I do if the dev team does nothing with my patch?

You find stuff to work on in the issue tracker on github. You can choose
if you want to do volunteer-* marked issues (described below) or
something else -- everything is open to everyone. Feel free to let
people know if you want to work on something to avoid duplicate work.

Everything we work on must be in the issue tracker (if you want to work
on something that isn't there, just create a new issue and start hacking).

New development should be based on the master branch (which should
always be rebased) and hackers create a new feature branch in their own
repo. They can do a pull request if they feel their code is good, add a
comment to the issue and/or let the dev community know on the dev
mailing list. If nothing happens, continue to bug the devs on the dev
mailing list or on our IRC channel (#openspending on freenode) before
talking to core developers personally (which should be last resort).

> 2. What does the dev team do with contributions?
>
> * How do we manage our todo list (our issue tracker)?
> * How's the patch reviewed?
> * How's the patch tested?
> * How's the patch merged?
> * How's the patch deployed?

We try to label our issues as descriptively as possible, at minimum we
distinguish bugs and feature requests. For special interest topics we
create labels for those (but try to keep them to a minimum). We also
keep a list of help needed from contributors through labels
volunteer-advanced, volunteer-hard, and volunteer-simple.

When a pull request, or a patch, is submitted it should always be
reviewed by another dev than the one who submitted it. For feature
request issues being resolved/closed a test must be included with the
pull request/patch. After a green light from the reviewer either the
reviewer, the submitter or anybody else can deploy it.

Deployment is done by updating the translations (we merge translations
that have reached 100%) and after that push to the staging server and
test it there (against our regression tests, plus a look at the
individual features being deployed wouldn't hurt).

If there are new/changed strings that require translations the project
should be updated on transifex and the dev mailing list notified of new
translations (these need not be ready for deployment on production but
it would be good to try to get at least some translations before
deploying -- just don't wait too long, 1 or 2 days should suffice).
Translations that come in later can be deployed when ready (just ask for
inclusion on the dev mailing list).

When everything looks good, deploy to production and notify the dev
mailing list (everybody is probably subscribed to the changes made to
the repo on github but this is about when things are deployed to
production/staging.

> 3. How can everybody be updated on the focus of OpenSpending?
>
> * What tools do we use for communications?
> * How do we decide on our roadmap?
> * Should we have regular dev meetings?
> * Should we try to do regular dev blog posts (e.g. based on the dev
> meetings)?

I propose we _mainly_ use the good ol' dev communications tools: the dev
mailing list and the IRC channel (#openspending on freenode).

When discussing individual features we can do that on github (via the
commenting system there) but if we want a wider discussion (input from
the dev community) we raise the issue on the dev mailing list and point
to the discussion in the github comments (we can also try to get a
quicker feedback on the IRC channel). Everything on the mailing lists is
archived.

Our IRC channel is for synchronous communication and quick
help/slacking/having fun. In addition I propose we have monthly dev
meetings on IRC which are logged (where to put the logs?). I say we have
these meetings the first Saturday of every month at 14:00 UTC (I know
not everybody will be able to join at that time so feel free to suggest
another time).

These meetings should be only an hour long and we need to set an agenda
for each one. At these meetings we update our roadmaps so that should
always be on the agenda.

I don't think we have to do regular dev blog posts (but I like the
planet set up where we aggregate via RSS (ala planet.gnome.org and
planet.ubuntu.com etc.) -- is anybody blogging semi-regularly about
OpenSpending?

This is only a proposal. If you have some better ideas (which you
probably have) feel free to add your ideas into the mix.

/Tryggvi