Only give write permission to per-repo teams

[daniel-beck]

Based on a discussion with KK.

[oleg-nenashev]

I would like to see more justification of the change, because the current statement is completely unclear to me and other contributors.

If it's related to the permission limitations... IMO we should distinguish "XXX Maintainers" and "XXX Developers" teams and teach IRC bot to assign people to proper groups. Maintainers should not be limited by "Write" permissions only, because several people manage labels, milestones, etc.

The existing Developer teams should be also streamlined

[oleg-nenashev]

:-1: for the current PR state. I think a wider discussion is required

[daniel-beck]

@oleg-nenashev According to the help everything needed for plugin maintenance, including use of labels, seems to be covered by the write permission (except possibly enabling issue tracker and wiki, and those I don't view as significant drawback).

[daniel-beck]

So the problem is that admin access to a team frequently gets abused. For example, people create repositories (say foo-plugin) in the jenkinsci org, that get assigned to the user's team (say, bar-plugin Developers) messing up permissions. Or the Everyone gets removed from collaborators (and while I don't like the Everyone group, changing this default isn't the solution here).

From the GitHub documentation it looks like everything that's actually needed is covered by Write access, so that's what I changed this to.

[lanwen]

Hook management is not covered by write permissions to add additional build tools

[oleg-nenashev]

Keeping :-1: till we improve the infra stuff for other cases (or for timely manual requests processing)

[KostyaSha]

All statistics is available only for admins. I already mentioned it in my complains to jenkins-board cc @rtyler :-1: for limiting developers on GH features.

[daniel-beck]

@oleg-nenashev @KostyaSha @lanwen So I assume you don't consider people deleting repositories to be a problem?

• https://github.com/jenkinsci/hp-quality-center-plugin
• https://issues.jenkins-ci.org/browse/HOSTING-54?focusedCommentId=253971&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253971

At least in this case it appears to have been accidental rather than deliberate. Another side effect of admin permissions for repositories…

[KostyaSha]

Of course not, force push could also wipe it. Hopefully it was scoped only to his plugin + GitHub contains RED banners in danger zone. @daniel-beck do you have any your own plugin to feel all support/infra pain? :)

[batmat]

I understand the need to have additional permissions for things like hooks and so on, but also that can lead to people inadvertently screwing up things. Example: https://issues.jenkins-ci.org/browse/HOSTING-54?focusedCommentId=253971&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253971

Now https://github.com/jenkinsci/hp-quality-center-plugin redirects to https://github.com/S73417H/hp-quality-center-plugin ...

Which is fine IMO for a user's namespace, but less for the jenkinsci org as we try to maintain some level of consistency (lacking for a better wording) :-(.

IMO, what we could indeed do is improving the irc-bot to handle such additional things like additional hook mgmt as @lanwen says.

[daniel-beck]

Of course not, force push could also wipe it.

Force pushes can be restored.

[KostyaSha]

Force pushes can be restored.

Via support requests until GC killed it. So you would say jenkinsci org has no infra for repository backups?

Based on a discussion with KK.

Person that doesn't maintain any plugin well. If you want really get feedback, then write directly to all maintainers or CC them to dev list, because most developers doesn't read maillist.

@bsideup one more plus for your hosting variant. Would think about creating migration instructions. (And yes in this case i would like request deleting initial repository from jenkinsci).

[bsideup]

@KostyaSha you mean https://github.com/jucies/releases ?

[daniel-beck]

IMO, what we could indeed do is improving the irc-bot to handle such additional things like additional hook mgmt as @lanwen says.

The question here is what to do until then? This stuff doesn't write itself.

---

@KostyaSha

do you have any your own plugin to feel all support/infra pain? :)

No, but even if I did, you'd just move the goal posts, as I have more access than you and can solve more problems on my own. That said, I don't recall a single actual request from you, besides maybe complaints about the tools we're using. As plugin hosting requests have shown, we're capable of timely request handling when done right.

So you would say jenkinsci org has no infra for repository backups?

Issues (you know, the thing you insist we let people use), wiki, etc. cannot be backed up other than a data dump that cannot be restored. Commits are easy to keep track of and make sure we have clones.

[daniel-beck]

because most developers doesn't read maillist.

It's a public mailing list known to contain governance topics. If they decide not to read that, or participate in project meetings, they need to live with the results. In that, it's like democracy.

[batmat]

All statistics is available only for admins.

You mean the Statistics API @KostyaSha ?

@daniel-beck do you have any your own plugin to feel all support/infra pain? :)

I have four. And the pain I feel here is the fact someone can inadvertently remove a plugin's source code from an organization. Organizations are about collaboration, so some shared rules to work together are not IMO very surprising. Any individual not willing to accept those can either help improve them, or experiment outside of that org. And this is something that's actually already existing as you know @KostyaSha

[KostyaSha]

Based on a discussion with KK.

that, it's like democracy.

participate in project meetings

That happens in time when even @stephenc can't be?

And this is something that's actually already existing as you know @KostyaSha

For collaborating - yes. But in style when you can host and do whatever you want with your plugin, you can reject any feature/etc requests when you are maintainer. Because you are sharing your work that may be useful to anybody. Nobody should block or limit you.

You mean the Statistics API @KostyaSha ?

Compare "statistics" tab with admin and without privs. (i.e. Info about what pages and how much people viewed).

Last year i do experiment and hosting 2 plugins fully at jenkinsci, 1 partially and would think about trying Juices. Corner case for me is pure PluginManagement (choosing dev/stable/experimental versions in terms of one repository with re-calculating dependencies to be sure that chosen combination would be installable).

cc @magnayn that usually also has interesting view points.

[daniel-beck]

That happens in time when even @stephenc can't be?

As almost all topics are discussed on the mailing list beforehand and/or afterwards, it's trivial to make your voice heard even when you cannot participate. And I doubt we'd ignore a thread popping up the next day saying "I saw this thing in the meeting minutes, and need to stop you from making a mistake". That said, I don't think it's ever come up.

And AFAIU not participating in the governance meeting is a deliberate choice for Stephen. It's 7 in the evening. Of course, it's more difficult for people from countries like India, China, and Australia, but I don't think we have any potential participants there (besides maybe Michael Neale). Any meeting time will not work for somebody, which is why we have the mailing list. See first paragraph.

[daniel-beck]

Based on a discussion with KK.

that, it's like democracy.

Nice quoting out of context. Note that I provided the full justification from that discussion as soon as someone asked. Also, it's a PR and still not merged.

[lanwen]

Have an idea: register bot-user for each repo and request auth token for this bot with all required scopes. Bot pwd will be only in org-admin hands. And token can be requested by maintainer. Token can have scopes to fetch statistics and manage hooks. But it cant be used to delete repo.

M?

[KostyaSha]

Sorry, but i'm human and need UI. KISS

[stephenc]

That happens in time when even @stephenc can't be?

And if there is something important coming up then I make sure that my view will be represented... there have even been cases where I have tasked the person with the opposing view of ensuring that they represent my view as a counter-position.

After that I leave it in the hands of the community to decide what to do.

If the above does not work, or if I do not think my views will be adequately represented, then I try and attend... but given that cooking some nice food to eat is more enjoyable than having a fight on IRC ;-)

[KostyaSha]

@stephenc i remember that words, but i remember also situations where very well discussed topics on dev list with total agreements was rejected by single 👑 person on IRC. That why i think it makes sense to have time when you and other people would be able discuss in time and not after.

[stephenc]

total agreements was rejected by single 👑 person on IRC

So IRC should be the rubber stamp of an agreement already decided in email. If it is not a rubber stamp then it should go back to email IMHO.

In that light if a single person rejects on IRC then that is a sign that the decision was not one ready for rubber stamping.

[oleg-nenashev]

As an IRCBot developer, I kindly ask to move the democracy-related off-topics to Jenkins Developers ML, CoC or even to the Human Rights Watch Forum.

Here we talk about the the pull request.

[daniel-beck]

New organization options make this restriction obsolete.

[KostyaSha]

New organization options make this restriction obsolete.

So what perms plugin author/maintainer will have for new plugin?

[daniel-beck]

@KostyaSha

So what perms plugin author/maintainer will have for new plugin?

The bot command has always made people repo admins (and nobody went in there afterwards on a regular basis to reduce them).