I don’t see why it is helpful to make intermediate work visible to plug-in authors, it creates a lot of unwanted noise. I think it would be sufficient that you make code reviews within your forked repository. When the review is successful you still can open a pull request for the original repository.
Ulli > Am 03.07.2015 um 16:39 schrieb Kanstantsin Shautsou > <[email protected]>: > > Is it possible not to post this description (spam) messages? If it rule for > CB employers, then you can send it to employers. If maintainer will decide > merge this, then he doesn't need to know CB processes. > > On Friday, July 3, 2015 at 5:31:53 PM UTC+3, Stephen Connolly wrote: > Yes, we have a bot that tracks that (but we are still working on refining how > the bot detects cloudbees users, so for now it doesn't. If we notice this > becoming a problem - which we will as the bot spams our hipchat instance with > nags, etc - we will switch to a hardcoded list of employees until we get a > better "automatic" solution) > > On 3 July 2015 at 15:04, domi <[email protected] <javascript:>> wrote: > 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] > <javascript:>> 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] >> <javascript:>> 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 >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/69b68969-0436-40bd-a3cb-0e30424f6d12%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout >> <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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxanAQzOaSOPy68C3wB44xyiW4bEd5j5gdbXLXnfB7-iA%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxanAQzOaSOPy68C3wB44xyiW4bEd5j5gdbXLXnfB7-iA%40mail.gmail.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout >> <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] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/DDD148B3-BAD6-4187-84C0-3E8177C2DF33%40fortysix.ch > > <https://groups.google.com/d/msgid/jenkinsci-dev/DDD148B3-BAD6-4187-84C0-3E8177C2DF33%40fortysix.ch?utm_medium=email&utm_source=footer>. > > For more options, visit https://groups.google.com/d/optout > <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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/fc6bbdbb-b4b6-4c06-9f35-7f0cbe798081%40googlegroups.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/fc6bbdbb-b4b6-4c06-9f35-7f0cbe798081%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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/3C857CDA-A511-4DDD-973E-400A30AE5409%40gmail.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Message signed with OpenPGP using GPGMail
