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. >>> >> >> >> -- >> 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. >> >> >> -- >> 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. >> > > -- 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/fc6bbdbb-b4b6-4c06-9f35-7f0cbe798081%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
