Re: Avoid privately-owned PRs

Hi

If we don't want to give write access to a lot of people an alternative 
approach is to use "Merging via command line" instructions from github 
and do the edits between step 1 and 2. When pushed, the PR is 
automatically marked as merged. That would let us to test the PR and do 
some polishing before the PR goes in.

The drawback would be that we can't do some changes and then pass the 
token over to the original contributor to add more stuff to the branch. 
But I don't know if that's a big problem since we're talking about small 
fixes before something goes in.

/Adam

On 2015-11-25 22:14, Bernard Aboba wrote:
> 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
>
> Hi,
>
> 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.
>
> Thoughts?
>
> Dom
>
>

Received on Thursday, 26 November 2015 10:06:12 UTC