GitHub permissions proposal

Hi @RohanM,

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

Cheers!

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 would also like to recommend adding CONTRIBUING.md to the repo

Hi everyone,

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.

1 Like

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.

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

No problem! Looks good :slight_smile:

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.

Cheers,
Rohan

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.

Thanks.

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 :wink: 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)

Ping @maikel and @RohanM

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 :relaxed:

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.

Cheers!

@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 :slight_smile: