Re: Advice for community participation to lower tension

[Shane Curcuru]

Now published on the ComDev site:

  http://community.apache.org/contributors/etiquette

Improvements welcome.  Note that ComDev is primarily introductory
materials, and plenty of pointers to canonical sources of information
(like policies, apache.org/dev pages, and the like).  So this is in no
way a replacement for the Code of Conduct or similar pages, but more of
an introduction.

- Shane

Re: Advice for community participation to lower tension

[Greg Chase]

Reposted to StackExchange - Community Building
,
and it seems to be appreciated.

On Fri, Apr 8, 2016 at 8:37 PM, Niclas Hedhman  wrote:

> Feel free to do whatever you want...
>
> The only other "source" is general advice given on mailing lists at ASF and
> elsewhere, that I "consumed" into my consciousness, tried and filtered. No
> verbatim source exist.
>
> Cheers
> Niclas
>
> On Sat, Apr 9, 2016 at 11:17 AM, Greg Chase  wrote:
>
> > This is excellent. I hope you don't mind if I fork this!
> >
> > Are you the original source or is there another place that deserves
> credit
> > as well?
> >
> > This email encrypted by tiny buttons & fat thumbs, beta voice
> recognition,
> > and autocorrect on my iPhone.
> >
> > > On Apr 8, 2016, at 6:50 PM, Niclas Hedhman  wrote:
> > >
> > > Everyone,
> > > recently there was some tension/friction in a community, and I posted
> the
> > > following advice to everyone to better get along. Not only did the
> > > community members responded positively, but I also got pinged privately
> > to
> > > make this available publicly, so here it is, and I will let the wider
> > > community do with it what it sees fit...
> > >
> > >
> > > First a few general guidelines;
> > >  a. Assume that the other party agrees more than disagrees with you. We
> > > tend to leave out agreements and focus on differences. Sometime this is
> > > forgotten and escalation becomes absurd for no rational reason.
> > >
> > >  b. When in doubt, assume that you are interpreting the message wrongly
> > > and kindly ask for verification that you understood a particular topic
> > well.
> > >
> > >  c. When writing, assume that every sentence will be misinterpreted.
> > > Review and try to reformulate to be as clear as possible.
> > >
> > >  d. Use a submissive tone in all writing. Instead of the strong "In my
> > > opinion, we must..." or the quite neutral "I think we should...", try
> to
> > > use "Maybe we should consider..." or "Another idea that we could..."
> > >
> > >   e. If you disagree strongly with an email sent, tag it Important,
> then
> > > put it aside. Read it half a day later again. Put it aside. Read it
> again
> > > next day, and then it is easier to write a balanced and inviting
> > response,
> > > instead of the initial vitriol that flows through us when we get
> upset. I
> > > found that sometimes a response wouldn't be necessary, as the
> importance
> > > was actually much lower than originally perceived, and I would be able
> to
> > > work "with", instead of "against", a given change.
> > >
> > >  f. Be forgiving and accept different priorities. The other person is
> not
> > > out to get you or attack your work. More often than not, it is one of
> the
> > > above (a-d) that are failing, or that the other person prioritize some
> > > aspect higher than you do. Sometimes, this requires compromises,
> > sometimes
> > > not and the different priorities can co-exist.
> > >
> > >
> > > Most communities at Apache consists of level-headed, reasonable people,
> > who
> > > have a strong vested interest in its Apache project. This interest,
> often
> > > passion, is both the source of tension, but it is also what unites the
> > > people within the community. It is easy to forget the vast amount of
> > > agreement that exists, and get upset over relatively small
> disagreements.
> > > Ability to put that aside, or downplay the importance, will ensure a
> > > harmonious project.
> > >
> > > Face-to-Face is excellent way to eliminate disagreements, but that is
> > often
> > > not practical. Consider Skype or Google Hangout, just for the social
> > aspect
> > > of being part of this community. It should not be formal, and the
> > > invitation should go out to everyone, perhaps someone want to make a
> > short
> > > presentation of what he/she is doing, to have some "structure", but
> that
> > > might not be needed either. Once we have a face to the words, and a
> > general
> > > idea how that person is socially, we are much more capable to interact
> by
> > > email.
> > >
> > >
> > > Cheers
> > > --
> > > Niclas Hedhman, Software Developer
> > > http://zest.apache.org - New Energy for Java
> >
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>

Re: Advice for community participation to lower tension

[Niclas Hedhman]

Don't count on it... Too much to do.
On Apr 9, 2016 18:20, "Ulrich Stärk"  wrote:

> Thanks Niclas!
>
> Any chance you can find the time to put this up at community.apache.org?
>
> Cheers,
>
> Uli
>
> On 09/04/16 03:50, Niclas Hedhman wrote:
> > Everyone,
> > recently there was some tension/friction in a community, and I posted the
> > following advice to everyone to better get along. Not only did the
> > community members responded positively, but I also got pinged privately
> to
> > make this available publicly, so here it is, and I will let the wider
> > community do with it what it sees fit...
> >
> >
> > First a few general guidelines;
> >   a. Assume that the other party agrees more than disagrees with you. We
> > tend to leave out agreements and focus on differences. Sometime this is
> > forgotten and escalation becomes absurd for no rational reason.
> >
> >   b. When in doubt, assume that you are interpreting the message wrongly
> > and kindly ask for verification that you understood a particular topic
> well.
> >
> >   c. When writing, assume that every sentence will be misinterpreted.
> > Review and try to reformulate to be as clear as possible.
> >
> >   d. Use a submissive tone in all writing. Instead of the strong "In my
> > opinion, we must..." or the quite neutral "I think we should...", try to
> > use "Maybe we should consider..." or "Another idea that we could..."
> >
> >e. If you disagree strongly with an email sent, tag it Important, then
> > put it aside. Read it half a day later again. Put it aside. Read it again
> > next day, and then it is easier to write a balanced and inviting
> response,
> > instead of the initial vitriol that flows through us when we get upset. I
> > found that sometimes a response wouldn't be necessary, as the importance
> > was actually much lower than originally perceived, and I would be able to
> > work "with", instead of "against", a given change.
> >
> >   f. Be forgiving and accept different priorities. The other person is
> not
> > out to get you or attack your work. More often than not, it is one of the
> > above (a-d) that are failing, or that the other person prioritize some
> > aspect higher than you do. Sometimes, this requires compromises,
> sometimes
> > not and the different priorities can co-exist.
> >
> >
> > Most communities at Apache consists of level-headed, reasonable people,
> who
> > have a strong vested interest in its Apache project. This interest, often
> > passion, is both the source of tension, but it is also what unites the
> > people within the community. It is easy to forget the vast amount of
> > agreement that exists, and get upset over relatively small disagreements.
> > Ability to put that aside, or downplay the importance, will ensure a
> > harmonious project.
> >
> > Face-to-Face is excellent way to eliminate disagreements, but that is
> often
> > not practical. Consider Skype or Google Hangout, just for the social
> aspect
> > of being part of this community. It should not be formal, and the
> > invitation should go out to everyone, perhaps someone want to make a
> short
> > presentation of what he/she is doing, to have some "structure", but that
> > might not be needed either. Once we have a face to the words, and a
> general
> > idea how that person is socially, we are much more capable to interact by
> > email.
> >
> >
> > Cheers
> >
>

Re: Advice for community participation to lower tension

[Ulrich Stärk]

Thanks Niclas!

Any chance you can find the time to put this up at community.apache.org?

Cheers,

Uli

On 09/04/16 03:50, Niclas Hedhman wrote:
> Everyone,
> recently there was some tension/friction in a community, and I posted the
> following advice to everyone to better get along. Not only did the
> community members responded positively, but I also got pinged privately to
> make this available publicly, so here it is, and I will let the wider
> community do with it what it sees fit...
> 
> 
> First a few general guidelines;
>   a. Assume that the other party agrees more than disagrees with you. We
> tend to leave out agreements and focus on differences. Sometime this is
> forgotten and escalation becomes absurd for no rational reason.
> 
>   b. When in doubt, assume that you are interpreting the message wrongly
> and kindly ask for verification that you understood a particular topic well.
> 
>   c. When writing, assume that every sentence will be misinterpreted.
> Review and try to reformulate to be as clear as possible.
> 
>   d. Use a submissive tone in all writing. Instead of the strong "In my
> opinion, we must..." or the quite neutral "I think we should...", try to
> use "Maybe we should consider..." or "Another idea that we could..."
> 
>e. If you disagree strongly with an email sent, tag it Important, then
> put it aside. Read it half a day later again. Put it aside. Read it again
> next day, and then it is easier to write a balanced and inviting response,
> instead of the initial vitriol that flows through us when we get upset. I
> found that sometimes a response wouldn't be necessary, as the importance
> was actually much lower than originally perceived, and I would be able to
> work "with", instead of "against", a given change.
> 
>   f. Be forgiving and accept different priorities. The other person is not
> out to get you or attack your work. More often than not, it is one of the
> above (a-d) that are failing, or that the other person prioritize some
> aspect higher than you do. Sometimes, this requires compromises, sometimes
> not and the different priorities can co-exist.
> 
> 
> Most communities at Apache consists of level-headed, reasonable people, who
> have a strong vested interest in its Apache project. This interest, often
> passion, is both the source of tension, but it is also what unites the
> people within the community. It is easy to forget the vast amount of
> agreement that exists, and get upset over relatively small disagreements.
> Ability to put that aside, or downplay the importance, will ensure a
> harmonious project.
> 
> Face-to-Face is excellent way to eliminate disagreements, but that is often
> not practical. Consider Skype or Google Hangout, just for the social aspect
> of being part of this community. It should not be formal, and the
> invitation should go out to everyone, perhaps someone want to make a short
> presentation of what he/she is doing, to have some "structure", but that
> might not be needed either. Once we have a face to the words, and a general
> idea how that person is socially, we are much more capable to interact by
> email.
> 
> 
> Cheers
> 

Re: Advice for community participation to lower tension

[Niclas Hedhman]

Feel free to do whatever you want...

The only other "source" is general advice given on mailing lists at ASF and
elsewhere, that I "consumed" into my consciousness, tried and filtered. No
verbatim source exist.

Cheers
Niclas

On Sat, Apr 9, 2016 at 11:17 AM, Greg Chase  wrote:

> This is excellent. I hope you don't mind if I fork this!
>
> Are you the original source or is there another place that deserves credit
> as well?
>
> This email encrypted by tiny buttons & fat thumbs, beta voice recognition,
> and autocorrect on my iPhone.
>
> > On Apr 8, 2016, at 6:50 PM, Niclas Hedhman  wrote:
> >
> > Everyone,
> > recently there was some tension/friction in a community, and I posted the
> > following advice to everyone to better get along. Not only did the
> > community members responded positively, but I also got pinged privately
> to
> > make this available publicly, so here it is, and I will let the wider
> > community do with it what it sees fit...
> >
> >
> > First a few general guidelines;
> >  a. Assume that the other party agrees more than disagrees with you. We
> > tend to leave out agreements and focus on differences. Sometime this is
> > forgotten and escalation becomes absurd for no rational reason.
> >
> >  b. When in doubt, assume that you are interpreting the message wrongly
> > and kindly ask for verification that you understood a particular topic
> well.
> >
> >  c. When writing, assume that every sentence will be misinterpreted.
> > Review and try to reformulate to be as clear as possible.
> >
> >  d. Use a submissive tone in all writing. Instead of the strong "In my
> > opinion, we must..." or the quite neutral "I think we should...", try to
> > use "Maybe we should consider..." or "Another idea that we could..."
> >
> >   e. If you disagree strongly with an email sent, tag it Important, then
> > put it aside. Read it half a day later again. Put it aside. Read it again
> > next day, and then it is easier to write a balanced and inviting
> response,
> > instead of the initial vitriol that flows through us when we get upset. I
> > found that sometimes a response wouldn't be necessary, as the importance
> > was actually much lower than originally perceived, and I would be able to
> > work "with", instead of "against", a given change.
> >
> >  f. Be forgiving and accept different priorities. The other person is not
> > out to get you or attack your work. More often than not, it is one of the
> > above (a-d) that are failing, or that the other person prioritize some
> > aspect higher than you do. Sometimes, this requires compromises,
> sometimes
> > not and the different priorities can co-exist.
> >
> >
> > Most communities at Apache consists of level-headed, reasonable people,
> who
> > have a strong vested interest in its Apache project. This interest, often
> > passion, is both the source of tension, but it is also what unites the
> > people within the community. It is easy to forget the vast amount of
> > agreement that exists, and get upset over relatively small disagreements.
> > Ability to put that aside, or downplay the importance, will ensure a
> > harmonious project.
> >
> > Face-to-Face is excellent way to eliminate disagreements, but that is
> often
> > not practical. Consider Skype or Google Hangout, just for the social
> aspect
> > of being part of this community. It should not be formal, and the
> > invitation should go out to everyone, perhaps someone want to make a
> short
> > presentation of what he/she is doing, to have some "structure", but that
> > might not be needed either. Once we have a face to the words, and a
> general
> > idea how that person is socially, we are much more capable to interact by
> > email.
> >
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://zest.apache.org - New Energy for Java
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Advice for community participation to lower tension

[Greg Chase]

This is excellent. I hope you don't mind if I fork this!

Are you the original source or is there another place that deserves credit as 
well?

This email encrypted by tiny buttons & fat thumbs, beta voice recognition, and 
autocorrect on my iPhone.

> On Apr 8, 2016, at 6:50 PM, Niclas Hedhman  wrote:
> 
> Everyone,
> recently there was some tension/friction in a community, and I posted the
> following advice to everyone to better get along. Not only did the
> community members responded positively, but I also got pinged privately to
> make this available publicly, so here it is, and I will let the wider
> community do with it what it sees fit...
> 
> 
> First a few general guidelines;
>  a. Assume that the other party agrees more than disagrees with you. We
> tend to leave out agreements and focus on differences. Sometime this is
> forgotten and escalation becomes absurd for no rational reason.
> 
>  b. When in doubt, assume that you are interpreting the message wrongly
> and kindly ask for verification that you understood a particular topic well.
> 
>  c. When writing, assume that every sentence will be misinterpreted.
> Review and try to reformulate to be as clear as possible.
> 
>  d. Use a submissive tone in all writing. Instead of the strong "In my
> opinion, we must..." or the quite neutral "I think we should...", try to
> use "Maybe we should consider..." or "Another idea that we could..."
> 
>   e. If you disagree strongly with an email sent, tag it Important, then
> put it aside. Read it half a day later again. Put it aside. Read it again
> next day, and then it is easier to write a balanced and inviting response,
> instead of the initial vitriol that flows through us when we get upset. I
> found that sometimes a response wouldn't be necessary, as the importance
> was actually much lower than originally perceived, and I would be able to
> work "with", instead of "against", a given change.
> 
>  f. Be forgiving and accept different priorities. The other person is not
> out to get you or attack your work. More often than not, it is one of the
> above (a-d) that are failing, or that the other person prioritize some
> aspect higher than you do. Sometimes, this requires compromises, sometimes
> not and the different priorities can co-exist.
> 
> 
> Most communities at Apache consists of level-headed, reasonable people, who
> have a strong vested interest in its Apache project. This interest, often
> passion, is both the source of tension, but it is also what unites the
> people within the community. It is easy to forget the vast amount of
> agreement that exists, and get upset over relatively small disagreements.
> Ability to put that aside, or downplay the importance, will ensure a
> harmonious project.
> 
> Face-to-Face is excellent way to eliminate disagreements, but that is often
> not practical. Consider Skype or Google Hangout, just for the social aspect
> of being part of this community. It should not be formal, and the
> invitation should go out to everyone, perhaps someone want to make a short
> presentation of what he/she is doing, to have some "structure", but that
> might not be needed either. Once we have a face to the words, and a general
> idea how that person is socially, we are much more capable to interact by
> email.
> 
> 
> Cheers
> -- 
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java

Advice for community participation to lower tension

[Niclas Hedhman]

Everyone,
recently there was some tension/friction in a community, and I posted the
following advice to everyone to better get along. Not only did the
community members responded positively, but I also got pinged privately to
make this available publicly, so here it is, and I will let the wider
community do with it what it sees fit...


First a few general guidelines;
  a. Assume that the other party agrees more than disagrees with you. We
tend to leave out agreements and focus on differences. Sometime this is
forgotten and escalation becomes absurd for no rational reason.

  b. When in doubt, assume that you are interpreting the message wrongly
and kindly ask for verification that you understood a particular topic well.

  c. When writing, assume that every sentence will be misinterpreted.
Review and try to reformulate to be as clear as possible.

  d. Use a submissive tone in all writing. Instead of the strong "In my
opinion, we must..." or the quite neutral "I think we should...", try to
use "Maybe we should consider..." or "Another idea that we could..."

   e. If you disagree strongly with an email sent, tag it Important, then
put it aside. Read it half a day later again. Put it aside. Read it again
next day, and then it is easier to write a balanced and inviting response,
instead of the initial vitriol that flows through us when we get upset. I
found that sometimes a response wouldn't be necessary, as the importance
was actually much lower than originally perceived, and I would be able to
work "with", instead of "against", a given change.

  f. Be forgiving and accept different priorities. The other person is not
out to get you or attack your work. More often than not, it is one of the
above (a-d) that are failing, or that the other person prioritize some
aspect higher than you do. Sometimes, this requires compromises, sometimes
not and the different priorities can co-exist.


Most communities at Apache consists of level-headed, reasonable people, who
have a strong vested interest in its Apache project. This interest, often
passion, is both the source of tension, but it is also what unites the
people within the community. It is easy to forget the vast amount of
agreement that exists, and get upset over relatively small disagreements.
Ability to put that aside, or downplay the importance, will ensure a
harmonious project.

Face-to-Face is excellent way to eliminate disagreements, but that is often
not practical. Consider Skype or Google Hangout, just for the social aspect
of being part of this community. It should not be formal, and the
invitation should go out to everyone, perhaps someone want to make a short
presentation of what he/she is doing, to have some "structure", but that
might not be needed either. Once we have a face to the words, and a general
idea how that person is socially, we are much more capable to interact by
email.


Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java