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.
Exactly!
"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
"opinion".
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.
Regards,
Gilles
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
