[openstack-dev] [all][tc] Lets keep our community open, lets fight for it

Nikola Đipanov ndipanov at redhat.com
Wed Feb 11 11:53:24 UTC 2015


+ Inf for writing this Flavio!

Only some observations below.

On 02/11/2015 10:55 AM, Flavio Percoco wrote:
> Greetings all,
> 
> During the last two cycles, I've had the feeling that some of the
> things I love the most about this community are degrading and moving
> to a state that I personally disagree with. With the hope of seeing
> these things improve, I'm taking the time today to share one of my
> concerns.
> 
> Since I believe we all work with good faith and we *all* should assume
> such when it comes to things happening in our community, I won't make
> names and I won't point fingers - yes, I don't have enough fingers to
> point based on the info I have. People that fall into the groups I'll
> mention below know that I'm talking to them.
> 
> This email is dedicated to the openness of our community/project.
> 
> ## Keep discussions open
> 
> I don't believe there's anything wrong about kicking off some
> discussions in private channels about specs/bugs. I don't believe
> there's anything wrong in having calls to speed up some discussions.
> HOWEVER, I believe it's *completely* wrong to consider those private
> discussions sufficient. If you have had that kind of private
> discussions, if you've discussed a spec privately and right after you
> went upstream and said: "This has been discussed in a call and it's
> good to go", I beg you to stop for 2 seconds and reconsider that. I
> don't believe you were able to fit all the community in that call and
> that you had enough consensus.
> 
> Furthermore, you should consider that having private conversations, at
> the very end, doesn't help with speeding up discussions. We've a
> community of people who *care* about the project they're working on.
> This means that whenever they see something that doesn't make much
> sense, they'll chime in and ask for clarification. If there was a
> private discussion on that topic, you'll have to provide the details
> of such discussion and bring that person up to date, which means the
> discussion will basically start again... from scratch.
> 
> ## Mailing List vs IRC Channel
> 
> I get it, our mailing list is freaking busy, keeping up with it is
> hard and time consuming and that leads to lots of IRC discussions. I
> don't think there's anything wrong with that but I believe it's wrong
> to expect *EVERYONE* to be in the IRC channel when those discussions
> happen.
> 
> If you are discussing something on IRC that requires the attention of
> most of your project's community, I highly recommend you to use the
> mailing list as oppose to pinging everyone independently and fighting
> with time zones. Using IRC bouncers as a replacement for something
> that should go to the mailing list is absurd. Please, use the mailing
> list and don't be afraid of having a bigger community chiming in in
> your discussion.  *THAT'S A GOOD THING*
> 
> Changes, specs, APIs, etc. Everything is good for the mailing list.
> We've fought hard to make this community grow, why shouldn't we take
> advantage of it?
> 

I think the above 2 are somewhat intertwined with another trend in the
community I've personally noticed towards the end of the Juno cycle,
that I also strongly believe needs to DIAFF.

An idea that it is possible to "manage" and open source community using
similar methods that are commonly used for managing subordinates in a
corporate hierarchy.

There are other (somewhat less) horrible examples around, and they all
came about as a (IMHO knee jerk) response to explosive growth, and they
all need to stop.

I urge people who are seen as leaders in their respective projects to
stop and think the next time they want to propose a "policy change" or a
"process" - ask yourself "Is there an OSS project that does something
similar successfully, or have I seen this from our old PM?" and then not
propose it if the answer is clearly that this will help the distributed
workflow of an OSS community.

On 02/11/2015 11:29 AM, Thierry Carrez wrote:
>> This is the point where my good faith assumption skill falls short.
>> Seriously, don't get me wrong but: WHAT IN THE ACTUAL F**K?
>>
>> THERE IS ABSOLUTELY NOTHING PRIVATE FOR CORE ****REVIEWERS***** TO
>> DISCUSS.
>>
>> If anything core reviewers should be the ones *FORCING* - it seems
>> that *encouraging* doesn't have the same effect anymore - *OPENNESS* in
>> order to include other non-core members in those discussions.
>>
>> Remember that the "core" flag is granted because of the reviews that
>> person has provided and because that individual *WANTS* to be part of
>> it. It's not a prize for people. In fact, I consider core reviewers to
>> be volunteers and their job is infinitely thanked.
>
> +1000
>
> Core reviewing has always be designed to be a duty, not a badge. There
> has been a trends toward making it a badge, with some companies giving
> bonuses to core reviewers, and HP making +2 pins and throwing +2
> parties. I think that's a significant mistake and complained about it,
> but then my influence only goes that far.
>
> The problem with special rights (like +2) is that if you don't actively
> resist it, they naturally turn into an aristocracy (especially when only
> existing cores vote on new cores). That aristocracy then usually turns
> into a clique which is excluding new blood and new opinions, and then
> that project slowly dies.
>

We cannot prevent people from attempting to use an economic leverage to
try to exert influence. We can and should stop incentivizing it
aggressively if it threatens to jeopardize the well being of the
community. That's what governance is for.

There are a number of ways to do this, some of which may have to strike
at the foundation of the way we have been organizing ourselves. I look
forward to this discussion happening and hope for the right response!

N.





More information about the OpenStack-dev mailing list