Hi Dev's
I'm wondering how and if we want to organise write access to the main repository. IMHO it's not clear enough who is capable of merging code to the master branch. A "secret" IntelMQ-Contributors group exists on GitHub, nevertheless the members of this group do only have "read" access. For the sake of transparency such teams should be public and documented in the "Development Guidelines".
In addition, I think access to the Issue-Tracker is to limited. More people should be allowed to tag, assign, close, etc. issues. This would lower the workload of the "Core-Team". They could focus on things with other priorities.
I know that in GitHub it is not possible to differentiate between write-access to the Repo and Moderator-access to the tracker. All tracker-moderators would have write-access to the repo. Nevertheless, this differentiation could be achieved by a set of community-guidelines. We should discuss those on this list.
I think such guidelines are sufficient means of access control, as:
1) It's a distributed VCS, changes can be reverted.
2) Clearly communicate who is allowed to push to the repository and who is not and how to get Into the "privileged group". One could use GitHub-Teams to do that. For example and discussion: * IntelMQ-Core-Dev: List of beings allowed to push to the master * IntelMQ-Contributors: List of beings allowed to push to feature and development branches, if this granularity is required * IntelMQ-Mods: List of beings allowed to moderate the tracker and documentation, like the wiki, readmes, etc. * IntelMQ-Website: List of beings allowed to edit the Website Those groups must not be secret.
3) There could be rules like: If someone pushes to the repository who is not allowed to do it, tell him/her it was a misbehaviour and revert the changes. If it's an intentional misbehaviour and happens multiple times, discuss the Issue and revoke his/her write access.
Best Regards
Dustin
On 05 Jan 2017, at 11:51, Dustin Demuth dustin.demuth@intevation.de wrote:
Hi Dev's
I'm wondering how and if we want to organise write access to the main repository.
I definitely prefer the current model *for all of us* to send PRs and the core maintainers (mostly Sebix) has to go over the PRs and do some QA before merging them in.
It's really a matter of cleanliness and quality assurance.
That's what I want to ensure by this process.
Thanks, a.
-- // CERT Austria // L. Aaron Kaplan kaplan@cert.at // T: +43 1 505 64 16 78 // http://www.cert.at // Eine Initiative der nic.at GmbH // http://www.nic.at/ - Firmenbuchnummer 172568b, LG Salzburg
Hi Devs
I think Dustin's idea of having a list of the maintainers with write access would be very useful. Especially for someone who is new to the project it is good to know who will be able to merge the pull request. Currently, you kind of have to guess by looking at previous commits/issues.
I think keeping pull requests, regardless of whether more people will receive write access to the repository, is a good idea. PRs are a great way to do code review and get feedback from other contributors before merging a new feature. Just because you have write access to the repository does not mean that you can no longer make PRs.
As to having more maintainers it depends on the workload of the core maintainers. It would definitely be useful to have more than one person in case that person is on holidays or otherwise unavailable. Currently there are 13 open PRs and as far as I can tell there are a couple that can be merged and that I have been waiting for. However, not knowing who even has the rights to merge them makes it hard to know why they have not yet been merged.
If you/we trust the people enough to follow the community guidelines, then I think Dustin's suggestions are a good idea and might help speed up some of the processes (GitHub tells me that v1.0 Stable Release is already 2 months past due :)).
Cheers, Sybil
On 05/01/17 13:22, L. Aaron Kaplan wrote:
On 05 Jan 2017, at 11:51, Dustin Demuth dustin.demuth@intevation.de wrote:
Hi Dev's
I'm wondering how and if we want to organise write access to the main repository.
I definitely prefer the current model *for all of us* to send PRs and the core maintainers (mostly Sebix) has to go over the PRs and do some QA before merging them in.
It's really a matter of cleanliness and quality assurance.
That's what I want to ensure by this process.
Thanks, a.
-- // CERT Austria // L. Aaron Kaplan kaplan@cert.at // T: +43 1 505 64 16 78 // http://www.cert.at // Eine Initiative der nic.at GmbH // http://www.nic.at/ - Firmenbuchnummer 172568b, LG Salzburg
Intelmq-dev mailing list Intelmq-dev@lists.cert.at http://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev
Hi Team,
As Response to:
On 05/01/17 13:22, L. Aaron Kaplan wrote:
I definitely prefer the current model *for all of us* to send PRs and the core maintainers (mostly Sebix) has to go over the PRs and do some QA before merging them in.
It's really a matter of cleanliness and quality assurance.
and
Am Donnerstag 05 Januar 2017 18:40:03 schrieb Sybil Ehrensberger:
I think keeping pull requests, regardless of whether more people will receive write access to the repository, is a good idea. PRs are a great way to do code review and get feedback from other contributors before merging a new feature. Just because you have write access to the repository does not mean that you can no longer make PRs.
Just to clarify my thoughts here: I never intended to remove the PR's from the process. I also share the opinion that those are a good way contribute new code and to ensure a certain quality. In addition they give us the possibility to learn from each other.
Best Regards
Dustin