Manuel, Please try and remember that what is going on is a process. We do not know what the outcome of this process will be. I can see four immediate possibilities:
1. The committee may decide that there is nothing wrong with KS's behaviour. 2. The committee may decide that KS's behaviour is a bad habit that has built up over time and suggest some type of probationary period with treat of further sanctions if the habit isn't corrected 3. The committee may decide that KS's behaviour has been sufficiently bad to warrant some form of sanction (less than stripping of commit bit) 4. The committee may decide that KS's behanious has been so bad such that his commit bit would be reset) None of these actions would stop KS from creating PRs, commenting on PRs, responding to mail threads, etc. Perhaps there are some Github permissions that could be used to restrict those... or perhaps a bot with admin privilidges could run arround chasing after KS on the Github repos of JenkinsCI and deleting any new comments... but quite frankly I suspect that would be a form of abuse in and of itself and a very sad day for the community. So, unless KS "takes the hump" and decides that the Jenkins community is not for him, you are going to have to interact with KS going forward. Now some form of sanction could perhaps be viewed as a "right to shun"... again I would view that as a sad day for the community. My personal belief is that KS has a different understanding of how the community works and how the community should work than a significant portion of the community. Some bad habits have been ignored as cultural differences for a while due to technical ability and as a result the habits have slipped a bit to something less healthy. When I see you making acusations of lying I see that as adding more fuel to the fire rather than trying to find a way for everyone to co-exist peacfully and respectfully. Similarly I did not think that some people's resorting to swearing in PR comments was appropriate either... At the end of the day, if I were to see the Jenkins community being like one of the foundations, I would see it more closely aligned to the "community over code" ethos of the Apache foundation rather than any of the other foundations... When we look at "community over code" that really means that your technical ability can earn you the initial right to be heard, but you only retain that right if you respect the community. Some of the recent interactions I have seen with KS and others can seem more hostile to newcomers. My personal hope is that KS will see this as an chance to reset some of the less good habits that have crept into his communication style and he can then continue to be a healthy part of our community. Alternatives where KS ends up leaving this community seem - to me - to cast both KS and the community in a less positive light... I would prefer instead to try and see the best in everyone. -Stephen On Sunday, 27 September 2015, Manuel Jesús Recena Soto <rec...@gmail.com> wrote: > Hello Kanstantsin, > > 2015-09-27 14:06 GMT+02:00 Kanstantsin Shautsou <kanstantsin....@gmail.com > <javascript:;>>: > >> > >> 1) Here > >> > https://github.com/jenkinsci/build-pipeline-plugin/pull/81#issuecomment-139033384 > >> > >> you didn't provided any technical reason only noise. > > > > It contains description why i don't like this "solution" > >> > >> > >> 2) Here > >> > https://groups.google.com/forum/#!msg/jenkinsci-dev/NL2wLBjIV5A/gDv9UkCNCgAJ > >> > >> "Oleg is identifying very well recena errors in PRs." WHERE??? As > >> result of this, a bug was resolved. I asked to be maintainer because > >> the plugin was unmaintained. > > > > In env-inject. Plugin was maintained by Oleg. And i saw that commits and > PRs > > was very well reviewed by him. (see below) > >> > >> > >> A) You constantly mention "following existed rules" but it seems are > YOUR > >> rules. > > > > > > > https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document#GovernanceDocument-Makingchangestoexistingplugins > > Try to be courteous to existing developers by sending them heads-up and > > coordinating with them, but if they aren’t responding, don’t let that > block > > your progress. > > I really tired adding to CC maintainers and last committers to > > "maintainership request" emails. I think it rude providing access to > plugins > > without talking with maintainers. > > This is what happened in env-inject, subversion-plugin, build-pipeline, > > parametrized-trigger disk-usage email (btw her answer didn't get mail > list > > because i see her reply in my email?) > > Again, you are lying. > > >> > >> > >> B) You constantly mantion my participation in Subversion Plugin. What > >> is it your problem here? I try to help here in my spare tiem. You > >> should appreciate and value that a person wants to spend time in this > >> "no trend" plugin. > > > > You didn't get my real point. I have experience that ~ 8 from 10 > newcomers > > fails to do release right. As this one of the most used plugins my point > was > > to have somebody experienced to verify changes before release and support > > you until you will do some release cycles. Of course i'm very glad that > > somebody decided to fix this plugin. And i know how much efforts @schrist > > spent on it. > > @schrist is still working on Subversion Plugin when he can/want. And > we have told about this plugin several times. > > Again, negative comments. > > >> > >> > >> Kanstantsin, I agree with you in a lot of things, but your comments > >> make me feel very uncomfortable. > > > > Hope this answer will clear what i mean. > > I don't understand what you means. > > Regards, > > >> > >> > >> I hope to meet you soon and talk about this with some beers on the > table. > >> > >> Regards, > >> > >> > * One more situation. I’m working on docker-plugin enhancements (plus > >> > docker-java library), there is existed open for everybody plan > >> > https://github.com/jenkinsci/docker-plugin/issues/235. Nobody asked > or > >> > joined development. > >> > In the same time CloudBees releases numerous number of docker-plugins > >> > and makes different presentations on JUC. (Obviously, every company > should > >> > do PR with docker). > >> > > >> > * KK references to https://github.com/jenkinsci/jenkins/pull/1827 if > it > >> > not obvious, then i can say that i never tried to personally insult > >> > somebody. I operate with work and it’s quality and just want to see > Jenkins > >> > better. This is what i get from CB developer (comments in PR was > deleted by > >> > somebody): > >> > > >> > > >> > I always open to facts and arguments, feel free to blame my code or > >> > help make something better. > >> > > >> > What i can say today. > >> > I think i got good experience with seen how FOSS project transformed > to > >> > single vendor FOSS project. I want share statement that i got from KK > at > >> > meeting (this can be useful for any new comer) and what i see now: > >> > - "Project organised as bazaar”. So your free to do what ever you want > >> > (excluding when somebody decided to enforce his invented rules like: > 1) > >> > filtering plugins from Update Center, 2) enforcing everybody to not > use GH > >> > issues or wiki, etc.). Plus such > >> > - About 2). KK uses for UI improvement Trello and gogledocs. For me it > >> > proves fact that INFRA is not suitable for comfortable development. It > >> > abusively require from everybody things that you can’t follow > yourself. > >> > (This and this) > >> > - CloudBees developers always suggesting people to merge new plugins > >> > into existed to have better usability for end-users (and i also > suggesting > >> > the same), while they do tones of docker plugins. Where is logic? > >> > - Right now CloudBees hijacks features planned/existed in > docker-plugin > >> > by creating new and new docker-* plugins. (I’m not taking > personalities, > >> > plugin is written under CloudBees license headers and CB packages). > Is this > >> > how CB works with FOSS? Answer from “KK”: ~“project is organised in > such > >> > way, no problems”. > >> > - IMHO all hired jenkins devs not working on their plugins anymore > like > >> > before. Example: role-strategy-plugin that was well maintained by > Oleg is > >> > not really maintained now. (Oleg, didn’t i hurt you with such > message?) > >> > - According to comments CB employees using model that allows them to > do > >> > merges in plugins where they are maintainers without reviews and > during > >> > working day only with reviews. Nice hole to merge anything you want > and > >> > nobody can follow what work and where happens, because nobody uses > company > >> > emails. As experiment i grepped logs for @cloudbees.com and found > that CB > >> > contribution into jenkins measured only by Jesse Glick commits ;) > >> > - KK wants join more developers. My eyes blows when i open remoting, > >> > core code or some plugins: most plugins is stupid copy-paste, @jglick > >> > personally invented annotation styling (in the same time i very > respect his > >> > experience), mess of letters without any spaces or brackets produced > by KK > >> > and all this continue be copy-pasted to other places. How can I add > workflow > >> > support in plugin when it impossible to follow changes or read this > monster > >> > code? Commit history in core was more clear and clean 1 year ago. I > tried > >> > join new developers into plugins and they run away with not polite > words. > >> > - Company that says everybody how to do CI/CD and integrate code > >> > analysers, not using them in newly created plugins. In old plugins > coding > >> > style can’t be touched because (?) it should stay for centuries with > mixed > >> > tabs and spaces, and in new …? What impression do you expect from > >> > new-comers? > >> > - If plugin has some number of open PRs, and has no maintainer, and > one > >> > company wants merge something they do it. Such approach kills > previously > >> > opened from FOSS people PRs and real maintaining is not happening. If > you > >> > work under plugin according to some plan and @reviewbybees PR > appears, you > >> > will be forced to switch and merge it either they will annoy every > day with > >> > questions when will it be merged (like “Zombie vs Plants”). > >> > - And of course there is a big cultural difference. If you want to see > >> > the insult, you will see it everywhere instead of resolving technical > >> > moments. > >> > > >> > > >> > On Friday, September 25, 2015 at 3:27:20 AM UTC+3, slide wrote: > >> >> > >> >> Just out of curiosity, what are the possible outcomes of such an > >> >> investigation? > >> >> > >> >> > >> >> On Thu, Sep 24, 2015, 17:02 Kohsuke Kawaguchi <k...@kohsuke.org > <javascript:;>> wrote: > >> >>> > >> >>> > >> >>> We have received complaints from multiple people that the conduct of > >> >>> Kanstantsin Shautsou (also known in the community as “KostyaSha”) > has > >> >>> repeatedly overstepped the threshold of what is generally accepted > as being > >> >>> “good conduct” in an open-source community. > >> >>> > >> >>> I have personally witnessed some of them as they have happened for > >> >>> more than half a year, and a number of people, including myself, > had private > >> >>> conversations with him about the matter. As additional complaints > have come > >> >>> in despite all those efforts, the board feels we have no options > but to > >> >>> formally launch an investigation to look into this. We are > approaching > >> >>> several prominent contributors in the community to join us to form a > >> >>> committee in order to look into this from all angles. Once we > receive > >> >>> confirmations from them, we will share their names. > >> >>> > >> >>> While we have not formally adopted any code of conduct, our > governance > >> >>> document does lay out the vision of the community we thrive to be. > This > >> >>> project derives a lot of power from constant influx of > contributors, and > >> >>> maintaining a healthy and respectful environment is of utmost > importance. > >> >>> > >> >>> The board will refrain from going into the details of the matter in > a > >> >>> public forum to avoid a public circus, and the committee will not > publicly > >> >>> discuss the matter for the same reason. If you have inputs to the > matter, > >> >>> please send them to jenkins...@googlegroups.com <javascript:;>, > and we will pass them all > >> >>> on to the committee. > >> >>> > >> >>> I’m hoping that the committee will come to a resolution in a week or > >> >>> so. We’ll publish the resolution when it concludes. > >> >>> > >> >>> I do not take a step like this lightly, and I do this with a heavy > >> >>> heart. However, given the duration in which this has been going on, > the > >> >>> number of people impacted, and the failed attempts to resolve this > issue > >> >>> less formally, I feel it is a duty of the board to act on the > situation. > >> >>> > >> >>> The situation also shows that the project needs to formally bless a > >> >>> code of conduct. I’m going to work with Daniel Beck to propose one > for us, > >> >>> and we will take it to the developers mailing list and project > meeting for > >> >>> the discussion. > >> >>> > >> >>> -- > >> >>> Kohsuke Kawaguchi > >> >>> > >> >>> -- > >> >>> 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 jenkinsci-de...@googlegroups.com <javascript:;>. > >> >>> To view this discussion on the web visit > >> >>> > https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4z_X-Jcpvxz_%3DVV085XKJNZhodREf1tZPHT-3Ge_wEEUA%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 jenkinsci-de...@googlegroups.com <javascript:;>. > >> > To view this discussion on the web visit > >> > > https://groups.google.com/d/msgid/jenkinsci-dev/aed320c9-6e6e-4062-b334-729b27652083%40googlegroups.com > . > >> > > >> > For more options, visit https://groups.google.com/d/optout. > >> > >> > >> > >> > >> -- > >> Manuel Recena Soto > >> * manuelrecena.com [/blog] > >> * linkedin.com/in/recena > > > > -- > > 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 jenkinsci-dev+unsubscr...@googlegroups.com <javascript:;>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/jenkinsci-dev/c7f802f5-a695-46a9-a716-d24ea3dcb550%40googlegroups.com > . > > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Manuel Recena Soto > * manuelrecena.com [/blog] > * linkedin.com/in/recena > > -- > 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 jenkinsci-dev+unsubscr...@googlegroups.com <javascript:;>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CABa-UofmDj7VixDeNaxw-grBnW7yTQvS71_UFGMfSvpTbXaYxA%40mail.gmail.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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxFuoxHhQnEer3h0cPwcYhmVC4v52mZrfwVK3KVcSvu2Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
