W3C home > Mailing lists > Public > public-webrtc-editors@w3.org > November 2015

RE: Avoid privately-owned PRs

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Wed, 25 Nov 2015 21:13:37 +0000
To: Dominique Hazael-Massieux <dom@w3.org>, "public-webrtc-editors@w3.org" <public-webrtc-editors@w3.org>
Message-ID: <BLUPR03MB1492F39E7845271B2CA3908EC050@BLUPR03MB149.namprd03.prod.outlook.com>
I am generally supportive of this direction (having lost write access to my own PRs on occasion, and having wanted to edit/rebase other PRs but not having access to do so).  

Is there a way for the Chairs/Editors to take some small steps in this direction (such as making it possible for us to edit each other's PRs) before expanding the scope? 

Lately I've stopped using my own private repo and started using the github website to create branches for each PR (which at least ensures that I can edit them, but may not give enough access to others).  

-----Original Message-----
From: Dominique Hazael-Massieux [mailto:dom@w3.org] 
Sent: Wednesday, November 25, 2015 8:48 AM
To: public-webrtc-editors@w3.org
Subject: Avoid privately-owned PRs


As discussed separately, there are a number of cases when we require a PR submitted to go back and fix typos and bugs in their PRs before they can be merged; while it isn't unreasonable, in cases where these changes are uncontroversial, it would be better to update the pull request itself directly.

This is not generally possible for pull requests that are submitted from privately owned because in general, only the owner has write access to that repository.

One way around that limitation would be to change how we use the shared @w3c repository:
* instead of limiting write access to the editors, we would give write access to all the "contributors" (i.e. people from which we expect or request PR)

* we would ask that these contributors instead of making pull requests from their private repo would instead push their changes as branch of the @w3c repo and pull request from there

* that way, any of the other contributor can help fix bugs and typos in these shared branches

* the only drawback is that contributors could mistakenly then push changes to master and gh-pages; but arguably, that's already a risk with editors, chairs and staff contacts, and in most cases, can easily be recovered from. This should probably push us to make these branches "protected" (i.e. not deletable or force-pushable), but that is true in any case.



Received on Wednesday, 25 November 2015 21:14:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:19:03 UTC