[Ksummit-discuss] TAB non-nomination

[Ksummit-discuss] TAB non-nomination

[James Bottomley]

Hi All,

Several people have asked me to stand again for election to the TAB, so
I thought I'd give a general explanation of why that isn't going to
happen.  For background: I was one of the people who lead the charge in
getting the Linux Foundation predecessor OSDL to create the TAB to give
developer input into what was then seen as a body trying to speak for
the Linux Kernel.  I was actually TAB chair for 8 years from 2006 to
2014.  The job of the TAB, as I saw it, was to solve a lot of the
political friction issues around the places where the Linux Kernel
community interfaces with the Linux Foundation and Industry and in
those 8 years I gained quite a lot of expertise in political relations
trying to do that.

However, TAB member and TAB chair aren't roles people are born to fill,
they're roles people have to grow into.  What our community needs is
more people willing to grow into these roles to ensure effective
succession and if I stepped into one I'd be denying others that
opportunity, which would be bad both for succession planning and the
growth of the community in general.

I think the reason I'm getting these requests is angst over this CoC
debate, so I'll go so far as to detail my political instincts over this
below ... if you've no interest in politics (as most of you won't have)
stop reading now.  If you are interested, perhaps you should consider
standing for the TAB yourself.

James

---

The biggest political mistake was actually doing anything with the
Linux Kernel CoC at all.  The object was to deflect a highly
unfavourable article in the New Yorker.  With hind sight, that could be
achieved simply by Linus' personal apology, statement that he was
stepping aside and going for assistance to understand others' emotions.

Hind sight, though is always perfect.  At the time, as a TAB member,
all you saw was a panic driven by both Linus and the Linux Foundation
that we needed an updated Kernel CoC ASAP, like today.  Panic is very
infectious so it can be extremely difficult in these circumstances to
stand up and say "stop, we need more information"  ... and if you think
you'd be the one always to demand more information remember that
there's a time a decision has to be made and it always passes before
you can get complete information, so you'd basically be rendering the
TAB indecisive and useless.  Recognising when it's time to stop and ask
for more data and when you have to make decisions with what you have is
a key political skill.

The second mistake was picking the wrong CoC.  I'm not talking about
the wording, which has been discussed on this list, but the politics
surrounding the choice:  The original author of the current CoC was
unsupportive to the point of attacking the kernel community in public. 
That drove a huge amount of me too attacks plus an equally large amount
of anti-me too hysteria and lead to enormous external awareness and
friction plus a not inconsiderable amount of unwelcome personal email
to various people.  This could largely have been avoided by either
evolving our existing CoC through a community process or by picking a
CoC whose original author would be willing to stand up and be
supportive of our desire to change.

The third mistake was dumping the fully formed CoC and a later update
into the tree with little to no community input which has generated a
lot of obvious anger within our community itself. All I'll say on this
is that revisiting the CoC is going to cause another huge cascade of
externally driven attacks which I think we'd all rather avoid, so if
you're still ticked, then perhaps you should channel that anger and
stand for the TAB ...

[Tech-board-discuss] TAB non-nomination

[James Bottomley]

Hi All,

Several people have asked me to stand again for election to the TAB, so
I thought I'd give a general explanation of why that isn't going to
happen.  For background: I was one of the people who lead the charge in
getting the Linux Foundation predecessor OSDL to create the TAB to give
developer input into what was then seen as a body trying to speak for
the Linux Kernel.  I was actually TAB chair for 8 years from 2006 to
2014.  The job of the TAB, as I saw it, was to solve a lot of the
political friction issues around the places where the Linux Kernel
community interfaces with the Linux Foundation and Industry and in
those 8 years I gained quite a lot of expertise in political relations
trying to do that.

However, TAB member and TAB chair aren't roles people are born to fill,
they're roles people have to grow into.  What our community needs is
more people willing to grow into these roles to ensure effective
succession and if I stepped into one I'd be denying others that
opportunity, which would be bad both for succession planning and the
growth of the community in general.

I think the reason I'm getting these requests is angst over this CoC
debate, so I'll go so far as to detail my political instincts over this
below ... if you've no interest in politics (as most of you won't have)
stop reading now.  If you are interested, perhaps you should consider
standing for the TAB yourself.

James

---

The biggest political mistake was actually doing anything with the
Linux Kernel CoC at all.  The object was to deflect a highly
unfavourable article in the New Yorker.  With hind sight, that could be
achieved simply by Linus' personal apology, statement that he was
stepping aside and going for assistance to understand others' emotions.

Hind sight, though is always perfect.  At the time, as a TAB member,
all you saw was a panic driven by both Linus and the Linux Foundation
that we needed an updated Kernel CoC ASAP, like today.  Panic is very
infectious so it can be extremely difficult in these circumstances to
stand up and say "stop, we need more information"  ... and if you think
you'd be the one always to demand more information remember that
there's a time a decision has to be made and it always passes before
you can get complete information, so you'd basically be rendering the
TAB indecisive and useless.  Recognising when it's time to stop and ask
for more data and when you have to make decisions with what you have is
a key political skill.

The second mistake was picking the wrong CoC.  I'm not talking about
the wording, which has been discussed on this list, but the politics
surrounding the choice:  The original author of the current CoC was
unsupportive to the point of attacking the kernel community in public. 
That drove a huge amount of me too attacks plus an equally large amount
of anti-me too hysteria and lead to enormous external awareness and
friction plus a not inconsiderable amount of unwelcome personal email
to various people.  This could largely have been avoided by either
evolving our existing CoC through a community process or by picking a
CoC whose original author would be willing to stand up and be
supportive of our desire to change.

The third mistake was dumping the fully formed CoC and a later update
into the tree with little to no community input which has generated a
lot of obvious anger within our community itself. All I'll say on this
is that revisiting the CoC is going to cause another huge cascade of
externally driven attacks which I think we'd all rather avoid, so if
you're still ticked, then perhaps you should channel that anger and
stand for the TAB ...

Re: [Ksummit-discuss] [Tech-board-discuss] TAB non-nomination

[Steven Rostedt]

On Thu, 08 Nov 2018 16:04:02 -0800
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> Hi All,
> 
> Several people have asked me to stand again for election to the TAB, so
> I thought I'd give a general explanation of why that isn't going to
> happen.  For background: I was one of the people who lead the charge in
> getting the Linux Foundation predecessor OSDL to create the TAB to give
> developer input into what was then seen as a body trying to speak for
> the Linux Kernel.  I was actually TAB chair for 8 years from 2006 to
> 2014.  The job of the TAB, as I saw it, was to solve a lot of the
> political friction issues around the places where the Linux Kernel
> community interfaces with the Linux Foundation and Industry and in
> those 8 years I gained quite a lot of expertise in political relations
> trying to do that.
> 
> However, TAB member and TAB chair aren't roles people are born to fill,
> they're roles people have to grow into.  What our community needs is
> more people willing to grow into these roles to ensure effective
> succession and if I stepped into one I'd be denying others that
> opportunity, which would be bad both for succession planning and the
> growth of the community in general.
> 
> I think the reason I'm getting these requests is angst over this CoC
> debate, so I'll go so far as to detail my political instincts over this
> below ... if you've no interest in politics (as most of you won't have)
> stop reading now.  If you are interested, perhaps you should consider
> standing for the TAB yourself.

If I understand this correctly, this is your way of telling those that
asked you to run for TAB that you are not doing so.

> 
> James
> 
> ---
> 
> The biggest political mistake was actually doing anything with the
> Linux Kernel CoC at all.  The object was to deflect a highly
> unfavourable article in the New Yorker.  With hind sight, that could be
> achieved simply by Linus' personal apology, statement that he was
> stepping aside and going for assistance to understand others' emotions.
> 
> Hind sight, though is always perfect.  At the time, as a TAB member,

Hind sight is actually far from perfect, because we really don't know
what would have happened if we did things differently.

-- Steve


> all you saw was a panic driven by both Linus and the Linux Foundation
> that we needed an updated Kernel CoC ASAP, like today.  Panic is very
> infectious so it can be extremely difficult in these circumstances to
> stand up and say "stop, we need more information"  ... and if you think
> you'd be the one always to demand more information remember that
> there's a time a decision has to be made and it always passes before
> you can get complete information, so you'd basically be rendering the
> TAB indecisive and useless.  Recognising when it's time to stop and ask
> for more data and when you have to make decisions with what you have is
> a key political skill.
> 
> The second mistake was picking the wrong CoC.  I'm not talking about
> the wording, which has been discussed on this list, but the politics
> surrounding the choice:  The original author of the current CoC was
> unsupportive to the point of attacking the kernel community in public. 
> That drove a huge amount of me too attacks plus an equally large amount
> of anti-me too hysteria and lead to enormous external awareness and
> friction plus a not inconsiderable amount of unwelcome personal email
> to various people.  This could largely have been avoided by either
> evolving our existing CoC through a community process or by picking a
> CoC whose original author would be willing to stand up and be
> supportive of our desire to change.
> 
> The third mistake was dumping the fully formed CoC and a later update
> into the tree with little to no community input which has generated a
> lot of obvious anger within our community itself. All I'll say on this
> is that revisiting the CoC is going to cause another huge cascade of
> externally driven attacks which I think we'd all rather avoid, so if
> you're still ticked, then perhaps you should channel that anger and
> stand for the TAB ...
> 
> _______________________________________________
> Tech-board-discuss mailing list
> Tech-board-discuss@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/tech-board-discuss

Re: [Tech-board-discuss] TAB non-nomination

[Steven Rostedt]

On Thu, 08 Nov 2018 16:04:02 -0800
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> Hi All,
> 
> Several people have asked me to stand again for election to the TAB, so
> I thought I'd give a general explanation of why that isn't going to
> happen.  For background: I was one of the people who lead the charge in
> getting the Linux Foundation predecessor OSDL to create the TAB to give
> developer input into what was then seen as a body trying to speak for
> the Linux Kernel.  I was actually TAB chair for 8 years from 2006 to
> 2014.  The job of the TAB, as I saw it, was to solve a lot of the
> political friction issues around the places where the Linux Kernel
> community interfaces with the Linux Foundation and Industry and in
> those 8 years I gained quite a lot of expertise in political relations
> trying to do that.
> 
> However, TAB member and TAB chair aren't roles people are born to fill,
> they're roles people have to grow into.  What our community needs is
> more people willing to grow into these roles to ensure effective
> succession and if I stepped into one I'd be denying others that
> opportunity, which would be bad both for succession planning and the
> growth of the community in general.
> 
> I think the reason I'm getting these requests is angst over this CoC
> debate, so I'll go so far as to detail my political instincts over this
> below ... if you've no interest in politics (as most of you won't have)
> stop reading now.  If you are interested, perhaps you should consider
> standing for the TAB yourself.

If I understand this correctly, this is your way of telling those that
asked you to run for TAB that you are not doing so.

> 
> James
> 
> ---
> 
> The biggest political mistake was actually doing anything with the
> Linux Kernel CoC at all.  The object was to deflect a highly
> unfavourable article in the New Yorker.  With hind sight, that could be
> achieved simply by Linus' personal apology, statement that he was
> stepping aside and going for assistance to understand others' emotions.
> 
> Hind sight, though is always perfect.  At the time, as a TAB member,

Hind sight is actually far from perfect, because we really don't know
what would have happened if we did things differently.

-- Steve


> all you saw was a panic driven by both Linus and the Linux Foundation
> that we needed an updated Kernel CoC ASAP, like today.  Panic is very
> infectious so it can be extremely difficult in these circumstances to
> stand up and say "stop, we need more information"  ... and if you think
> you'd be the one always to demand more information remember that
> there's a time a decision has to be made and it always passes before
> you can get complete information, so you'd basically be rendering the
> TAB indecisive and useless.  Recognising when it's time to stop and ask
> for more data and when you have to make decisions with what you have is
> a key political skill.
> 
> The second mistake was picking the wrong CoC.  I'm not talking about
> the wording, which has been discussed on this list, but the politics
> surrounding the choice:  The original author of the current CoC was
> unsupportive to the point of attacking the kernel community in public. 
> That drove a huge amount of me too attacks plus an equally large amount
> of anti-me too hysteria and lead to enormous external awareness and
> friction plus a not inconsiderable amount of unwelcome personal email
> to various people.  This could largely have been avoided by either
> evolving our existing CoC through a community process or by picking a
> CoC whose original author would be willing to stand up and be
> supportive of our desire to change.
> 
> The third mistake was dumping the fully formed CoC and a later update
> into the tree with little to no community input which has generated a
> lot of obvious anger within our community itself. All I'll say on this
> is that revisiting the CoC is going to cause another huge cascade of
> externally driven attacks which I think we'd all rather avoid, so if
> you're still ticked, then perhaps you should channel that anger and
> stand for the TAB ...
> 
> _______________________________________________
> Tech-board-discuss mailing list
> Tech-board-discuss@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/tech-board-discuss

Re: [Ksummit-discuss] TAB non-nomination

[Chris Mason]

On 8 Nov 2018, at 16:04, James Bottomley wrote:
>
> Hind sight, though is always perfect.  At the time, as a TAB member,
> all you saw was a panic driven by both Linus and the Linux Foundation
> that we needed an updated Kernel CoC ASAP, like today.

I think panic is the wrong word to attach to Linus' response, especially 
around the code of conduct.

>
> The second mistake was picking the wrong CoC. [ ... ]
>
> The third mistake was dumping the fully formed CoC and a later update
> into the tree with little to no community input

The update was entirely based on community input.

> which has generated a
> lot of obvious anger within our community itself.

It's absolutely true that some members of the community were upset.

We'll never know if there could have been a better time to make code of 
conduct changes.  There are a wide range of deeply held beliefs in this 
area, and every choice would have eventually led to major disagreements. 
  But what we do know is that everyone sat down and did their best to 
find compromise.  That doesn't mean we found the right compromise for 
every developer, but I still really appreciate how much time and energy 
everyone spent explaining their point of view and looking for common 
ground.

> All I'll say on this
> is that revisiting the CoC is going to cause another huge cascade of
> externally driven attacks which I think we'd all rather avoid, so if
> you're still ticked, then perhaps you should channel that anger and
> stand for the TAB ...
>

It's really important the TAB is full of people that care about the 
kernel.  Anger about the code of conduct isn't a great qualifier, but 
I'll happily encourage anyone who cares deeply about the kernel 
community, even if they disagree with my opinions about how to best 
support it.

-chris

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Chris Mason]

On 8 Nov 2018, at 16:04, James Bottomley wrote:
>
> Hind sight, though is always perfect.  At the time, as a TAB member,
> all you saw was a panic driven by both Linus and the Linux Foundation
> that we needed an updated Kernel CoC ASAP, like today.

I think panic is the wrong word to attach to Linus' response, especially 
around the code of conduct.

>
> The second mistake was picking the wrong CoC. [ ... ]
>
> The third mistake was dumping the fully formed CoC and a later update
> into the tree with little to no community input

The update was entirely based on community input.

> which has generated a
> lot of obvious anger within our community itself.

It's absolutely true that some members of the community were upset.

We'll never know if there could have been a better time to make code of 
conduct changes.  There are a wide range of deeply held beliefs in this 
area, and every choice would have eventually led to major disagreements. 
  But what we do know is that everyone sat down and did their best to 
find compromise.  That doesn't mean we found the right compromise for 
every developer, but I still really appreciate how much time and energy 
everyone spent explaining their point of view and looking for common 
ground.

> All I'll say on this
> is that revisiting the CoC is going to cause another huge cascade of
> externally driven attacks which I think we'd all rather avoid, so if
> you're still ticked, then perhaps you should channel that anger and
> stand for the TAB ...
>

It's really important the TAB is full of people that care about the 
kernel.  Anger about the code of conduct isn't a great qualifier, but 
I'll happily encourage anyone who cares deeply about the kernel 
community, even if they disagree with my opinions about how to best 
support it.

-chris

Re: [Ksummit-discuss] TAB non-nomination

[Stephen Hemminger]

On Thu, 08 Nov 2018 16:04:02 -0800
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> Hi All,
> 
> Several people have asked me to stand again for election to the TAB, so
> I thought I'd give a general explanation of why that isn't going to
> happen.  For background: I was one of the people who lead the charge in
> getting the Linux Foundation predecessor OSDL to create the TAB to give
> developer input into what was then seen as a body trying to speak for
> the Linux Kernel.  I was actually TAB chair for 8 years from 2006 to
> 2014.  The job of the TAB, as I saw it, was to solve a lot of the
> political friction issues around the places where the Linux Kernel
> community interfaces with the Linux Foundation and Industry and in
> those 8 years I gained quite a lot of expertise in political relations
> trying to do that.
> 
> However, TAB member and TAB chair aren't roles people are born to fill,
> they're roles people have to grow into.  What our community needs is
> more people willing to grow into these roles to ensure effective
> succession and if I stepped into one I'd be denying others that
> opportunity, which would be bad both for succession planning and the
> growth of the community in general.
> 
> I think the reason I'm getting these requests is angst over this CoC
> debate, so I'll go so far as to detail my political instincts over this
> below ... if you've no interest in politics (as most of you won't have)
> stop reading now.  If you are interested, perhaps you should consider
> standing for the TAB yourself.
> 
> James

Thank you for your service.

> The biggest political mistake was actually doing anything with the
> Linux Kernel CoC at all.  The object was to deflect a highly
> unfavourable article in the New Yorker.  With hind sight, that could be
> achieved simply by Linus' personal apology, statement that he was
> stepping aside and going for assistance to understand others' emotions.
> 
> Hind sight, though is always perfect.  At the time, as a TAB member,
> all you saw was a panic driven by both Linus and the Linux Foundation
> that we needed an updated Kernel CoC ASAP, like today.  Panic is very
> infectious so it can be extremely difficult in these circumstances to
> stand up and say "stop, we need more information"  ... and if you think
> you'd be the one always to demand more information remember that
> there's a time a decision has to be made and it always passes before
> you can get complete information, so you'd basically be rendering the
> TAB indecisive and useless.  Recognising when it's time to stop and ask
> for more data and when you have to make decisions with what you have is
> a key political skill.

Based on what it looked like from outside the process, this analysis
matches what I observed.


> The second mistake was picking the wrong CoC.  I'm not talking about
> the wording, which has been discussed on this list, but the politics
> surrounding the choice:  The original author of the current CoC was
> unsupportive to the point of attacking the kernel community in public. 
> That drove a huge amount of me too attacks plus an equally large amount
> of anti-me too hysteria and lead to enormous external awareness and
> friction plus a not inconsiderable amount of unwelcome personal email
> to various people.  This could largely have been avoided by either
> evolving our existing CoC through a community process or by picking a
> CoC whose original author would be willing to stand up and be
> supportive of our desire to change.

There is precedent for taking something which did not match
the political alignment of the community (GPL license) and modifying
the interpretation to meet the consensus of the a subset of the
community. I don't think even today that the Linux kernel developers
beliefs around GPL match the purist camp.

> The third mistake was dumping the fully formed CoC and a later update
> into the tree with little to no community input which has generated a
> lot of obvious anger within our community itself. All I'll say on this
> is that revisiting the CoC is going to cause another huge cascade of
> externally driven attacks which I think we'd all rather avoid, so if
> you're still ticked, then perhaps you should channel that anger and
> stand for the TAB ...

This is where I disagree. Without doing something it would have caused
even more attacks.  This kind of messy surgery was necessary to fix
the practice and perception of the kernel developers.

James, I am sorry to see you throw your hands up and give up.
It is has always been valuable to have your considered insight
even if at times we all disagree.

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Stephen Hemminger]

On Thu, 08 Nov 2018 16:04:02 -0800
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> Hi All,
> 
> Several people have asked me to stand again for election to the TAB, so
> I thought I'd give a general explanation of why that isn't going to
> happen.  For background: I was one of the people who lead the charge in
> getting the Linux Foundation predecessor OSDL to create the TAB to give
> developer input into what was then seen as a body trying to speak for
> the Linux Kernel.  I was actually TAB chair for 8 years from 2006 to
> 2014.  The job of the TAB, as I saw it, was to solve a lot of the
> political friction issues around the places where the Linux Kernel
> community interfaces with the Linux Foundation and Industry and in
> those 8 years I gained quite a lot of expertise in political relations
> trying to do that.
> 
> However, TAB member and TAB chair aren't roles people are born to fill,
> they're roles people have to grow into.  What our community needs is
> more people willing to grow into these roles to ensure effective
> succession and if I stepped into one I'd be denying others that
> opportunity, which would be bad both for succession planning and the
> growth of the community in general.
> 
> I think the reason I'm getting these requests is angst over this CoC
> debate, so I'll go so far as to detail my political instincts over this
> below ... if you've no interest in politics (as most of you won't have)
> stop reading now.  If you are interested, perhaps you should consider
> standing for the TAB yourself.
> 
> James

Thank you for your service.

> The biggest political mistake was actually doing anything with the
> Linux Kernel CoC at all.  The object was to deflect a highly
> unfavourable article in the New Yorker.  With hind sight, that could be
> achieved simply by Linus' personal apology, statement that he was
> stepping aside and going for assistance to understand others' emotions.
> 
> Hind sight, though is always perfect.  At the time, as a TAB member,
> all you saw was a panic driven by both Linus and the Linux Foundation
> that we needed an updated Kernel CoC ASAP, like today.  Panic is very
> infectious so it can be extremely difficult in these circumstances to
> stand up and say "stop, we need more information"  ... and if you think
> you'd be the one always to demand more information remember that
> there's a time a decision has to be made and it always passes before
> you can get complete information, so you'd basically be rendering the
> TAB indecisive and useless.  Recognising when it's time to stop and ask
> for more data and when you have to make decisions with what you have is
> a key political skill.

Based on what it looked like from outside the process, this analysis
matches what I observed.


> The second mistake was picking the wrong CoC.  I'm not talking about
> the wording, which has been discussed on this list, but the politics
> surrounding the choice:  The original author of the current CoC was
> unsupportive to the point of attacking the kernel community in public. 
> That drove a huge amount of me too attacks plus an equally large amount
> of anti-me too hysteria and lead to enormous external awareness and
> friction plus a not inconsiderable amount of unwelcome personal email
> to various people.  This could largely have been avoided by either
> evolving our existing CoC through a community process or by picking a
> CoC whose original author would be willing to stand up and be
> supportive of our desire to change.

There is precedent for taking something which did not match
the political alignment of the community (GPL license) and modifying
the interpretation to meet the consensus of the a subset of the
community. I don't think even today that the Linux kernel developers
beliefs around GPL match the purist camp.

> The third mistake was dumping the fully formed CoC and a later update
> into the tree with little to no community input which has generated a
> lot of obvious anger within our community itself. All I'll say on this
> is that revisiting the CoC is going to cause another huge cascade of
> externally driven attacks which I think we'd all rather avoid, so if
> you're still ticked, then perhaps you should channel that anger and
> stand for the TAB ...

This is where I disagree. Without doing something it would have caused
even more attacks.  This kind of messy surgery was necessary to fix
the practice and perception of the kernel developers.

James, I am sorry to see you throw your hands up and give up.
It is has always been valuable to have your considered insight
even if at times we all disagree.

Re: [Ksummit-discuss] TAB non-nomination

[Shuah Khan]

On 11/08/2018 08:30 PM, Chris Mason wrote:
> On 8 Nov 2018, at 16:04, James Bottomley wrote:
>>
>> Hind sight, though is always perfect.  At the time, as a TAB member,
>> all you saw was a panic driven by both Linus and the Linux Foundation
>> that we needed an updated Kernel CoC ASAP, like today.
> 
> I think panic is the wrong word to attach to Linus' response, especially 
> around the code of conduct.
> 
>>
>> The second mistake was picking the wrong CoC. [ ... ]
>>
>> The third mistake was dumping the fully formed CoC and a later update
>> into the tree with little to no community input
> 

It is unfortunate it had to start that way. I also understand at times it
might be necessary to do so based on my experience with the Linux Kernel
Community Enforcement Statement process. What should TAB do as a body if
it needs to take action without an option to initiate an open discussion?

I am of the opinion that that was the situation the TAB was in a couple of
months ago. Whether that the right choice or not, it is important to continue
the conversation and come to an understanding that this is a problem that
needs to ab addressed. I think we are on the path to doing that.

> The update was entirely based on community input.
> 
>> which has generated a
>> lot of obvious anger within our community itself.
> 
> It's absolutely true that some members of the community were upset.
> 
> We'll never know if there could have been a better time to make code of 
> conduct changes.  There are a wide range of deeply held beliefs in this 
> area, and every choice would have eventually led to major disagreements. 
>   But what we do know is that everyone sat down and did their best to 
> find compromise.  That doesn't mean we found the right compromise for 
> every developer, but I still really appreciate how much time and energy 
> everyone spent explaining their point of view and looking for common 
> ground.
> 

The positive take away for me in what transpired these past couple of
months is just that. The community came together to discuss and express
their point of view to move the nudge process forward and speak out to
say "we didn't like the way it was handled".

I don't see this as an end and we have to continue to evolve CoC as a
living document.

>> All I'll say on this
>> is that revisiting the CoC is going to cause another huge cascade of
>> externally driven attacks which I think we'd all rather avoid, so if
>> you're still ticked, then perhaps you should channel that anger and
>> stand for the TAB ...
>>
> 
> It's really important the TAB is full of people that care about the 
> kernel.  Anger about the code of conduct isn't a great qualifier, but 
> I'll happily encourage anyone who cares deeply about the kernel 
> community, even if they disagree with my opinions about how to best 
> support it.
> 

Right. This is the reason why I am standing for TAB and I want to be part
of the solution and not part of the problem. I am looking for constructive
ways to keep our community viable for years to come.

thanks,
-- Shuah

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Shuah Khan]

On 11/08/2018 08:30 PM, Chris Mason wrote:
> On 8 Nov 2018, at 16:04, James Bottomley wrote:
>>
>> Hind sight, though is always perfect.  At the time, as a TAB member,
>> all you saw was a panic driven by both Linus and the Linux Foundation
>> that we needed an updated Kernel CoC ASAP, like today.
> 
> I think panic is the wrong word to attach to Linus' response, especially 
> around the code of conduct.
> 
>>
>> The second mistake was picking the wrong CoC. [ ... ]
>>
>> The third mistake was dumping the fully formed CoC and a later update
>> into the tree with little to no community input
> 

It is unfortunate it had to start that way. I also understand at times it
might be necessary to do so based on my experience with the Linux Kernel
Community Enforcement Statement process. What should TAB do as a body if
it needs to take action without an option to initiate an open discussion?

I am of the opinion that that was the situation the TAB was in a couple of
months ago. Whether that the right choice or not, it is important to continue
the conversation and come to an understanding that this is a problem that
needs to ab addressed. I think we are on the path to doing that.

> The update was entirely based on community input.
> 
>> which has generated a
>> lot of obvious anger within our community itself.
> 
> It's absolutely true that some members of the community were upset.
> 
> We'll never know if there could have been a better time to make code of 
> conduct changes.  There are a wide range of deeply held beliefs in this 
> area, and every choice would have eventually led to major disagreements. 
>   But what we do know is that everyone sat down and did their best to 
> find compromise.  That doesn't mean we found the right compromise for 
> every developer, but I still really appreciate how much time and energy 
> everyone spent explaining their point of view and looking for common 
> ground.
> 

The positive take away for me in what transpired these past couple of
months is just that. The community came together to discuss and express
their point of view to move the nudge process forward and speak out to
say "we didn't like the way it was handled".

I don't see this as an end and we have to continue to evolve CoC as a
living document.

>> All I'll say on this
>> is that revisiting the CoC is going to cause another huge cascade of
>> externally driven attacks which I think we'd all rather avoid, so if
>> you're still ticked, then perhaps you should channel that anger and
>> stand for the TAB ...
>>
> 
> It's really important the TAB is full of people that care about the 
> kernel.  Anger about the code of conduct isn't a great qualifier, but 
> I'll happily encourage anyone who cares deeply about the kernel 
> community, even if they disagree with my opinions about how to best 
> support it.
> 

Right. This is the reason why I am standing for TAB and I want to be part
of the solution and not part of the problem. I am looking for constructive
ways to keep our community viable for years to come.

thanks,
-- Shuah

Re: [Ksummit-discuss] TAB non-nomination

[Theodore Y. Ts'o]

On Fri, Nov 09, 2018 at 10:52:55AM -0700, Shuah Khan wrote:
> >> The third mistake was dumping the fully formed CoC and a later update
> >> into the tree with little to no community input
> 
> It is unfortunate it had to start that way. I also understand at times it
> might be necessary to do so based on my experience with the Linux Kernel
> Community Enforcement Statement process. What should TAB do as a body if
> it needs to take action without an option to initiate an open discussion?

As Chris mentioned, there was a large amount of community input on the
update.  It just didn't happen in an open fashion.  One of the
challenges with e-mail discussion is that it can end up get dominated
by a small number of people who send a large number of messages.  In
an in-person meeting, a good moderator can say, "Alexis, you've been
talking a lot; perhaps we should hear from some other people who have
been quiet.  Drew, what do you think?"  It's a lot harder to do this
on a mailing list.

The second challenge is that we were getting trolled by people who
were *not* members of the kernel development community.  I was able to
track down one such troll to their social media presence on gab.ai.
(Yeah, that same lovely "free speech absolutists' site, for when
Twitter considers you too toxic" which got deplatformed after the
shooting at the Tree of Life Synagogue in Pittsburgh.)

So what was done with the update to the CoC was that a proposed set of
changes was sent out to the top 200 or so contributors to the kernel,
by git statistics over the past year, asking for their comments and
their sign-offs.  So there *was* community input, and that input did
result in changes to the CoC update.

Could there be a better process?  I think we're all open to input.  If
someone would like to suggest a better way to handle things, that
would be great.  I will disclose upfront, though, that I will have to
politely disagree with the proposition that completely free and open
discussion is always the magic bullet solution.

Regards,

						- Ted

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Theodore Y. Ts'o]

On Fri, Nov 09, 2018 at 10:52:55AM -0700, Shuah Khan wrote:
> >> The third mistake was dumping the fully formed CoC and a later update
> >> into the tree with little to no community input
> 
> It is unfortunate it had to start that way. I also understand at times it
> might be necessary to do so based on my experience with the Linux Kernel
> Community Enforcement Statement process. What should TAB do as a body if
> it needs to take action without an option to initiate an open discussion?

As Chris mentioned, there was a large amount of community input on the
update.  It just didn't happen in an open fashion.  One of the
challenges with e-mail discussion is that it can end up get dominated
by a small number of people who send a large number of messages.  In
an in-person meeting, a good moderator can say, "Alexis, you've been
talking a lot; perhaps we should hear from some other people who have
been quiet.  Drew, what do you think?"  It's a lot harder to do this
on a mailing list.

The second challenge is that we were getting trolled by people who
were *not* members of the kernel development community.  I was able to
track down one such troll to their social media presence on gab.ai.
(Yeah, that same lovely "free speech absolutists' site, for when
Twitter considers you too toxic" which got deplatformed after the
shooting at the Tree of Life Synagogue in Pittsburgh.)

So what was done with the update to the CoC was that a proposed set of
changes was sent out to the top 200 or so contributors to the kernel,
by git statistics over the past year, asking for their comments and
their sign-offs.  So there *was* community input, and that input did
result in changes to the CoC update.

Could there be a better process?  I think we're all open to input.  If
someone would like to suggest a better way to handle things, that
would be great.  I will disclose upfront, though, that I will have to
politely disagree with the proposition that completely free and open
discussion is always the magic bullet solution.

Regards,

						- Ted

Re: [Ksummit-discuss] TAB non-nomination

[Joe Perches]

On Fri, 2018-11-09 at 14:03 -0500, Theodore Y. Ts'o wrote:
> On Fri, Nov 09, 2018 at 10:52:55AM -0700, Shuah Khan wrote:
> > > > The third mistake was dumping the fully formed CoC and a later update
> > > > into the tree with little to no community input

I agree with this statement.

> So what was done with the update to the CoC was that a proposed set of
> changes was sent out to the top 200 or so contributors to the kernel,
> by git statistics over the past year, asking for their comments and
> their sign-offs.

I believe that did not happen as described as at least
I was not asked for input/comment/sign-off and I am
well within that top 200 or so list.

> So there *was* community input, and that input did
> result in changes to the CoC update.
> 
> Could there be a better process?  I think we're all open to input.  If
> someone would like to suggest a better way to handle things, that
> would be great.

Open posting of suggested changes with a waiting
period for comment of at least a week.

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Joe Perches]

On Fri, 2018-11-09 at 14:03 -0500, Theodore Y. Ts'o wrote:
> On Fri, Nov 09, 2018 at 10:52:55AM -0700, Shuah Khan wrote:
> > > > The third mistake was dumping the fully formed CoC and a later update
> > > > into the tree with little to no community input

I agree with this statement.

> So what was done with the update to the CoC was that a proposed set of
> changes was sent out to the top 200 or so contributors to the kernel,
> by git statistics over the past year, asking for their comments and
> their sign-offs.

I believe that did not happen as described as at least
I was not asked for input/comment/sign-off and I am
well within that top 200 or so list.

> So there *was* community input, and that input did
> result in changes to the CoC update.
> 
> Could there be a better process?  I think we're all open to input.  If
> someone would like to suggest a better way to handle things, that
> would be great.

Open posting of suggested changes with a waiting
period for comment of at least a week.

Re: [Ksummit-discuss] [Tech-board-discuss] TAB non-nomination

[Frank Rowand]

On 11/8/18 7:30 PM, Chris Mason wrote:
> On 8 Nov 2018, at 16:04, James Bottomley wrote:
>>
>> Hind sight, though is always perfect.  At the time, as a TAB member,
>> all you saw was a panic driven by both Linus and the Linux Foundation
>> that we needed an updated Kernel CoC ASAP, like today.
> 
> I think panic is the wrong word to attach to Linus' response, especially 
> around the code of conduct.
> 
>>
>> The second mistake was picking the wrong CoC. [ ... ]
>>
>> The third mistake was dumping the fully formed CoC and a later update
>> into the tree with little to no community input
> 

> The update was entirely based on community input.

I am going to try to parse that sentence very carefully and narrowly.

If you are saying that the update (that is, code-of-conduct-interpretation.rst)
then I would agree that the document appears to have been created
based on community input.  But that is merely a conjecture on my part
since the document was created in a small closed group.

If you are saying that the creation of code-of-conduct-interpretation.rst
was done in a process that was open and visible to the community, then
I would disagree.  I don't know if this is what you meant to convey,
but it is very easy to interpret the sentence in this way.

-Frank


>> which has generated a
>> lot of obvious anger within our community itself.
> 
> It's absolutely true that some members of the community were upset.
> 
> We'll never know if there could have been a better time to make code of 
> conduct changes.  There are a wide range of deeply held beliefs in this 
> area, and every choice would have eventually led to major disagreements. 
>   But what we do know is that everyone sat down and did their best to 
> find compromise.  That doesn't mean we found the right compromise for 
> every developer, but I still really appreciate how much time and energy 
> everyone spent explaining their point of view and looking for common 
> ground.
> 
>> All I'll say on this
>> is that revisiting the CoC is going to cause another huge cascade of
>> externally driven attacks which I think we'd all rather avoid, so if
>> you're still ticked, then perhaps you should channel that anger and
>> stand for the TAB ...
>>
> 
> It's really important the TAB is full of people that care about the 
> kernel.  Anger about the code of conduct isn't a great qualifier, but 
> I'll happily encourage anyone who cares deeply about the kernel 
> community, even if they disagree with my opinions about how to best 
> support it.
> 
> -chris
> _______________________________________________
> Tech-board-discuss mailing list
> Tech-board-discuss@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/tech-board-discuss
> 

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Frank Rowand]

On 11/8/18 7:30 PM, Chris Mason wrote:
> On 8 Nov 2018, at 16:04, James Bottomley wrote:
>>
>> Hind sight, though is always perfect.  At the time, as a TAB member,
>> all you saw was a panic driven by both Linus and the Linux Foundation
>> that we needed an updated Kernel CoC ASAP, like today.
> 
> I think panic is the wrong word to attach to Linus' response, especially 
> around the code of conduct.
> 
>>
>> The second mistake was picking the wrong CoC. [ ... ]
>>
>> The third mistake was dumping the fully formed CoC and a later update
>> into the tree with little to no community input
> 

> The update was entirely based on community input.

I am going to try to parse that sentence very carefully and narrowly.

If you are saying that the update (that is, code-of-conduct-interpretation.rst)
then I would agree that the document appears to have been created
based on community input.  But that is merely a conjecture on my part
since the document was created in a small closed group.

If you are saying that the creation of code-of-conduct-interpretation.rst
was done in a process that was open and visible to the community, then
I would disagree.  I don't know if this is what you meant to convey,
but it is very easy to interpret the sentence in this way.

-Frank


>> which has generated a
>> lot of obvious anger within our community itself.
> 
> It's absolutely true that some members of the community were upset.
> 
> We'll never know if there could have been a better time to make code of 
> conduct changes.  There are a wide range of deeply held beliefs in this 
> area, and every choice would have eventually led to major disagreements. 
>   But what we do know is that everyone sat down and did their best to 
> find compromise.  That doesn't mean we found the right compromise for 
> every developer, but I still really appreciate how much time and energy 
> everyone spent explaining their point of view and looking for common 
> ground.
> 
>> All I'll say on this
>> is that revisiting the CoC is going to cause another huge cascade of
>> externally driven attacks which I think we'd all rather avoid, so if
>> you're still ticked, then perhaps you should channel that anger and
>> stand for the TAB ...
>>
> 
> It's really important the TAB is full of people that care about the 
> kernel.  Anger about the code of conduct isn't a great qualifier, but 
> I'll happily encourage anyone who cares deeply about the kernel 
> community, even if they disagree with my opinions about how to best 
> support it.
> 
> -chris
> _______________________________________________
> Tech-board-discuss mailing list
> Tech-board-discuss@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/tech-board-discuss
> 

[Ksummit-discuss] better hot-topic discussion processes was: Re: TAB non-nomination

[Jason Cooper]

+Kostantin

Hi Ted,

On Fri, Nov 09, 2018 at 02:03:05PM -0500, Theodore Y. Ts'o wrote:
> So what was done with the update to the CoC was that a proposed set of
> changes was sent out to the top 200 or so contributors to the kernel,
> by git statistics over the past year, asking for their comments and
> their sign-offs.  So there *was* community input, and that input did
> result in changes to the CoC update.
> 
> Could there be a better process?  I think we're all open to input.  If
> someone would like to suggest a better way to handle things, that
> would be great.  I will disclose upfront, though, that I will have to
> politely disagree with the proposition that completely free and open
> discussion is always the magic bullet solution.

Ok, I'll take a stab at that. :)

I'll make the assumption that there was nothing said in the "invited"
discussion that the speaker would object to being a matter of public
record.

So I see two possible avenues to improve the process.  Keeping in mind
that these are rare, and thus the process shouldn't be a burden.

The first is what I'll call a "delayed archive."  Basically, you Cc the
archive in along with the invitees to the discussion.  The archive
server then adds the emails to the public archive 90 days after the
email was sent.  This might also work well for the security ML.

The second is more of a "distributed moderation" model.  A mailinglist
would be added to the Cc where only members can post.  Non-member posts
are dropped.  However, there are also "subscribers"; they can't post,
but they receive posts to the ML.[1]  There is no delay.

So, if I'm just a subscriber, but I know James, and I want to contribute
to the discussion, I send my reply to him, and he can forward it if
relevant.[2]  James can filter any emails coming in against his address
book so he's not bothered with people he doesn't know (Don't we all
already do this? :-) ).  The same goes for all the other members.  The
idea here is avoid the single-point-of-failure of having a single
moderator.  Optionally, the "members" could be automatically assigned
that status based on the git history.

thx,

Jason.

[1] Another way to describe this is an ML for which posting is limited
to subscribers that meet a given threshold within the git history.

[2] programmatically, we could say that James' address is in the To: and
all others in the Cc:.  This would allow for easier spotting of "I'm
being asked to moderate this."

[Tech-board-discuss] better hot-topic discussion processes was: Re: TAB non-nomination

[Jason Cooper]

+Kostantin

Hi Ted,

On Fri, Nov 09, 2018 at 02:03:05PM -0500, Theodore Y. Ts'o wrote:
> So what was done with the update to the CoC was that a proposed set of
> changes was sent out to the top 200 or so contributors to the kernel,
> by git statistics over the past year, asking for their comments and
> their sign-offs.  So there *was* community input, and that input did
> result in changes to the CoC update.
> 
> Could there be a better process?  I think we're all open to input.  If
> someone would like to suggest a better way to handle things, that
> would be great.  I will disclose upfront, though, that I will have to
> politely disagree with the proposition that completely free and open
> discussion is always the magic bullet solution.

Ok, I'll take a stab at that. :)

I'll make the assumption that there was nothing said in the "invited"
discussion that the speaker would object to being a matter of public
record.

So I see two possible avenues to improve the process.  Keeping in mind
that these are rare, and thus the process shouldn't be a burden.

The first is what I'll call a "delayed archive."  Basically, you Cc the
archive in along with the invitees to the discussion.  The archive
server then adds the emails to the public archive 90 days after the
email was sent.  This might also work well for the security ML.

The second is more of a "distributed moderation" model.  A mailinglist
would be added to the Cc where only members can post.  Non-member posts
are dropped.  However, there are also "subscribers"; they can't post,
but they receive posts to the ML.[1]  There is no delay.

So, if I'm just a subscriber, but I know James, and I want to contribute
to the discussion, I send my reply to him, and he can forward it if
relevant.[2]  James can filter any emails coming in against his address
book so he's not bothered with people he doesn't know (Don't we all
already do this? :-) ).  The same goes for all the other members.  The
idea here is avoid the single-point-of-failure of having a single
moderator.  Optionally, the "members" could be automatically assigned
that status based on the git history.

thx,

Jason.

[1] Another way to describe this is an ML for which posting is limited
to subscribers that meet a given threshold within the git history.

[2] programmatically, we could say that James' address is in the To: and
all others in the Cc:.  This would allow for easier spotting of "I'm
being asked to moderate this."

Re: [Ksummit-discuss] [Tech-board-discuss] TAB non-nomination

[Chris Mason]

On 9 Nov 2018, at 11:54, Frank Rowand wrote:

> On 11/8/18 7:30 PM, Chris Mason wrote:
>> On 8 Nov 2018, at 16:04, James Bottomley wrote:
>>>
>>> Hind sight, though is always perfect.  At the time, as a TAB member,
>>> all you saw was a panic driven by both Linus and the Linux 
>>> Foundation
>>> that we needed an updated Kernel CoC ASAP, like today.
>>
>> I think panic is the wrong word to attach to Linus' response, 
>> especially
>> around the code of conduct.
>>
>>>
>>> The second mistake was picking the wrong CoC. [ ... ]
>>>
>>> The third mistake was dumping the fully formed CoC and a later 
>>> update
>>> into the tree with little to no community input
>>
>
>> The update was entirely based on community input.
>
> I am going to try to parse that sentence very carefully and narrowly.
>
> If you are saying that the update (that is, 
> code-of-conduct-interpretation.rst)
> then I would agree that the document appears to have been created
> based on community input.  But that is merely a conjecture on my part
> since the document was created in a small closed group.
>
> If you are saying that the creation of 
> code-of-conduct-interpretation.rst
> was done in a process that was open and visible to the community, then
> I would disagree.  I don't know if this is what you meant to convey,
> but it is very easy to interpret the sentence in this way.
>

Ted's earlier reply has a good summary, but the part I want to underline 
is that we sought out people who strongly disagreed with us, and we did 
our best to understand their concerns.  It was important to me that we 
give people a private channel to express themselves, especially 
considering that the topic at hand was behavior on public lists.

It was a tradeoff, but I was really happy with the number of people who 
participated who might otherwise have stayed out of the discussion 
completely.

-chris

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Chris Mason]

On 9 Nov 2018, at 11:54, Frank Rowand wrote:

> On 11/8/18 7:30 PM, Chris Mason wrote:
>> On 8 Nov 2018, at 16:04, James Bottomley wrote:
>>>
>>> Hind sight, though is always perfect.  At the time, as a TAB member,
>>> all you saw was a panic driven by both Linus and the Linux 
>>> Foundation
>>> that we needed an updated Kernel CoC ASAP, like today.
>>
>> I think panic is the wrong word to attach to Linus' response, 
>> especially
>> around the code of conduct.
>>
>>>
>>> The second mistake was picking the wrong CoC. [ ... ]
>>>
>>> The third mistake was dumping the fully formed CoC and a later 
>>> update
>>> into the tree with little to no community input
>>
>
>> The update was entirely based on community input.
>
> I am going to try to parse that sentence very carefully and narrowly.
>
> If you are saying that the update (that is, 
> code-of-conduct-interpretation.rst)
> then I would agree that the document appears to have been created
> based on community input.  But that is merely a conjecture on my part
> since the document was created in a small closed group.
>
> If you are saying that the creation of 
> code-of-conduct-interpretation.rst
> was done in a process that was open and visible to the community, then
> I would disagree.  I don't know if this is what you meant to convey,
> but it is very easy to interpret the sentence in this way.
>

Ted's earlier reply has a good summary, but the part I want to underline 
is that we sought out people who strongly disagreed with us, and we did 
our best to understand their concerns.  It was important to me that we 
give people a private channel to express themselves, especially 
considering that the topic at hand was behavior on public lists.

It was a tradeoff, but I was really happy with the number of people who 
participated who might otherwise have stayed out of the discussion 
completely.

-chris

Re: [Ksummit-discuss] better hot-topic discussion processes was: Re: TAB non-nomination

[Chris Mason]

On 9 Nov 2018, at 12:17, Jason Cooper wrote:

> +Kostantin
>
> Hi Ted,
>
> On Fri, Nov 09, 2018 at 02:03:05PM -0500, Theodore Y. Ts'o wrote:
>> So what was done with the update to the CoC was that a proposed set of
>> changes was sent out to the top 200 or so contributors to the kernel,
>> by git statistics over the past year, asking for their comments and
>> their sign-offs.  So there *was* community input, and that input did
>> result in changes to the CoC update.
>>
>> Could there be a better process?  I think we're all open to input.  If
>> someone would like to suggest a better way to handle things, that
>> would be great.  I will disclose upfront, though, that I will have to
>> politely disagree with the proposition that completely free and open
>> discussion is always the magic bullet solution.
>
> Ok, I'll take a stab at that. :)
>
> I'll make the assumption that there was nothing said in the "invited"
> discussion that the speaker would object to being a matter of public
> record.

I'm snipping the rest because you lost me right here ;)

-chris

Re: [Tech-board-discuss] [Ksummit-discuss] better hot-topic discussion processes was: Re: TAB non-nomination

[Chris Mason]

On 9 Nov 2018, at 12:17, Jason Cooper wrote:

> +Kostantin
>
> Hi Ted,
>
> On Fri, Nov 09, 2018 at 02:03:05PM -0500, Theodore Y. Ts'o wrote:
>> So what was done with the update to the CoC was that a proposed set of
>> changes was sent out to the top 200 or so contributors to the kernel,
>> by git statistics over the past year, asking for their comments and
>> their sign-offs.  So there *was* community input, and that input did
>> result in changes to the CoC update.
>>
>> Could there be a better process?  I think we're all open to input.  If
>> someone would like to suggest a better way to handle things, that
>> would be great.  I will disclose upfront, though, that I will have to
>> politely disagree with the proposition that completely free and open
>> discussion is always the magic bullet solution.
>
> Ok, I'll take a stab at that. :)
>
> I'll make the assumption that there was nothing said in the "invited"
> discussion that the speaker would object to being a matter of public
> record.

I'm snipping the rest because you lost me right here ;)

-chris

Re: [Ksummit-discuss] TAB non-nomination

[Theodore Y. Ts'o]

On Fri, Nov 09, 2018 at 11:23:26AM -0800, Joe Perches wrote:
> I believe that did not happen as described as at least
> I was not asked for input/comment/sign-off and I ahm
> well within that top 200 or so list.

I'm not sure precisely which metrics Greg used when he created his
list, but using "git log --since="July 2017" v4.18" and piping it into
the perl script I use to count Signed-off-by, Acked-by, and
Reviewed-by, lines, you're about #240; so you're in the top 250, but
not the top 200.

There are other metrics that could be used as well, such using the
number of lines added/removed to create the ranked list.  Different
metrics will have differing amounts of bias for or against people who
generate large number of "rename variables to random new types" or
"whitespace cleanups" commits.

To be honest, that's one of the weaknesses of only using git
statistics.  They have the advantage that they are objective; however,
especially if the exact metric which is used is revealed, such systems
can also be easily gamed.  (e.g., do you create a single commit that
fixes all of the white space in one subsystem or use a separate commit
for each file?)

And of course, using commit statistics may not accurately measure the
value of say, a set of patches which add support for a new
architecture or fixes a tricky locking problem, versus commits which
only fix checkpatch complaints.  So I will be the first to admit that
using git statistics has its limitations.

Regards,

					- Ted

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Theodore Y. Ts'o]

On Fri, Nov 09, 2018 at 11:23:26AM -0800, Joe Perches wrote:
> I believe that did not happen as described as at least
> I was not asked for input/comment/sign-off and I ahm
> well within that top 200 or so list.

I'm not sure precisely which metrics Greg used when he created his
list, but using "git log --since="July 2017" v4.18" and piping it into
the perl script I use to count Signed-off-by, Acked-by, and
Reviewed-by, lines, you're about #240; so you're in the top 250, but
not the top 200.

There are other metrics that could be used as well, such using the
number of lines added/removed to create the ranked list.  Different
metrics will have differing amounts of bias for or against people who
generate large number of "rename variables to random new types" or
"whitespace cleanups" commits.

To be honest, that's one of the weaknesses of only using git
statistics.  They have the advantage that they are objective; however,
especially if the exact metric which is used is revealed, such systems
can also be easily gamed.  (e.g., do you create a single commit that
fixes all of the white space in one subsystem or use a separate commit
for each file?)

And of course, using commit statistics may not accurately measure the
value of say, a set of patches which add support for a new
architecture or fixes a tricky locking problem, versus commits which
only fix checkpatch complaints.  So I will be the first to admit that
using git statistics has its limitations.

Regards,

					- Ted

Re: [Ksummit-discuss] TAB non-nomination

[Joe Perches]

On Sat, 2018-11-10 at 16:21 -0500, Theodore Y. Ts'o wrote:
> On Fri, Nov 09, 2018 at 11:23:26AM -0800, Joe Perches wrote:
> > I believe that did not happen as described as at least
> > I was not asked for input/comment/sign-off and I ahm
> > well within that top 200 or so list.
> 
> I'm not sure precisely which metrics Greg used when he created his
> list, but using "git log --since="July 2017" v4.18" and piping it into
> the perl script I use to count Signed-off-by, Acked-by, and
> Reviewed-by, lines, you're about #240; so you're in the top 250, but
> not the top 200.

Acks are nearly useless as a metric.
Non-primary Sign-offs are less so.

By author is a rather more useful one.

$ git shortlog -n -s --since=<foo>

Separating whitespace/checkpatch style patches
from actual defect fixes and other enhancements is,
of course, a more difficult automation problem.

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Joe Perches]

On Sat, 2018-11-10 at 16:21 -0500, Theodore Y. Ts'o wrote:
> On Fri, Nov 09, 2018 at 11:23:26AM -0800, Joe Perches wrote:
> > I believe that did not happen as described as at least
> > I was not asked for input/comment/sign-off and I ahm
> > well within that top 200 or so list.
> 
> I'm not sure precisely which metrics Greg used when he created his
> list, but using "git log --since="July 2017" v4.18" and piping it into
> the perl script I use to count Signed-off-by, Acked-by, and
> Reviewed-by, lines, you're about #240; so you're in the top 250, but
> not the top 200.

Acks are nearly useless as a metric.
Non-primary Sign-offs are less so.

By author is a rather more useful one.

$ git shortlog -n -s --since=<foo>

Separating whitespace/checkpatch style patches
from actual defect fixes and other enhancements is,
of course, a more difficult automation problem.

Re: [Ksummit-discuss] better hot-topic discussion processes was: Re: TAB non-nomination

[Jason Cooper]

Hi Chris,

On Sat, Nov 10, 2018 at 07:26:55PM +0000, Chris Mason wrote:
> On 9 Nov 2018, at 12:17, Jason Cooper wrote:
> > On Fri, Nov 09, 2018 at 02:03:05PM -0500, Theodore Y. Ts'o wrote:
> >> So what was done with the update to the CoC was that a proposed set of
> >> changes was sent out to the top 200 or so contributors to the kernel,
> >> by git statistics over the past year, asking for their comments and
> >> their sign-offs.  So there *was* community input, and that input did
> >> result in changes to the CoC update.
> >>
> >> Could there be a better process?  I think we're all open to input.  If
> >> someone would like to suggest a better way to handle things, that
> >> would be great.  I will disclose upfront, though, that I will have to
> >> politely disagree with the proposition that completely free and open
> >> discussion is always the magic bullet solution.
> >
> > Ok, I'll take a stab at that. :)
> >
> > I'll make the assumption that there was nothing said in the "invited"
> > discussion that the speaker would object to being a matter of public
> > record.
> 
> I'm snipping the rest because you lost me right here ;)

In light of your other, slightly more verbose email (venue for objectors
to speak freely), I agree.  I was not aware that was a primary reason
for the "community, but non-public" discussion.

That is a tremendously valuable aspect of the decision, that I'd not
seen conveyed clearly until your email.  Thanks for sharing it.

thx,

Jason.

Re: [Tech-board-discuss] [Ksummit-discuss] better hot-topic discussion processes was: Re: TAB non-nomination

[Jason Cooper]

Hi Chris,

On Sat, Nov 10, 2018 at 07:26:55PM +0000, Chris Mason wrote:
> On 9 Nov 2018, at 12:17, Jason Cooper wrote:
> > On Fri, Nov 09, 2018 at 02:03:05PM -0500, Theodore Y. Ts'o wrote:
> >> So what was done with the update to the CoC was that a proposed set of
> >> changes was sent out to the top 200 or so contributors to the kernel,
> >> by git statistics over the past year, asking for their comments and
> >> their sign-offs.  So there *was* community input, and that input did
> >> result in changes to the CoC update.
> >>
> >> Could there be a better process?  I think we're all open to input.  If
> >> someone would like to suggest a better way to handle things, that
> >> would be great.  I will disclose upfront, though, that I will have to
> >> politely disagree with the proposition that completely free and open
> >> discussion is always the magic bullet solution.
> >
> > Ok, I'll take a stab at that. :)
> >
> > I'll make the assumption that there was nothing said in the "invited"
> > discussion that the speaker would object to being a matter of public
> > record.
> 
> I'm snipping the rest because you lost me right here ;)

In light of your other, slightly more verbose email (venue for objectors
to speak freely), I agree.  I was not aware that was a primary reason
for the "community, but non-public" discussion.

That is a tremendously valuable aspect of the decision, that I'd not
seen conveyed clearly until your email.  Thanks for sharing it.

thx,

Jason.

Re: [Ksummit-discuss] [Tech-board-discuss] TAB non-nomination

[Jason Cooper]

Hi Chris,

On Sat, Nov 10, 2018 at 07:15:16PM +0000, Chris Mason wrote:
...
> Ted's earlier reply has a good summary, but the part I want to underline 
> is that we sought out people who strongly disagreed with us, and we did 
> our best to understand their concerns.  It was important to me that we 
> give people a private channel to express themselves, especially 
> considering that the topic at hand was behavior on public lists.
> 
> It was a tradeoff, but I was really happy with the number of people who 
> participated who might otherwise have stayed out of the discussion 
> completely.

This is the most concise and clear explanation for the path taken.
Thanks for sharing it with everyone.

thx,

Jason.

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Jason Cooper]

Hi Chris,

On Sat, Nov 10, 2018 at 07:15:16PM +0000, Chris Mason wrote:
...
> Ted's earlier reply has a good summary, but the part I want to underline 
> is that we sought out people who strongly disagreed with us, and we did 
> our best to understand their concerns.  It was important to me that we 
> give people a private channel to express themselves, especially 
> considering that the topic at hand was behavior on public lists.
> 
> It was a tradeoff, but I was really happy with the number of people who 
> participated who might otherwise have stayed out of the discussion 
> completely.

This is the most concise and clear explanation for the path taken.
Thanks for sharing it with everyone.

thx,

Jason.

Re: [Ksummit-discuss] [Tech-board-discuss] TAB non-nomination

[Frank Rowand]

On 11/10/18 11:15 AM, Chris Mason wrote:
> 
> 
> On 9 Nov 2018, at 11:54, Frank Rowand wrote:
> 
>> On 11/8/18 7:30 PM, Chris Mason wrote:
>>> On 8 Nov 2018, at 16:04, James Bottomley wrote:
>>>>
>>>> Hind sight, though is always perfect.  At the time, as a TAB member,
>>>> all you saw was a panic driven by both Linus and the Linux 
>>>> Foundation
>>>> that we needed an updated Kernel CoC ASAP, like today.
>>>
>>> I think panic is the wrong word to attach to Linus' response, 
>>> especially
>>> around the code of conduct.
>>>
>>>>
>>>> The second mistake was picking the wrong CoC. [ ... ]
>>>>
>>>> The third mistake was dumping the fully formed CoC and a later 
>>>> update
>>>> into the tree with little to no community input
>>>
>>
>>> The update was entirely based on community input.
>>
>> I am going to try to parse that sentence very carefully and narrowly.
>>
>> If you are saying that the update (that is, 
>> code-of-conduct-interpretation.rst)
>> then I would agree that the document appears to have been created
>> based on community input.  But that is merely a conjecture on my part
>> since the document was created in a small closed group.
>>
>> If you are saying that the creation of 
>> code-of-conduct-interpretation.rst
>> was done in a process that was open and visible to the community, then
>> I would disagree.  I don't know if this is what you meant to convey,
>> but it is very easy to interpret the sentence in this way.
>>
> 
> Ted's earlier reply has a good summary, but the part I want to underline 
> is that we sought out people who strongly disagreed with us, and we did 
> our best to understand their concerns.  It was important to me that we 
> give people a private channel to express themselves, especially 
> considering that the topic at hand was behavior on public lists.

OK.  So the update was done in an opaque closed fashion, which involved
soliciting input from some unknown fraction of the community.  Do I
understand that correctly?

And I think it would be fair to say that the people who created the
update were probably aware of the comments of a much larger group of
people who had participated in the threads on various email lists,
and also I suspect the comments threads on the related lwn articles.
So likely also based on input from a (probably) larger fraction of
the community who had been willing to publicly comment.

So based on community input, but the document was not reviewed by the
broader community, or accepted by the broader community.

Note that my opinion is that code-of-conduct-interpretation.rst is
a step in a positive direction.  I'm just disappointed that it was
not submitted through the normal process of review (and no, sending
a patch to the mail list on Saturday and merging the patch two days
later on Monday is not normal review, especially when some people
were traveling to OSS Europe, ELC Europe, and the Maintainers
Summit that weekend).

-Frank


> It was a tradeoff, but I was really happy with the number of people who 
> participated who might otherwise have stayed out of the discussion 
> completely.
> 
> -chris
> 

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Frank Rowand]

On 11/10/18 11:15 AM, Chris Mason wrote:
> 
> 
> On 9 Nov 2018, at 11:54, Frank Rowand wrote:
> 
>> On 11/8/18 7:30 PM, Chris Mason wrote:
>>> On 8 Nov 2018, at 16:04, James Bottomley wrote:
>>>>
>>>> Hind sight, though is always perfect.  At the time, as a TAB member,
>>>> all you saw was a panic driven by both Linus and the Linux 
>>>> Foundation
>>>> that we needed an updated Kernel CoC ASAP, like today.
>>>
>>> I think panic is the wrong word to attach to Linus' response, 
>>> especially
>>> around the code of conduct.
>>>
>>>>
>>>> The second mistake was picking the wrong CoC. [ ... ]
>>>>
>>>> The third mistake was dumping the fully formed CoC and a later 
>>>> update
>>>> into the tree with little to no community input
>>>
>>
>>> The update was entirely based on community input.
>>
>> I am going to try to parse that sentence very carefully and narrowly.
>>
>> If you are saying that the update (that is, 
>> code-of-conduct-interpretation.rst)
>> then I would agree that the document appears to have been created
>> based on community input.  But that is merely a conjecture on my part
>> since the document was created in a small closed group.
>>
>> If you are saying that the creation of 
>> code-of-conduct-interpretation.rst
>> was done in a process that was open and visible to the community, then
>> I would disagree.  I don't know if this is what you meant to convey,
>> but it is very easy to interpret the sentence in this way.
>>
> 
> Ted's earlier reply has a good summary, but the part I want to underline 
> is that we sought out people who strongly disagreed with us, and we did 
> our best to understand their concerns.  It was important to me that we 
> give people a private channel to express themselves, especially 
> considering that the topic at hand was behavior on public lists.

OK.  So the update was done in an opaque closed fashion, which involved
soliciting input from some unknown fraction of the community.  Do I
understand that correctly?

And I think it would be fair to say that the people who created the
update were probably aware of the comments of a much larger group of
people who had participated in the threads on various email lists,
and also I suspect the comments threads on the related lwn articles.
So likely also based on input from a (probably) larger fraction of
the community who had been willing to publicly comment.

So based on community input, but the document was not reviewed by the
broader community, or accepted by the broader community.

Note that my opinion is that code-of-conduct-interpretation.rst is
a step in a positive direction.  I'm just disappointed that it was
not submitted through the normal process of review (and no, sending
a patch to the mail list on Saturday and merging the patch two days
later on Monday is not normal review, especially when some people
were traveling to OSS Europe, ELC Europe, and the Maintainers
Summit that weekend).

-Frank


> It was a tradeoff, but I was really happy with the number of people who 
> participated who might otherwise have stayed out of the discussion 
> completely.
> 
> -chris
> 

Re: [Ksummit-discuss] [Tech-board-discuss] TAB non-nomination

[Theodore Y. Ts'o]

On Sat, Nov 10, 2018 at 07:18:00PM -0800, Frank Rowand wrote:
> OK.  So the update was done in an opaque closed fashion, which involved
> soliciting input from some unknown fraction of the community.  Do I
> understand that correctly?
> 
> And I think it would be fair to say that the people who created the
> update were probably aware of the comments of a much larger group of
> people who had participated in the threads on various email lists,
> and also I suspect the comments threads on the related lwn articles.
> So likely also based on input from a (probably) larger fraction of
> the community who had been willing to publicly comment.
> 
> So based on community input, but the document was not reviewed by the
> broader community, or accepted by the broader community.

"Community" is a very slippery term.  I will note that there were
*many* people who were participating on the threads, sometimes in very
non-constructive or in a downright toxic fashion, who had zero commits
in recent years.  In some cases, it was zero commits, *ever*.  I
recall doing the research on one prolific author and found that while
he did contribute the kernel, it was 3 or 4 commits... ~5 years
ago... to a driver.

And then there was one person who admitted that while he was just a
user, he insisted he had a right to weigh in the issue.  They
certainly have the right to have that belief, of course.  Whether or
not maintainers are obliged to cater to people with those beliefs is a
very different question, however.

There seems to be an assumption that a open, public discussion will
always give you the best review.  I don't think that's necessarily
true.  It can often give you a very biased sample from the poeple who
are most stridently on one side of the debate or the other, as well as
being biased towards those who believe in the "last post wins" style
of debate, since they end up speaking most loudly and posting most
frequently and most aggressively.

I found it very interesting that by explicitly asking the top ranked
developers by git statistics for comments and for their sign-off on
the various update patches, we got a much broader read on what people
thought, and received some very thoughtful comments --- from people
who had *not* engaged on the public threads.

At this point, Linus has indicated that he would prefer that we not
try to tweak the CoC any further, and let's see how it works out in
practice.  If new developers continue to report that they feel more
welcome, and we get more news reports like this:

https://www.zdnet.com/article/a-kinder-gentler-linus-torvalds-and-linux-4-20/

... and no one is getting kicked out of Linux development for being
politically incorrect, and the quality and quantity of kernel code
continues to increase, it'll all be good and we can spend most of our
time worrying about technical rather than political issues.

     	      	    	      	     	  - Ted

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Theodore Y. Ts'o]

On Sat, Nov 10, 2018 at 07:18:00PM -0800, Frank Rowand wrote:
> OK.  So the update was done in an opaque closed fashion, which involved
> soliciting input from some unknown fraction of the community.  Do I
> understand that correctly?
> 
> And I think it would be fair to say that the people who created the
> update were probably aware of the comments of a much larger group of
> people who had participated in the threads on various email lists,
> and also I suspect the comments threads on the related lwn articles.
> So likely also based on input from a (probably) larger fraction of
> the community who had been willing to publicly comment.
> 
> So based on community input, but the document was not reviewed by the
> broader community, or accepted by the broader community.

"Community" is a very slippery term.  I will note that there were
*many* people who were participating on the threads, sometimes in very
non-constructive or in a downright toxic fashion, who had zero commits
in recent years.  In some cases, it was zero commits, *ever*.  I
recall doing the research on one prolific author and found that while
he did contribute the kernel, it was 3 or 4 commits... ~5 years
ago... to a driver.

And then there was one person who admitted that while he was just a
user, he insisted he had a right to weigh in the issue.  They
certainly have the right to have that belief, of course.  Whether or
not maintainers are obliged to cater to people with those beliefs is a
very different question, however.

There seems to be an assumption that a open, public discussion will
always give you the best review.  I don't think that's necessarily
true.  It can often give you a very biased sample from the poeple who
are most stridently on one side of the debate or the other, as well as
being biased towards those who believe in the "last post wins" style
of debate, since they end up speaking most loudly and posting most
frequently and most aggressively.

I found it very interesting that by explicitly asking the top ranked
developers by git statistics for comments and for their sign-off on
the various update patches, we got a much broader read on what people
thought, and received some very thoughtful comments --- from people
who had *not* engaged on the public threads.

At this point, Linus has indicated that he would prefer that we not
try to tweak the CoC any further, and let's see how it works out in
practice.  If new developers continue to report that they feel more
welcome, and we get more news reports like this:

https://www.zdnet.com/article/a-kinder-gentler-linus-torvalds-and-linux-4-20/

... and no one is getting kicked out of Linux development for being
politically incorrect, and the quality and quantity of kernel code
continues to increase, it'll all be good and we can spend most of our
time worrying about technical rather than political issues.

     	      	    	      	     	  - Ted

Re: [Ksummit-discuss] [Tech-board-discuss] TAB non-nomination

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

On Sun, Nov 11 2018, Theodore Y. Ts'o wrote:

> On Sat, Nov 10, 2018 at 07:18:00PM -0800, Frank Rowand wrote:
>> OK.  So the update was done in an opaque closed fashion, which involved
>> soliciting input from some unknown fraction of the community.  Do I
>> understand that correctly?
>> 
>> And I think it would be fair to say that the people who created the
>> update were probably aware of the comments of a much larger group of
>> people who had participated in the threads on various email lists,
>> and also I suspect the comments threads on the related lwn articles.
>> So likely also based on input from a (probably) larger fraction of
>> the community who had been willing to publicly comment.
>> 
>> So based on community input, but the document was not reviewed by the
>> broader community, or accepted by the broader community.
>
> "Community" is a very slippery term.  I will note that there were
> *many* people who were participating on the threads, sometimes in very
> non-constructive or in a downright toxic fashion, who had zero commits
> in recent years.  In some cases, it was zero commits, *ever*.  I
> recall doing the research on one prolific author and found that while
> he did contribute the kernel, it was 3 or 4 commits... ~5 years
> ago... to a driver.
>
> And then there was one person who admitted that while he was just a
> user, he insisted he had a right to weigh in the issue.  They
> certainly have the right to have that belief, of course.  Whether or
> not maintainers are obliged to cater to people with those beliefs is a
> very different question, however.
>
> There seems to be an assumption that a open, public discussion will
> always give you the best review.

Maybe not, but it does help create a sense of community.  It encourages
people to feel valued and included.

The new CoC suggests that our standards include

* Focusing on what is best for the community

Is having a perfect CoC best for the community?  Or is having an open
process best, even when it produces a suboptimal result?

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

On Sun, Nov 11 2018, Theodore Y. Ts'o wrote:

> On Sat, Nov 10, 2018 at 07:18:00PM -0800, Frank Rowand wrote:
>> OK.  So the update was done in an opaque closed fashion, which involved
>> soliciting input from some unknown fraction of the community.  Do I
>> understand that correctly?
>> 
>> And I think it would be fair to say that the people who created the
>> update were probably aware of the comments of a much larger group of
>> people who had participated in the threads on various email lists,
>> and also I suspect the comments threads on the related lwn articles.
>> So likely also based on input from a (probably) larger fraction of
>> the community who had been willing to publicly comment.
>> 
>> So based on community input, but the document was not reviewed by the
>> broader community, or accepted by the broader community.
>
> "Community" is a very slippery term.  I will note that there were
> *many* people who were participating on the threads, sometimes in very
> non-constructive or in a downright toxic fashion, who had zero commits
> in recent years.  In some cases, it was zero commits, *ever*.  I
> recall doing the research on one prolific author and found that while
> he did contribute the kernel, it was 3 or 4 commits... ~5 years
> ago... to a driver.
>
> And then there was one person who admitted that while he was just a
> user, he insisted he had a right to weigh in the issue.  They
> certainly have the right to have that belief, of course.  Whether or
> not maintainers are obliged to cater to people with those beliefs is a
> very different question, however.
>
> There seems to be an assumption that a open, public discussion will
> always give you the best review.

Maybe not, but it does help create a sense of community.  It encourages
people to feel valued and included.

The new CoC suggests that our standards include

* Focusing on what is best for the community

Is having a perfect CoC best for the community?  Or is having an open
process best, even when it produces a suboptimal result?

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [Ksummit-discuss] [Tech-board-discuss] TAB non-nomination

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

On Sun, Nov 11 2018, Theodore Y. Ts'o wrote:

>
> At this point, Linus has indicated that he would prefer that we not
> try to tweak the CoC any further, and let's see how it works out in
> practice.

I do love this.  Linus, who is apparently the cause of the problem, is
seen to be wise enough to be able to decide when we should start the
conversation, and when we should stop it.

To me, this just seems like Linus throwing his weight around in an area
where he has already demonstrated his incompetence.

Of course we cannot really see how the CoC "works out in practice"
because you changed two variables at once.  Linus decided to behave
differently and a CoC was "adopted".  We will never know which change
had which effect.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

On Sun, Nov 11 2018, Theodore Y. Ts'o wrote:

>
> At this point, Linus has indicated that he would prefer that we not
> try to tweak the CoC any further, and let's see how it works out in
> practice.

I do love this.  Linus, who is apparently the cause of the problem, is
seen to be wise enough to be able to decide when we should start the
conversation, and when we should stop it.

To me, this just seems like Linus throwing his weight around in an area
where he has already demonstrated his incompetence.

Of course we cannot really see how the CoC "works out in practice"
because you changed two variables at once.  Linus decided to behave
differently and a CoC was "adopted".  We will never know which change
had which effect.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [Ksummit-discuss] [Tech-board-discuss] TAB non-nomination

[Steven Rostedt]

On Mon, 12 Nov 2018 15:54:56 +1100
NeilBrown <neilb@suse.com> wrote:

> On Sun, Nov 11 2018, Theodore Y. Ts'o wrote:
> 
> >
> > At this point, Linus has indicated that he would prefer that we not
> > try to tweak the CoC any further, and let's see how it works out in
> > practice.  
> 
> I do love this.  Linus, who is apparently the cause of the problem, is
> seen to be wise enough to be able to decide when we should start the
> conversation, and when we should stop it.
> 
> To me, this just seems like Linus throwing his weight around in an area
> where he has already demonstrated his incompetence.

No, think if it this way. Code got into the kernel. Perhaps how it got
in wasn't the best way, but regardless it's in the kernel. Now we are
not going to touch it until someone shows that the code is actually
broken, with real examples. In other words, it's about not trying to
fix things for theoretical situations or hand waving. When it proves
that there is an actual bug, we'll fix it then.

I personally do not agree with this method, but I'm willing to try it
out. Linus has made that same argument for real code in the kernel
before.

-- Steve

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Steven Rostedt]

On Mon, 12 Nov 2018 15:54:56 +1100
NeilBrown <neilb@suse.com> wrote:

> On Sun, Nov 11 2018, Theodore Y. Ts'o wrote:
> 
> >
> > At this point, Linus has indicated that he would prefer that we not
> > try to tweak the CoC any further, and let's see how it works out in
> > practice.  
> 
> I do love this.  Linus, who is apparently the cause of the problem, is
> seen to be wise enough to be able to decide when we should start the
> conversation, and when we should stop it.
> 
> To me, this just seems like Linus throwing his weight around in an area
> where he has already demonstrated his incompetence.

No, think if it this way. Code got into the kernel. Perhaps how it got
in wasn't the best way, but regardless it's in the kernel. Now we are
not going to touch it until someone shows that the code is actually
broken, with real examples. In other words, it's about not trying to
fix things for theoretical situations or hand waving. When it proves
that there is an actual bug, we'll fix it then.

I personally do not agree with this method, but I'm willing to try it
out. Linus has made that same argument for real code in the kernel
before.

-- Steve

Re: [Ksummit-discuss] TAB non-nomination

[James Morris]

On Sat, 10 Nov 2018, Theodore Y. Ts'o wrote:

> On Fri, Nov 09, 2018 at 11:23:26AM -0800, Joe Perches wrote:
> > I believe that did not happen as described as at least
> > I was not asked for input/comment/sign-off and I ahm
> > well within that top 200 or so list.
> 
> I'm not sure precisely which metrics Greg used when he created his
> list, but using "git log --since="July 2017" v4.18" and piping it into
> the perl script I use to count Signed-off-by, Acked-by, and
> Reviewed-by, lines, you're about #240; so you're in the top 250, but
> not the top 200.

Please also consider maintainers who are pulling in sub-trees without 
adding signed-off-by to each patch.


-- 
James Morris
<jmorris@namei.org>

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[James Morris]

On Sat, 10 Nov 2018, Theodore Y. Ts'o wrote:

> On Fri, Nov 09, 2018 at 11:23:26AM -0800, Joe Perches wrote:
> > I believe that did not happen as described as at least
> > I was not asked for input/comment/sign-off and I ahm
> > well within that top 200 or so list.
> 
> I'm not sure precisely which metrics Greg used when he created his
> list, but using "git log --since="July 2017" v4.18" and piping it into
> the perl script I use to count Signed-off-by, Acked-by, and
> Reviewed-by, lines, you're about #240; so you're in the top 250, but
> not the top 200.

Please also consider maintainers who are pulling in sub-trees without 
adding signed-off-by to each patch.


-- 
James Morris
<jmorris@namei.org>

Re: [Ksummit-discuss] [Tech-board-discuss] TAB non-nomination

[Jani Nikula]

On Sun, 11 Nov 2018, "Theodore Y. Ts'o" <tytso@mit.edu> wrote:
> "Community" is a very slippery term.  I will note that there were
> *many* people who were participating on the threads, sometimes in very
> non-constructive or in a downright toxic fashion, who had zero commits
> in recent years.  In some cases, it was zero commits, *ever*.  I
> recall doing the research on one prolific author and found that while
> he did contribute the kernel, it was 3 or 4 commits... ~5 years
> ago... to a driver.
>
> And then there was one person who admitted that while he was just a
> user, he insisted he had a right to weigh in the issue.  They
> certainly have the right to have that belief, of course.  Whether or
> not maintainers are obliged to cater to people with those beliefs is a
> very different question, however.
>
> There seems to be an assumption that a open, public discussion will
> always give you the best review.  I don't think that's necessarily
> true.  It can often give you a very biased sample from the poeple who
> are most stridently on one side of the debate or the other, as well as
> being biased towards those who believe in the "last post wins" style
> of debate, since they end up speaking most loudly and posting most
> frequently and most aggressively.

I think it's interesting to note that ksummit-discuss seemed to be a
much more fruitful list for discussion than LKML in this matter. Would
we benefit from a non-technical mailing list to accompany LKML?
Something less "seasonal" than ksummit-discuss.

Could also restrict posting to subscribers only, with public archives,
and limit subscribers to, say, people in MAINTAINERS and/or some (fairly
low) number of required commits in the past years. I presume
ksummit-discuss had fairly good signal-to-noise because it's not well
known or publicized.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Jani Nikula]

On Sun, 11 Nov 2018, "Theodore Y. Ts'o" <tytso@mit.edu> wrote:
> "Community" is a very slippery term.  I will note that there were
> *many* people who were participating on the threads, sometimes in very
> non-constructive or in a downright toxic fashion, who had zero commits
> in recent years.  In some cases, it was zero commits, *ever*.  I
> recall doing the research on one prolific author and found that while
> he did contribute the kernel, it was 3 or 4 commits... ~5 years
> ago... to a driver.
>
> And then there was one person who admitted that while he was just a
> user, he insisted he had a right to weigh in the issue.  They
> certainly have the right to have that belief, of course.  Whether or
> not maintainers are obliged to cater to people with those beliefs is a
> very different question, however.
>
> There seems to be an assumption that a open, public discussion will
> always give you the best review.  I don't think that's necessarily
> true.  It can often give you a very biased sample from the poeple who
> are most stridently on one side of the debate or the other, as well as
> being biased towards those who believe in the "last post wins" style
> of debate, since they end up speaking most loudly and posting most
> frequently and most aggressively.

I think it's interesting to note that ksummit-discuss seemed to be a
much more fruitful list for discussion than LKML in this matter. Would
we benefit from a non-technical mailing list to accompany LKML?
Something less "seasonal" than ksummit-discuss.

Could also restrict posting to subscribers only, with public archives,
and limit subscribers to, say, people in MAINTAINERS and/or some (fairly
low) number of required commits in the past years. I presume
ksummit-discuss had fairly good signal-to-noise because it's not well
known or publicized.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Ksummit-discuss] [Tech-board-discuss] TAB non-nomination

[Laurent Pinchart]

Hi Jani,

On Tuesday, 13 November 2018 18:49:58 EET Jani Nikula wrote:
> On Sun, 11 Nov 2018, "Theodore Y. Ts'o" wrote:
> > "Community" is a very slippery term.  I will note that there were
> > *many* people who were participating on the threads, sometimes in very
> > non-constructive or in a downright toxic fashion, who had zero commits
> > in recent years.  In some cases, it was zero commits, *ever*.  I
> > recall doing the research on one prolific author and found that while
> > he did contribute the kernel, it was 3 or 4 commits... ~5 years
> > ago... to a driver.
> > 
> > And then there was one person who admitted that while he was just a
> > user, he insisted he had a right to weigh in the issue.  They
> > certainly have the right to have that belief, of course.  Whether or
> > not maintainers are obliged to cater to people with those beliefs is a
> > very different question, however.
> > 
> > There seems to be an assumption that a open, public discussion will
> > always give you the best review.  I don't think that's necessarily
> > true.  It can often give you a very biased sample from the poeple who
> > are most stridently on one side of the debate or the other, as well as
> > being biased towards those who believe in the "last post wins" style
> > of debate, since they end up speaking most loudly and posting most
> > frequently and most aggressively.
> 
> I think it's interesting to note that ksummit-discuss seemed to be a
> much more fruitful list for discussion than LKML in this matter. Would
> we benefit from a non-technical mailing list to accompany LKML?
> Something less "seasonal" than ksummit-discuss.

Or could it be because the list is less known by the general public, and thus 
not as targeted by trolls ? Maybe I'm being overly negative there, a new 
mailing list might help. We would need to make sure to get people to subscribe 
(yet another mailing list...), but on the other hand the much lower traffic 
compared to LKML might help regain people who are not subscribed to or just 
don't read LKML.

> Could also restrict posting to subscribers only, with public archives,
> and limit subscribers to, say, people in MAINTAINERS and/or some (fairly
> low) number of required commits in the past years.

Limiting subscription to MAINTAINERS would in my opinion keep out too many 
people with a real interest and useful feedback to provide. Limiting it to 
contributors would be better, even if possibly too limiting. We could 
experiment with that though and see how it works out.

In any case, if we want to restrict list subscription (or at least post 
rights) to kernel community members, we will need to answer the elephant in 
the room question: who is the kernel community ?

> I presume ksummit-discuss had fairly good signal-to-noise because it's not
> well known or publicized.

I should have read your whole e-mail before writing the reply :-)

-- 
Regards,

Laurent Pinchart

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Laurent Pinchart]

Hi Jani,

On Tuesday, 13 November 2018 18:49:58 EET Jani Nikula wrote:
> On Sun, 11 Nov 2018, "Theodore Y. Ts'o" wrote:
> > "Community" is a very slippery term.  I will note that there were
> > *many* people who were participating on the threads, sometimes in very
> > non-constructive or in a downright toxic fashion, who had zero commits
> > in recent years.  In some cases, it was zero commits, *ever*.  I
> > recall doing the research on one prolific author and found that while
> > he did contribute the kernel, it was 3 or 4 commits... ~5 years
> > ago... to a driver.
> > 
> > And then there was one person who admitted that while he was just a
> > user, he insisted he had a right to weigh in the issue.  They
> > certainly have the right to have that belief, of course.  Whether or
> > not maintainers are obliged to cater to people with those beliefs is a
> > very different question, however.
> > 
> > There seems to be an assumption that a open, public discussion will
> > always give you the best review.  I don't think that's necessarily
> > true.  It can often give you a very biased sample from the poeple who
> > are most stridently on one side of the debate or the other, as well as
> > being biased towards those who believe in the "last post wins" style
> > of debate, since they end up speaking most loudly and posting most
> > frequently and most aggressively.
> 
> I think it's interesting to note that ksummit-discuss seemed to be a
> much more fruitful list for discussion than LKML in this matter. Would
> we benefit from a non-technical mailing list to accompany LKML?
> Something less "seasonal" than ksummit-discuss.

Or could it be because the list is less known by the general public, and thus 
not as targeted by trolls ? Maybe I'm being overly negative there, a new 
mailing list might help. We would need to make sure to get people to subscribe 
(yet another mailing list...), but on the other hand the much lower traffic 
compared to LKML might help regain people who are not subscribed to or just 
don't read LKML.

> Could also restrict posting to subscribers only, with public archives,
> and limit subscribers to, say, people in MAINTAINERS and/or some (fairly
> low) number of required commits in the past years.

Limiting subscription to MAINTAINERS would in my opinion keep out too many 
people with a real interest and useful feedback to provide. Limiting it to 
contributors would be better, even if possibly too limiting. We could 
experiment with that though and see how it works out.

In any case, if we want to restrict list subscription (or at least post 
rights) to kernel community members, we will need to answer the elephant in 
the room question: who is the kernel community ?

> I presume ksummit-discuss had fairly good signal-to-noise because it's not
> well known or publicized.

I should have read your whole e-mail before writing the reply :-)

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] [Tech-board-discuss] TAB non-nomination

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

On Sun, Nov 11, 2018 at 12:57:28AM -0500, Theodore Y. Ts'o wrote:

> There seems to be an assumption that a open, public discussion will
> always give you the best review.  I don't think that's necessarily
> true.  It can often give you a very biased sample from the poeple who
> are most stridently on one side of the debate or the other, as well as
> being biased towards those who believe in the "last post wins" style
> of debate, since they end up speaking most loudly and posting most
> frequently and most aggressively.

> I found it very interesting that by explicitly asking the top ranked
> developers by git statistics for comments and for their sign-off on
> the various update patches, we got a much broader read on what people
> thought, and received some very thoughtful comments --- from people
> who had *not* engaged on the public threads.

One thing that other organisations that do this sort of consultation
process (which is very good and useful) do which didn't seem to happen
here is that they announce that this is going on.  This is useful
because it helps people know what's going on and can help make the
public discussion a bit more useful as a result.  If, as is common,
there's also some way for people to push in comments those can turn up
useful feedback that people you wouldn't have thought to ask aren't
comfortable providing in public though you'll also tend to get a lot of
noise in there as well if it's a contentious area so that's hard work.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

On Sun, Nov 11, 2018 at 12:57:28AM -0500, Theodore Y. Ts'o wrote:

> There seems to be an assumption that a open, public discussion will
> always give you the best review.  I don't think that's necessarily
> true.  It can often give you a very biased sample from the poeple who
> are most stridently on one side of the debate or the other, as well as
> being biased towards those who believe in the "last post wins" style
> of debate, since they end up speaking most loudly and posting most
> frequently and most aggressively.

> I found it very interesting that by explicitly asking the top ranked
> developers by git statistics for comments and for their sign-off on
> the various update patches, we got a much broader read on what people
> thought, and received some very thoughtful comments --- from people
> who had *not* engaged on the public threads.

One thing that other organisations that do this sort of consultation
process (which is very good and useful) do which didn't seem to happen
here is that they announce that this is going on.  This is useful
because it helps people know what's going on and can help make the
public discussion a bit more useful as a result.  If, as is common,
there's also some way for people to push in comments those can turn up
useful feedback that people you wouldn't have thought to ask aren't
comfortable providing in public though you'll also tend to get a lot of
noise in there as well if it's a contentious area so that's hard work.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Ksummit-discuss] TAB non-nomination

[Geert Uytterhoeven]

On Fri, Nov 9, 2018 at 8:03 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> On Fri, Nov 09, 2018 at 10:52:55AM -0700, Shuah Khan wrote:
> > >> The third mistake was dumping the fully formed CoC and a later update
> > >> into the tree with little to no community input
> >
> > It is unfortunate it had to start that way. I also understand at times it
> > might be necessary to do so based on my experience with the Linux Kernel
> > Community Enforcement Statement process. What should TAB do as a body if
> > it needs to take action without an option to initiate an open discussion?
>
> As Chris mentioned, there was a large amount of community input on the
> update.  It just didn't happen in an open fashion.  One of the
> challenges with e-mail discussion is that it can end up get dominated
> by a small number of people who send a large number of messages.  In
> an in-person meeting, a good moderator can say, "Alexis, you've been
> talking a lot; perhaps we should hear from some other people who have
> been quiet.  Drew, what do you think?"  It's a lot harder to do this
> on a mailing list.
>
> The second challenge is that we were getting trolled by people who
> were *not* members of the kernel development community.  I was able to
> track down one such troll to their social media presence on gab.ai.
> (Yeah, that same lovely "free speech absolutists' site, for when
> Twitter considers you too toxic" which got deplatformed after the
> shooting at the Tree of Life Synagogue in Pittsburgh.)
>
> So what was done with the update to the CoC was that a proposed set of
> changes was sent out to the top 200 or so contributors to the kernel,
> by git statistics over the past year, asking for their comments and
> their sign-offs.  So there *was* community input, and that input did
> result in changes to the CoC update.

Good to know this did result in changes. But probably only for the first
version?
I hadn't checked before, but the actual patches that went in are exactly
the same as the patches I acked.

Nevertheless, if one is asked through a private channel if one wants to ack
some patches that have already 10+ acks, there are basically 3 options
(excl. forcing a public disclosure):

  1. Ack the patch, if you (mostly) agree with it,
  2. Nak the patch, which probably won't have any effect, due to the private
     channel,
  3. Ask for changes to be made, which may be complicated, as the
     version you received already has several acks that may become
     invalid, and it's a private channel. Hence this may also don't have
     any effect.

So even if one considers option 3, depending on the amount and severity
of the changes one has in mind, option 1 might be the better option.
There are still opportunities for improvement later, quoting the second
patch "[...] can be seen as a bug, though; such bugs will be fixed more
quickly if any interested parties submit patches to that effect."...

However, the latest message seems to be "don't change the CoC anymore",
and no more patches have been (re)sent...
(Yes, I'm "guilty" here too, perhaps everyone is waiting for someone else
to (re)submit first?)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Tech-board-discuss] [Ksummit-discuss] TAB non-nomination

[Geert Uytterhoeven]

On Fri, Nov 9, 2018 at 8:03 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> On Fri, Nov 09, 2018 at 10:52:55AM -0700, Shuah Khan wrote:
> > >> The third mistake was dumping the fully formed CoC and a later update
> > >> into the tree with little to no community input
> >
> > It is unfortunate it had to start that way. I also understand at times it
> > might be necessary to do so based on my experience with the Linux Kernel
> > Community Enforcement Statement process. What should TAB do as a body if
> > it needs to take action without an option to initiate an open discussion?
>
> As Chris mentioned, there was a large amount of community input on the
> update.  It just didn't happen in an open fashion.  One of the
> challenges with e-mail discussion is that it can end up get dominated
> by a small number of people who send a large number of messages.  In
> an in-person meeting, a good moderator can say, "Alexis, you've been
> talking a lot; perhaps we should hear from some other people who have
> been quiet.  Drew, what do you think?"  It's a lot harder to do this
> on a mailing list.
>
> The second challenge is that we were getting trolled by people who
> were *not* members of the kernel development community.  I was able to
> track down one such troll to their social media presence on gab.ai.
> (Yeah, that same lovely "free speech absolutists' site, for when
> Twitter considers you too toxic" which got deplatformed after the
> shooting at the Tree of Life Synagogue in Pittsburgh.)
>
> So what was done with the update to the CoC was that a proposed set of
> changes was sent out to the top 200 or so contributors to the kernel,
> by git statistics over the past year, asking for their comments and
> their sign-offs.  So there *was* community input, and that input did
> result in changes to the CoC update.

Good to know this did result in changes. But probably only for the first
version?
I hadn't checked before, but the actual patches that went in are exactly
the same as the patches I acked.

Nevertheless, if one is asked through a private channel if one wants to ack
some patches that have already 10+ acks, there are basically 3 options
(excl. forcing a public disclosure):

  1. Ack the patch, if you (mostly) agree with it,
  2. Nak the patch, which probably won't have any effect, due to the private
     channel,
  3. Ask for changes to be made, which may be complicated, as the
     version you received already has several acks that may become
     invalid, and it's a private channel. Hence this may also don't have
     any effect.

So even if one considers option 3, depending on the amount and severity
of the changes one has in mind, option 1 might be the better option.
There are still opportunities for improvement later, quoting the second
patch "[...] can be seen as a bug, though; such bugs will be fixed more
quickly if any interested parties submit patches to that effect."...

However, the latest message seems to be "don't change the CoC anymore",
and no more patches have been (re)sent...
(Yes, I'm "guilty" here too, perhaps everyone is waiting for someone else
to (re)submit first?)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds