[OH-Dev] Giving more people commit access

[Carol Willing]

Shauna,

I tend to be pretty conservative on pushing changes and believe that 
clean, well written code is a goal that developers should strive toward.

Let's see how it goes with one reviewer. It has essentially been one 
reviewer in the past plus Travis.

Code quality could improve with more committers since folks will likely 
gravitate to pull requests that meet their knowledge strengths.

I also prefer striving for quality code and responsive actions on issues 
and PRs over trying to prevent an error from getting pushed. 
Realistically, errors get pushed even with the best review process. If 
something merges and deploys that causes an issue, I think the 
likelihood of resolving quickly and recovering is higher when there are 
more people that understand the code base. I trust that people are 
trying to do their best to submit quality code. As a safe place for 
learning, I see us rallying as a team if there is a major code crisis of 
some sort.

As for individual guidelines on pushing a larger pull request (say 7 
files and/or greater than 500 lines changed), I guess a few strong 
recommendations might be good:
1. Please find someone (other than yourself) to review and merge your 
own Pull Request (unless there are extenuating circumstances ie site 
vandalism, security issue,...)
2. Try to find someone to pair review or also review large changes 
before merging

I will personally take the action item to do a monthly written update on 
oh-mainline pull requests and send it to this mailing list.

Carol

On 5/11/14, 5:27 PM, Shauna Gordon-McKeon wrote:
> Do we want to have multiple reviewers, or do you think that will slow 
> things down too much?  For instance, the first reviewer could leave a 
> comment approving (or gives feedback, and after that is incorporated 
> approves), and the second reviewer could merge.
>
>
> On Sun, May 11, 2014 at 8:24 PM, Asheesh Laroia <lists at asheesh.org 
> <mailto:lists at asheesh.org>> wrote:
>
>     Hey all,
>
>     I thought about it more, and I concluded that we should give more
>     people commit access to oh-mainline.
>
>     Here is my plan:
>
>     * If at least one person in the Login Team vouches for you, and
>     you have gotten
>     at least two pull requests merged into oh-mainline (anything in
>     oh-mainline, including docs), you will gain push access to the
>     oh-mainline repo.
>
>     * Login Team is defined here:
>     http://openhatch.readthedocs.org/en/latest/community/login_team.html
>
>     * I'll run a script every day
>     <https://github.com/openhatch/oh-pr-checker/blob/master/ok.py> to
>     see if I've fallen behind.
>
>     * I've given the following GitHub users push access:
>
>     *    Aaron1011
>     *    brittag
>     *    cpallares
>     *    eeshangarg
>     *    natea
>     *    onceuponatimeforever
>     *    pythonian4000
>     *    shaunagm
>     *    sunu
>     *    willingc
>
>
>     I also made a slight change to our branching -- there now exist
>     deployed_linode.openhatch.org
>     <http://deployed_linode.openhatch.org> and
>     deployed_linode2.openhatch.org
>     <http://deployed_linode2.openhatch.org> branches, which point at
>     the git repo on both those servers. That way, there is great
>     clarity about when someone merges some code, but it isn't yet
>     deployed.
>
>     Only the Login Team people will be able to deploy things, for now.
>     Hopefully we can get that fixed shortly.
>
>
>     If you're in the list of people I've added here, welcome aboard!
>     And if you're not yet, hopefully you will be.
>
>
>     Given the much more decentralized access, I'm hoping that people
>     will mostly follow the following guidelines:
>
>     * Submit your changes as a pull request, and get someone to review
>     them before merging them. Don't push your own changes directly
>     without review, unless there is some super pressing reason.
>
>     * Review other people's pull requests, and merge them if you are
>     happy with them, and take good care of licensing. (The docs do
>     talk about this already.)
>
>     * If you are reviewing people's docs changes, then the quality of
>     the submission is not as important as for code changes.
>
>     Having more committers maybe means I will start getting more code
>     review for my own changes, which would benefit everyone.
>
>     That's all I can think of, but I'm sure there's something else.
>
>     -- Asheesh.
>
>     _______________________________________________
>     Devel mailing list
>     Devel at lists.openhatch.org <mailto:Devel at lists.openhatch.org>
>     http://lists.openhatch.org/mailman/listinfo/devel
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/devel


-- 
Carol Willing
Developer
Willing Consulting

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/devel/attachments/20140511/930b644c/attachment.html>