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
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.
@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.
Administrators 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
Rob @oeoeaio
Maikel @maikel
Paul @pmackay
Core Developers - Write access - can commit, manage pull requests from others etc - Can manage issues
Lynne @lin_d_hop
Steve @stveep
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]
Kirsten @Kirsten
Sally @sstead
Danni @danielle
Nick @NickWeir
Myriam @MyriamBoure
Elf @elf-pavlik
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.
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.
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?
@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?
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.
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.
@danielle - here is the logic for who / what permissions on github re. your conversation with @NickWeir@lin_d_hop and @Sara. If you want to give a couple of extra people write access so that they can be Issue Managers / gardeners any of the admins can do it. Please then also update this post so we can easily keep track