[openspending-dev] Development process

Fri Mar 22 02:29:12 UTC 2013

Hi Tryggvi

Thanks for kicking off this discussion. I agree with almost of your
suggestions except for the meeting on weekends bit :) Timezones are harder
to account for on weekends since it'll be at an awkward time for at least
someone and will kill their weekend :)

+1 on work being done entirely on feature branches. It would be nice to
note that "git rebase" is *never* a good idea once a branch has been pushed
to github. Everything commit on master needs to be a pull request and
reviewed by someone else, unless perhaps if it's a production emergency and
a fix *has* to go in.

While I like IRC as a medium and have used it for meetings, I've often
found that speaking makes a meeting faster than using IRC. So, if we can
make that a voice call instead, that'd be nice.

Nigel

On 21 March 2013 04:31, Tryggvi Björgvinsson
<tryggvi.bjorgvinsson at okfn.org>wrote:

> 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/20130322/c387a71c/attachment.html>