Dear all (particulary Alexandre &
Pieter)
Both positions are respectable but do not have the same goal.
Then, let us keep the "OpenERP community" as it is (according to
Pieter) and let us make a new "organized OpenERP alternative task
force" (according to Alexandre).
I think that solution is respectful for everyone
Best regards
Cordialement
--------------------------------
INVITU
Computer & Network Engineering
BP 32 - 98713 Papeete - French Polynesia
Tél: +689 46 11 99
[email protected]
www.invitu.com
P Please
consider the environment before printing this e-mail!
Le 22/11/2012 06:49, Pieter J. Kersten a écrit :
Hi
Alexandre,
Of course you are free to disagree. Allow me to make a few remarks
though:
The sole reason someone *can* share code, is because it was
written, used by and payed for by someone who apparently cared and
was happy with it. Your whole idea of "unwilling" and/or
"uncaring" authors is therefore IMO unfounded. When authors loose
interest over time (and most will), you can always ask the author
to transfer it to you or else render it "abandoned" or something
like that.
The sole reason the addons community exists, is because several
authors decided long ago to change and extend the default behavior
of OpenERP's core modules and OpenERP refused to take these
changes/new modules into their core. With good reason from their
perspective. The several authors took the liberty (and obligation)
to share their code. Others used this code yet again and enhanced
and extended it. See, a thriving community.
When new authors dive up with their modules and you refuse their
contributions based on a presumed quality standard, you risk them
feeling disrespected - you are not the only proud professional out
there - which can ignite a repeat of the split process which led
to this community. That would be a loss.
Your idea of quality is your (professional) opinion. Nothing less,
nothing more. You can earn credits when others see viability in
your opinion and act accordingly. It is however always the choice
of others to do something with your opinion - or not. No single
opinion, by any individual or group, should block viable
contributions to Open Source. And by "viable" I mean as seen from
the authors perspective.
The whole concept of Open Source is find it, use it,
enhance/extend it, (re)share it. And when nothing is to be found:
build it, share it, foster it. Your use cases assume economic
viability from the perspective of the reviewers and seen as
shrink-wrap software. But viability is in the eye of the beholder.
No-one can predict other users needs searching for perhaps the
same functionality you refused. And Open Source is not equivalent
to shrink-wrap software.
In case 4, when code was shared but not up to your standards/ideas
of viability, the author doesn't respond to your summoning and
someone steps in and "takes" the module, it is effectively being
hijacked. If "Alan" receives credits for doing that, then when the
original author returns, he will find "Alan" on his path blocking
his way, backed by the group that gave him the credits. That's
plainly unethical by all standards I know of.
I concur that co-operation can achieve benefits for all. But for
that you need to be open for all. I see need for coordination and
quality assurance by original authors, and if the now chosen
reviewers are willing to assist in that - splendid. In
co-operation with the authors, you can reach an accepted flow and
set of standard for certain modules and perhaps even a base
standard for the set of modules as kept under the umbrella of
gathered modules. But that's as far as you can go. Any new module
will bring its own standard, which should open up the discussion.
And there is nothing wrong with that.
The points of view you share, breath an intent to become *the*
source of community modules and quality standards. That can be
achieved within a closed environment as can be found within a
company. But out in the open that would require world domination.
And that would be pure arrogance. No-one looses credits for
sharing code. But a community with domination intents will. It
would simply create another single point of controlled publication
of OpenERP modules, next to OpenERP's core modules, giving credits
to the reviewers, but achieving that by ignoring the base concepts
of Open Source. Yet another "partner"-model in the making. But
with that intent, not one I would be happy to be a part of. It
would harm my credits if I would.
I sincerely hope the community to be wiser than that.
"If I would dictate my worldview upon others, I would be plainly
disrespectful. But in order to do be able to keep mine, I have to
dictate others to respect others' worldviews."
Just my 2c.
--
Pieter J. Kersten
EduSense B.V.
Op 22-11-12 14:12 schreef Alexandre Fayolle:
On jeu. 22 nov. 2012 13:33:06 CET, Pieter
J. Kersten wrote:
You still miss my point. It is not in
the behavior of the reviewers I
foresee impoliteness, but in the fact that someone
contributing a new
module and making enhancements to his own module, is forced to
convince a tribune of reviewers of the quality of this new
contribution.
The flow can become: refuse it, refuse it, refuse it and then,
when
the quality is "high" enough - who says what's quality and
what's high
enough? - take it. Phew, it's in. You risk bashing people away
by
enforcing the mechanics alone.
A "politer" flow would be: take it, grant the author access to
it,
review it and then, if that "proves" to be necessary (for
you?),
enhance it in co-creation with the author. No sweat, everybody
happy.
That's the way OS has proved to work over the last few
decades.
I beg to disagree. What the politer version leads to in my
experience
is tons of non maintained modules which were checked in once in
the
past and slowly decay over time (extra-addons is full of these).
This
is *not* the way you will ever get a new piece of code in major
OS
projects such as Gnome, KDE, the Linux Kernel, or include a new
package
in the Debian distribution.
Let us take an example. John Doe wishes to add a new addon in
team
maintained someproject-addons. He pushes his branch with his new
module
on launchpad and proposes that the branch is merged. It should
not
matter if John is already a member of the team or not.
Case 1 (dysfunctional) : nobody cares, no reviews are given,
positive
or negative. John should ping people a bit. If he is already a
member
of the team, after some reasonable time and warnings he may
force the
merge. If not John will have to find another place for his
addon, and
he will earn the right to criticize the community.
Case 2: John's module is super specific, super specialized, and
people
reading the code say so in their reviews. There is discussion,
and a
consensus is reached saying that the code does not belong to the
projet
and suggesting to John that he should find another project for
his
addon, and thanking him for his contribution.
Case 3: John's code is poor (e.g. there are no comments, no the
few
help strings are written in very bad english, and some
algorithms are
not efficient). This is pointed out in the reviews, with fix
suggestions. John is unresponsive to the suggestions and does
not apply
the various suggestions. Nobody is really interested in
maintaining the
new addon, and since John is obviously not interested either,
the MP is
rejected. John's credit is harmed.
Case 4: same as Case 3, but Alan steps in and mentions his
interest in
the addon, and applies the fixes, and overall commits to
maintaining
the addon. The MP is applied. Alan earns credit.
Case 5 (hopefully nominal): The code is OK, within a few days,
the MP
gets a couple of 'approved' reviews. The merge is processed and
life
goes on. John earns credit.
Compare to Case 6: Same as case 3. The merge is performed,
hoping that
this will encourage John to fix the issues. John is never heard
of
again. No one in the team uses the code, so no one feels
committed to
apply the fixes. However, some people outside the team install
the
module in production. They submit bug reports which no one feels
inclined to process because, well the code is crappy in the
first place
and should be rewritten, and no one really has time to fix the
issues.
The team looses credit, and the members morale is harmed.
Who says what "good quality" is and what is "high enough" ? We
do. How
do we now ? Because we are programmers, and we have seen bad
code and
we have seen good code, and we know how to turn bad into good.
We can
help newcomers improve their code (and, yes, we can do this
politely).
But it is not helpful to anyone, neither to the author of low
quality
code, nor the the team in charge of maintaining the code base,
to
accept low quality code in the first place, and to leave the
team in
charge for fixing it. Known issue must be fixed as soon as
possible
(and if possible before they are merged).
--
Alexandre Fayolle
Chef de Projet
Tel : + 33 (0)4 79 26 57 94
Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac Cedex
http://www.camptocamp.com
_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
|
