I’ve noticed a few commits to the git repository over the last month from a number of contributors - mostly documentation and language files. This has been great, but it’s also highlighted a problem with how we manage access to the code.
Currently, anyone who can use the github issue tracker also has permission to commit to the code repository. This means that we have a lot of people who have commit access, and we have a growing number of people who would like to contribute code. We have a pretty rigorous review process to make sure that contributions don’t cause any issues, both for work within the core team and for contributions from the larger community. However, that review process relies on the contribution arriving in the right manner. Currently, anyone who has github issue access can, very easily and without intending it, bypass that review process and put code in OFN that we’re unaware of and potentially break it, or worse, introduce a subtle error that we don’t pick up for a long time.
I’d like to safeguard the review process and the code, and at the same time keep the contribution process was as simple as possible.
What I propose is that we split the issue tracker and the code into two separate github projects. The core development team would be given commit access to the code, and everyone involved would be given access to the issue tracker. People outside the core team would still be able to make code contributions, in the same way that code contributions are made to most open source projects on github - by forking the project and submitting a pull request. This will mean that the core dev team would be able to easily review and integrate those contributions.
Does anyone have any suggestions or objections to this proposal? I’m away on holiday for the next two weeks (until Thursday the 8th of October). Let me know your thoughts, and I’ll review everything and work out a way to take things forward when I return.
I must admit never seeing using two different repositories for code and tracking issues!
Do you see need that many people can close issues and assign labels to them, and just few push?
Another alternative could work by finding few people who would act as gardeners of the tracker, they would make sure not to push code directly to the repo themselves. Together with that, having a chatroom available could help everyone who doesn’t have write permissions to ask tracker gardeners to assign labels or close issues. One of obvious chat rooms: https://gitter.im/openfoodfoundation/openfoodnetwork
BTW I really like this article http://words.steveklabnik.com/how-to-be-an-open-source-gardener
I’d agree it would be a shame to lose the direct link between repo and issues. Could the gardener idea be tried for a bit? Also are there some current processes related to tagging and milestones that could be managed differently to reduce the number of people who need to change those things?
I talked it through with @oeoeaio and @maikel, we agree that it’d be a shame to lose the link between the repo and the issues. We’re thinking of moving towards something a bit like the gardener approach - we’d have a core team of developers, and then a small number of people who would have access exclusively for managing issues, who would agree not to commit code but would be welcome to submit code via fork+PR.
@pmackay, do you have an impression of how issues are managed at present and if this would have a small or large impact on the current workflow?
@elf-pavlik, a CONTRIBUTING.md is a great idea. I’ve added a simple one to get things started.
Let me know what you think and hopefully we’ll get something moving soon!
This month I hope to allocate one full day to dive into OFN issues tracker and get better understanding of those 170+ open issues. It will also come handy for the upcoming hackathon in Europe.
CONTRIBUTING.md looks good!
@elf-pavlik Sounds good! You might find the github issues easier to navigate using https://www.zenhub.io/ , which adds a bit more structure to how the issues are organised.
OK people, taking on board all the above, here’s our proposed github reshuffle . . can you let us know if this looks ok and we’ll make these changes next week.
Everything that Core Developers can do PLUS ability to add/remove users, change their permissions etc
Andrew Spinks (legacy and back-up)
Rohan Mitchell @RohanM
- Write access - can commit, manage pull requests from others etc
- Can manage issues
Issue Managers (‘gardeners’)
- Write access but only to be used for managing issues e.g. labels, milestones etc.
- Can assign other users (including Community users) to issues.
- Must be careful NOT to commit code other than through a pull request [see Contributing.md]
Community [Read only]
- Can create issues, comment and close their own issues (Issue Managers can assign them to issues)
- Can fork, work on code and submit pull requests, according to Community contribution process (outlined in contributing.md)
Everyone else, unless you want to make a case for why you need write access.
Couple of additional notes / questions:
- Is there anyone else managing issues for their country, instance etc that would need ‘Issue Manager’ level of access? @Selmo?
- We think the only active people who’d be moved from write to read access would be @Aidan @marito59 @mags @sigmundpetersen - let us know if you think this will be a problem
On my side, it is OK to just have read access (and it’s safer). I can manage issues assigned to me by my country issue manager (@MyriamBoure) and send Pull Request (as I did today) for changes I made.
Great! I’ve applied those permissions. Let me know if yourself or anyone is missing access that you need.
Hi (again) @RohanM,
Apparently the rights I have no longer allow me to publish a branch and create a PR. Can you please check that for me and upgrade accordingly ?
I have 2 PR related to translation (the one we discussed on delayed_job and another on emails I talked eralier with @maikel.
Pinging @MyriamBoure for information.
Hi @marito59, you have read access only to the openfoodnetwork repository. But you don’t need write access to open a pull request. You can fork the project on Github, push your branches to that fork and then open a pull request. Does that work for you?
OK, it works.
The only remaining point is that we can’t label the PR (nor issues), therefore we can’t highlight the context of the change.
@danielle I am on a slow transition moving back to France, so I will be less and less involved in the day-to-day operations in Norway (but will still be here whenever needed!), I will spend more time on the French instance. I’m wondering if that wouldn’t be good to have one “gardener” in Norway, to be able to manage labels and milestones for Norway… @sigmundpetersen could play that role.
What do you think?
Also that would be great to discuss about the label / milestones management, it seems it’s not so clear, not only for me https://github.com/openfoodfoundation/openfoodnetwork/issues/630
Currently, in France, we have created a fork in order to charge the changes we are making (mostly related to localisation).
One issue we are facing, is that, since we cannot manage issues in the root repository, we are creating issues in our own one.
Pros : we can manage our own issues and task assignements without bothering anyone else
Cons : we may be working on a similar issue without knowing.
Currently, our feeling is that the risk of work duplication is low, since we mostly work on localisation.
Let us know if it is OK for you. (pinging @MyriamBoure, @blancnic, @gnollet)
I think it’s a good idea to organise your own issues in your own fork. And duplication happens even within the same repository. It’s probably good if you watch the new issues in our repository so that you can detect duplicates.
Hey @MyriamBoure and @marito59
I was chatting to @pmackay about this today, and I think we need to come up with a labels and milestones solution in GitHub that works for everyone. This may mean backlogs for each instance, but a main release milestone that everyone can add issues to when contributing to the master code base.
This is something I’d like to kick off discussions about in the GO today, and to then start a Discourse discussion on with a wiki topic that we can all contribute to.
Separately to this though, I would recommend chatting to @NickWeir and @pmackay to understand how they manage their own backlog in GitHub.