[ANN] Bad conduct investigation

[Kohsuke Kawaguchi]

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, 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

[Slide]

Just out of curiosity, what are the possible outcomes of such an investigation?

--
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.
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.

[Kanstantsin Shautsou]

@Slide, they can block my jenkinsci account, github account and google groups. Not sure how i will be able continue development on some plugins that i wrote and maintain in such case.

@KK you publicly exposed this complain and my name. You want judge me with some unknown to me persons.  That’s why I’m answering why this happened also publicly.

> has repeatedly overstepped the threshold of what is generally accepted as being “good conduct” in an open-source community.

I know debian, gentoo and bit linux kernel community. This communities also has “if you screw up, take responsibility for your actions” and rules. I can say that some persons also overstepped them in jenkins (that caused such my reaction). 

Pre-history

I like FOSS and always trying to use it instead of closed-source SW. I started using Jenkins 4 ago and found that it has too many bugs, so decided to start improving it. I started from bug wrangling in JIRA, reading docs, started learning sources and finally started opening PRs with different fixes 3 years ago. I never had to many issues/bugs with any other SW and still sure that Jenkins has low quality. (I tired protecting Jenkins quality and it’s other issues on conferences when people asking why it impossible to do this or this in jenkins).

Timeline

* So what happened before April, i finally tired with ancient uncomfortable JIRA/Confluence and tried to help with INFRA. I have deep experience with linux, distros, administrating linux servers, automation (9 years for everything). Hardly get response from KK (or rtyler, don’t remember exactly) what to do and started puppetizing jira. https://github.com/jenkins-infra/jenkins-infra/pull/66 So, my summary about infra:

- it was locked on two persons, that had no time for this

- they think that it better to migrate to hosted solutions instead of supporting jenkins INFRA because they have no time for support and doesn’t want provide access to somebody else or change something.

- i hurt KK feelings with phrase that “jenkins infra sucks"

- after this KK reacted and it was possible to provide access to infra for new persons like Daniel B., Oleg N., @aheritier. Now this helps restarting services, but still no real work on infra enhancements (excluding finally updated JIRA).

- no INFRA work, just fill INFRA issues in JIRA to show how they are all not resolved.

* The second case is https://github.com/jenkinsci/parameterized-trigger-plugin/pull/83 i think i provided enough arguments in comments. Summary: experienced(?) dev didn’t followed existed rules and KK likes it. For me it just one more situation that leads to lower jenkins quality.

* Will try to not take personalities, but, please, think about it in general. KK points to this comment https://github.com/jenkinsci/build-pipeline-plugin/pull/81#issuecomment-139033384  and this https://github.com/jenkinsci/jenkins/pull/1815#issuecomment-137709017

CB joined people for jenkins development (that’s of course excellent). But it happens that nobody guiding them into existed jenkins rules. And they are trying to take maintainership https://groups.google.com/d/msg/jenkinsci-dev/NL2wLBjIV5A/gDv9UkCNCgAJ https://github.com/jenkinsci/build-pipeline-plugin/pull/81#issuecomment-139033384/https://groups.google.com/forum/#!searchin/jenkinsci-dev/recena/jenkinsci-dev/6Eqz7Z9QbNE/tMOt44t-AQAJ without following existed rules (seems can provide more links).

Btw Stephen C. describes very well how communication should work, but unfortunately it wasn’t followed.

* 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> 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 jenkinsci-board@googlegroups.com, 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-dev+unsubscribe@googlegroups.com.

[Manuel Jesús Recena Soto]

Hello Kanstantsin,

It seems you forgot other rude comments and behaviors, but anyway, you
are lying.

2015-09-26 23:42 GMT+02:00 Kanstantsin Shautsou <kanstan...@gmail.com>:
>
> @Slide, they can block my jenkinsci account, github account and google groups. Not sure how i will be able continue development on some plugins that i wrote and maintain in such case.
>
> @KK you publicly exposed this complain and my name. You want judge me with some unknown to me persons. That’s why I’m answering why this happened also publicly.
>
> > has repeatedly overstepped the threshold of what is generally accepted as being “good conduct” in an open-source community.
> I know debian, gentoo and bit linux kernel community. This communities also has “if you screw up, take responsibility for your actions” and rules. I can say that some persons also overstepped them in jenkins (that caused such my reaction).
>
> Pre-history
> I like FOSS and always trying to use it instead of closed-source SW. I started using Jenkins 4 ago and found that it has too many bugs, so decided to start improving it. I started from bug wrangling in JIRA, reading docs, started learning sources and finally started opening PRs with different fixes 3 years ago. I never had to many issues/bugs with any other SW and still sure that Jenkins has low quality. (I tired protecting Jenkins quality and it’s other issues on conferences when people asking why it impossible to do this or this in jenkins).
>
> Timeline
> * So what happened before April, i finally tired with ancient uncomfortable JIRA/Confluence and tried to help with INFRA. I have deep experience with linux, distros, administrating linux servers, automation (9 years for everything). Hardly get response from KK (or rtyler, don’t remember exactly) what to do and started puppetizing jira. https://github.com/jenkins-infra/jenkins-infra/pull/66 So, my summary about infra:
> - it was locked on two persons, that had no time for this
> - they think that it better to migrate to hosted solutions instead of supporting jenkins INFRA because they have no time for support and doesn’t want provide access to somebody else or change something.
> - i hurt KK feelings with phrase that “jenkins infra sucks"
> - after this KK reacted and it was possible to provide access to infra for new persons like Daniel B., Oleg N., @aheritier. Now this helps restarting services, but still no real work on infra enhancements (excluding finally updated JIRA).
> - no INFRA work, just fill INFRA issues in JIRA to show how they are all not resolved.
>
> * The second case is https://github.com/jenkinsci/parameterized-trigger-plugin/pull/83 i think i provided enough arguments in comments. Summary: experienced(?) dev didn’t followed existed rules and KK likes it. For me it just one more situation that leads to lower jenkins quality.
>
> * Will try to not take personalities, but, please, think about it in general. KK points to this comment https://github.com/jenkinsci/build-pipeline-plugin/pull/81#issuecomment-139033384 and this https://github.com/jenkinsci/jenkins/pull/1815#issuecomment-137709017
> CB joined people for jenkins development (that’s of course excellent). But it happens that nobody guiding them into existed jenkins rules. And they are trying to take maintainership https://groups.google.com/d/msg/jenkinsci-dev/NL2wLBjIV5A/gDv9UkCNCgAJ https://github.com/jenkinsci/build-pipeline-plugin/pull/81#issuecomment-139033384/https://groups.google.com/forum/#!searchin/jenkinsci-dev/recena/jenkinsci-dev/6Eqz7Z9QbNE/tMOt44t-AQAJ without following existed rules (seems can provide more links).
> Btw Stephen C. describes very well how communication should work, but unfortunately it wasn’t followed.
>

1) Here https://github.com/jenkinsci/build-pipeline-plugin/pull/81#issuecomment-139033384

you didn't provided any technical reason only noise.

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.

A) You constantly mention "following existed rules" but it seems are YOUR rules.

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.

Kanstantsin, I agree with you in a lot of things, but your comments
make me feel very uncomfortable.

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> 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, 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.

>>> 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.
> 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

[Kanstantsin Shautsou]

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?)

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.

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. 

[Manuel Jesús Recena Soto]

Hello Kanstantsin,

2015-09-27 14:06 GMT+02:00 Kanstantsin Shautsou <kanstan...@gmail.com>:
>>
>> 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,

> https://groups.google.com/d/msgid/jenkinsci-dev/c7f802f5-a695-46a9-a716-d24ea3dcb550%40googlegroups.com.

[Stephen Connolly]

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

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

[Manuel Jesús Recena Soto]

Hello Kanstantsin,

My apologies to use the term "to lie", it was the wrong word.

English is not my native language and I did not know that the meaning
was so strong.

As I said before, I agree with you in a lot of things and hope to meet

you soon and talk about this with some beers on the table.

Regards,

> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxFuoxHhQnEer3h0cPwcYhmVC4v52mZrfwVK3KVcSvu2Q%40mail.gmail.com.

[Baptiste Mathus]

Kanstantsin, my current feeling is that you talk a lot about technical issues here, when it's actually a human one.

In my mind, what Stephen says about Apache's way, specifically and paraphrasing "people >> code", is actually something fundamentally important in any OSS project (granted ymmv, but for one I wouldn't spend a minute in a project that values more code than behaviour).

Contrary to what you seem to think, the current subject has *nothing* to do with tech. 

Some people here gave and give a lot of time not only on code, and that is also a very important contribution [that can also give a bit more voice to decisions, just like code]. 

I was sometimes the witness and/or the target of such behaviour by you in the past.

Even if someone disagrees with some choices, that never will entitle that person to become offensive. And IMO even less in an OSS project where people do that on their free time.

To exaggerate and illustrate, even if people here decided to make Jenkins THE copy-paste driven development tool of the world, that still wouldn't allow anyone to be offensive. 

The right behaviour if someone disagrees with that could for example be to try and convince with respectful words it may not be the right way, and in the end fork if prooved to be impossible to change.

I voluntarily didn't provide too many links about your specific case, 'cause I hope you will understand the issue, back off and that subject will stop by itself.

And granted, you are sometimes right on what you're trying to push. But doing it the way you too often do is counterproductive.

-- Baptiste

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.

--

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Kohsuke Kawaguchi]

I'll re-iterate what I wrote in my original email. I should have repeated this a few times.

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, and we will pass them all on to the committee.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6XkFoHeDFMHQ4419S8w2ksqbWty-AU--Q8HMNsHeo22g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Kohsuke Kawaguchi

[Kanstantsin Shautsou]

On Sep 28, 2015, at 21:17, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:

I'll re-iterate what I wrote in my original email. I should have repeated this a few times.

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, and we will pass them all on to the committee.

I will repeat again, you exposed my name, without providing the full picture. If you want introduce a generic devrel/userrel/comrel team/feature in jenkins, then you should wrote such announcements in generic way “If somebody hurt/insult you, then please wrote to jenkinsci-board". Your write-only email style insults me. 

I usually very open and ok to get @recena, @stephenc and probably other people comments ;)

@stephenc GH allows blocking users https://help.github.com/articles/blocking-a-user/