It seems to me that some of these issues are likely unavoidable. The
comment on this thread that resonated with me most was something like "I
don't look at Jiras of projects I don't care about". I could say "I have
been guilty of that behavior" but there is IMO nothing wrong with this
behavior. Commons is large and some components are large and non-trivial,
aside from Math (or should it be Maths ;) my native language is French but
I think it is "Maths" in the U.K.

All of this leads me to think that when one wants to discuss potentially
disruptive topics like splitting up a component or moving it to a TLP,
there is an extra level of presentation that is required when the component
is large or complex. Especially when one is trying to build consensus from
a diverse group of folks such as ours where it is well know that not every
person knows or care about every component.

What I mean about an extra level of presentation is a detailed description
with an explanation of size, scope and complexity of the various packages.
Maybe this is all on the component site already, maybe not. In the case of
Math, this might have helped non-CM devs become better aware of the big
picture.

It turns out that for Math, this kind of discussion might have been just
too onerous for the people that ended up forking Math into Hipowhatnot.

I can imagine that those folks just found it simpler and easier to just
move to a different place to keep coding as they saw fit.

At this point and based on memory of looking at the Math code base, I would
be OK with a TLP.

Long ramble done.

Gary


On Apr 14, 2017 9:12 AM, "Gilles" <gil...@harfang.homelinux.org> wrote:

On Fri, 14 Apr 2017 16:34:22 +0200, Stefan Bodewig wrote:

> On 2017-04-13, Gilles wrote:
>
> On Thu, 13 Apr 2017 11:53:27 +0200, Stefan Bodewig wrote:
>>
>>> On 2017-04-12, Gilles wrote:
>>>
>>
> [Reminder: a big part of "Commons RNG" was developed inside CM and
>>>> most PMC people did not even know about it (although I was opening
>>>> JIRA issues all along.  Hence creating a "git" repository is not
>>>> futile if it can raise awareness.]
>>>>
>>>
> By now you've probably learned that people won't look at JIRA issues
>>> raised for components they don't work on. At least I don't :-)
>>>
>>
> A priori, I don't have any problem with an individual taking that
>> stance. [I do it too, because a day is only 24 hours long.]
>>
>
> But then, one is not entitled to claim a say about the issues which
>> he let pass...
>>
>
> I don't recall ever claiming anything like this.
>
> Not sure what you are trying to say here. It could be that you are
> trying to attack me but I hope you are not. Email is a difficult beast,
> in particular emails written in a foreign language (German is my native
> language and I don't think English is yours, either, there is lot of
> room for misunderstandings).
>

Stefan,

English is not my native language, but I don't think that the
sentence you refer to contains anything offensive: "one" is not
"you".

[I can be clearer: I had this issue with Emmanuel, about the
design and scope of "Commons RNG" (cf. ML archive), and it was
acknowledged that "do-ocracy" must prevail over "opinion".]



> I prefer the "small steps" approach taken with RNG and NUMBERS.
>>>
>>
> That's what I've been advocating all along.
>>
>
> Fine, then we all seem to be on the same page. Let's move on.
>
> I read you expect the PMC to do something, but unfortunately I don't
>>> understand what it is that you want the PMC to do. Maybe we are are
>>> interpreting the role of the PMC differently.
>>>
>>
> In what way has the integrity of the Commons project been endangered?
>>> I've seen people fork the code of MATH - which is fine by our license
>>> - and move to work in a different environment - which is their choice
>>> and I'm not willing to judge them.
>>>
>>
> And I think that the PMC has been wrong in passively accepting the
>> "surprise" fork.
>>
>
> Oops, I thought you were talking about the PMC harming MATH right now,
> after all you started the thread based on the report for the past
> quarter, not years ago. I'm sorry I misunderstood you.
>
> Because it came from _inside_ the community, the PMC would have
>> been right to demand that a reasonable attempt be made at exposing
>> the reasons, and at trying to fix issues while preserving the
>> community.
>>
>
> I was hurt by the fork, and the way it happened.  And I was hurt that
>> the PMC did not see anything wrong in "community fellows" keeping me
>> in the dark for five months, to work alone on a doomed project, while
>> they were sneakily setting up an alternative environment.
>>
>
> I understand the action hurt you. Absolutely.
>
> On the road that led to people starting their fork somewhere else there
> have been lots of heated arguments. It looked like bad flame-wars that
> happen in other communities as well and yes, the PMC should probably
> have tried to stop them and remind people to treat each other with
> respect. We didn't and I think this has been acknowledged in the past. I
> don't have the links ready but I know several PMC members have said so
> already.  We try to learn from it.
>
> We don't need to tell the board that we are still trying to do better
> with each report, though. :-)
>
> To be frank my recollection of said arguments is not one where one side
> was the reasonable voice and victim of attacks while the other side was
> wielding flame-throwers. We should have called out *all* of you.
>

I know that I can be stubborn, the more so when I think that I'm
right and when all the codes and references I can find point in the
same direction.
Calling off a "flame-war" is necessary, but sometimes not sufficient.

In the particular case I have in mind, _all_ the PMC members should
have at least quickly browsed through the arguments:
  http://markmail.org/message/uiljlf63uucnfyy2

In my necessarily biased opinion, the above was obviously showing
that one side of argument was presenting all the facts while the
other rested on pure speculation.


As to the action of forking itself, I still don't see anything the PMC
> should have done about it. We should have interfered before it
> happened. That doesn't mean I'm convinced that we could have been
> successfull back then.
>

When the fork was announced, it was too late, indeed.
Because the move was kept secret; in blatant contradiction with
the touted "open" and "consensus" and "community" buzzwords.



> I've seen you sticking around to work on MATH and keeping the parts
>>> alive that you care deeply about and finding new contributors that
>>> share those goal - which is great.
>>>
>>
> Or stupid...
>>
>
> No more stupid than most of us working on any other component in their
> spare time.
>
> The PMC has not been standing in the way of RNG or NUMBERS, maybe
>>> discussions have been taking longer than you'd have wanted.
>>>
>>
> Yes that's one of the things that prevent "do-ocracy": someone
>> willing to do the work is stalled by (non-technical) arguments
>> from someone not intending to back them with actual work (same
>> reference):
>>
>
> That's the price of consensus. You don't get to choose who needs to
> agree with you, you have to convince all people who show up. This takes
> time and drains energy. Yes, a dictator style development approach can
> move a lot faster. This is a drawback of consensus based development
> that we have accepted, or else we'd all by playing with our github repos
> on our own.
>

It's also my opinion that we are more strongly contributing
to the open source model by being a team.
But I often have the feeling that the PMC operates as an
aggregate of individualities rather than as a community.
There are low-level requirements (naming of releases, vote
counts, etc.), but hardly any policies.

I'm convinced that it can hurt the community as it can hurt
individual contributors.
Both happened as we should all be able to see.

Thanks for your attention,
Gilles



> Stefan
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to