I think this is just fine, but I just noticed that its actually not so easy to see whether a comment is really coming from a CB developer or not. Most of the user ids used on GitHub are not associated to a CB email. Just because you add :bug: or :bee: to a comment know one knows if this is coming from a CB employee. I think many people will actually start to use these icons just because they have seen it on any jenkins PR and think it a common thing to do in this organisation. /Domi
On 02 Jul 2015, at 22:32, Stephen Connolly <[email protected]> wrote: > To give some background. > > I initially set up the reviewbybees GitHub account *for our closed source > repos only*... But people pick up habits and it crept out to OSS plugins > *because*: > > 1. it is easy to use > 2. It makes it easy to find pull requests using a query > 3. Other than the mention `@reviewbybees` it's low impact > > Very quickly though, you just get used to appending all your pull requests > with the tag. > > There are side-effects of the tag and our conducting internal review in the > open: > > 1. All those +1 votes can become intimidating to plugin maintainers. You have > a pull request who's direction you are not entirely happy with and a couple > of CloudBees people look to be saying: "super this should be a no brainer to > merge". That is not what our review is about. We want plugin maintainers to > retain control of their repositories. If they don't like a change, they > should be able and free to say so. Using +1/-1 for our own internal quality > process doesn't help... Hence the move to :bee: (it is review by bees after > all) and :bug: (I wanted :poo: but that proposal was rejected :-( ) > > 2. We could use the line a lot of other companies use, where we keep our > changes hidden on a private fork (so our review could be hidden) and only > push up once review is complete. The down side of that is that we would then > be building up larger units of change "in secret" and then landing them on > the plugin maintainer. It can be harder for a plugin maintainer to assert the > direction they want to follow if they are facing a big piece of work that has > just landed without notice at the door of your repo. Thus why we prefer to > work in the open and let the plugin maintainer shout "stop that's not the > direction I want" before we even finish our PR. I believe this is best for > the community. Additionally the comments in the code review can help the > plugin maintainer understand why we have gone for a specific design. Code > review in secret deprives the maintainer of that information. > > 3. Some of our employees will (initially) be strangers to the community. > Plugin maintainers should be given an explanation of why a bunch of strangers > are littering pull requests with :bee; and :bug: comments. So we have added > that a bit adds a comment explaining that we have a process and we are not > going to ask for it to be merged until our process is done - but plugin > maintainers can do whatever they want. > > 4. Some of us have two hats. I am a plugin maintainer for some plugins and > also a core committer. It may not be obvious when I am wearing each hat. To > help clarify we have the bot provide a formal request for the pull request to > be merged. Thus my actions after the review is complete can be more clearly > differentiated. The formal request, we also believe, is good to let plugin > maintainers know that our review is complete. > > In saying that, we don't want to antagonise the community. We want to do self > code review and we want plugin maintainers to be free to decide what > contributions they accept. We value community feedback, hence this thread. > > - Stephen > > On Thursday, July 2, 2015, Kanstantsin Shautsou <[email protected]> > wrote: > Was this discussed/allowed on some Jenkins meeting? > Can such actions be documented/allowed somewhere in Jenkins project > documentation? > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/69b68969-0436-40bd-a3cb-0e30424f6d12%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > > -- > Sent from my phone > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxanAQzOaSOPy68C3wB44xyiW4bEd5j5gdbXLXnfB7-iA%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/DDD148B3-BAD6-4187-84C0-3E8177C2DF33%40fortysix.ch. For more options, visit https://groups.google.com/d/optout.
