commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [ALL] The Commons Math issue
Date Tue, 18 Apr 2017 13:42:25 GMT
Hello Stefan.

On Tue, 18 Apr 2017 10:15:20 +0200, Stefan Bodewig wrote:
> [sorry, been offline for a few days and don't want to re-start a 
> thread
> that seems to have come to a conclusion, just need to clarify one 
> thing]

I think that you have highlighted why "Commons" ways did not
work for CM.

> On 2017-04-14, Gilles 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:
>>>>> 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...
>>> 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.
>> English is not my native language, but I don't think that the
>> sentence you refer to contains anything offensive: "one" is not
>> "you".
> Thank you.
> The way to construct the attack is that I talk about me and you talk
> about "one" and I had no reason to assume the "one" could be anybody
> other than me. I'm still not sure why you said the above at all as
> Emmanuel wasn't participating in the conversation at all.

Because I wished that we consider concrete examples of what went
wrong, in order to improve everybody's experience here.

A general assumption that "nobody's is malicious", even when true,
is not helping.

> Thanks for clarifying it.
>>>> 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.
> Well, that's because we are all individuals. :-)
> For Commons it is more difficult to form a community than for most
> "normal" ASF projects as the least common denominator is much
> smaller. In "normal" project you've got a product vision and a shared
> code base to align folks.

"Commons Math" is a perfect example of "non-alignment":
  * no common vision
  * no shared code base
[In the past, I argued about them terribly lacking in CM,
so I'll not expand again here...]

Creating focused components is bent to solve those two issues.
[And consequently, the "rules" (or absence thereof) that worked
for other "Commons" components (i.e. real ones) will work for the
CM spin-offs too.]

> All we've got is the goal to produce something
> useful - where many of us have different ideas of what will be useful 
> -

And that's why "do-ocracy" should really matter more than

> and the idea of doing so via collaboration.
> IMHO we need to accept that we are a pretty diverse bunch of
> people. We've got different reasons for being here and we are 
> certainly
> different in our approaches of reaching our goals. Mutual respect is
> what can bind us - and I believe this is what was lost in the MATH 
> case.

It is a fact that the people who forked it did not search for
consensus. [The ML archive is proof of it.]

They and I had different priorities, but they did not accept
such a "diversity": Not changing the code became more important
than improving the shared experience.

>> There are low-level requirements (naming of releases, vote counts,
>> etc.), but hardly any policies.
> Well, some of us may enjoy working here because we don't have that 
> many
> rules and policies. I think I am one of those.

"Diversity" and "no rules" do not go along very well (as in the
real world).
When "no rules" work (here), it is because it is usually easy to
see the best one from a few technical alternatives.
I'm convinced that it will be so too with any of the components
that have a "math" flavour.

Simply, whenever possible it is better to have that code supported
here rather than duplicated on yet another GitHub project.


> Stefan

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message