Michael Wechner wrote:
[...]
How can we solve this problem?
by listening to each other and not just doing stuff with high potential
of breaking things without discussing it beforehand. This is what really
destroys a community.
IMO with a CTR policy every committer should decide when a change should
be discussed. Sometimes the decision can be wrong - for instance, I have
recognized that I should have discussed some of my recent changes before-
hand. But then a discussion can follow, and changes can be reverted.
I think it is important how the community handles such a situation.
"Breaking things" is not always a bad thing, sometimes a change just shows
where problems exist (e.g., a change to the repository layer might show
where the layer was bypassed). Even the perception if something is
"broken" can depend on the point of view. E.g., IMO things are really
broken if principles like SoC or IoC are violated, or antipatterns occur.
Functional bugs can be fixed, I don't consider them real problems
(at least in an unstable branch).
I share Thorsten's concerns about the community.
Some ideas how to improve it from my point of view:
- Stronger participation in discussions, reacting to proposals.
Even a "+-0" or "Interesting, but I have no idea" is great.
People should feel encouraged to express their ideas on the list.
I have to admit that I'm rather discouraged, which unfortunately
resulted in unannounced commits. Correct me if I'm wrong, but in
the case of others it might result in holding back ideas.
- Focusing on solutions (example: the guidelines thread).
IMO we should start with existing guidelines.
Just my $0.02 - I'm the type of person who is motivated by progress.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
