[openspending-dev] Development process

Thu Mar 21 20:36:40 UTC 2013

Hey Tryggvi,

I like your ideas, and I agree with mostly all. I have just a few
suggestions:

   - Don't use feature branches by default. It's needed if you're working
   on something big that will break something else, or if you don't have
   commit access to the repository. But always rebase as often as possible,
   and merge back into master as soon as you have something useful. Or, even
   if you don't, merge if it's not something that will break anything else.
   The reasoning for this is to avoid having separate development tracks, and
   having merge issues (be it actual conflicts, or logic conflicts);
   - Even though I don't like feature branches, code reviews are awesome;
   - No meetings on weekends :P

Cheers,
Vítor.

2013/3/20 Tryggvi Björgvinsson <tryggvi.bjorgvinsson at okfn.org>

> 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
>
>
> _______________________________________________
> openspending-dev mailing list
> openspending-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/openspending-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/openspending-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending-dev/attachments/20130321/0e8e3e3e/attachment.html>