Andreas Hartmann wrote:
> Michael Wechner wrote:
>> Andreas Hartmann wrote:
>>> 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
>>
>> what exactly do you mean by CTR
>
> commit then review
I think that's perfect for changes which won't break
things, but for
changes with the potential
of breaking things I would suggest RTC (review then commit)
>
>> (there are many acronyms out there and maybe we
want to clarify this
>> first)
>>> 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.
>>
>> some changes cannot be reverted that easily. For
instance if someone
>> is changing the content model
>> and some people upgrade and spend a lot of time on
this, and then it
>> will be reverted, what do you think
>> how many poeple will be frustrated in the end. And
then it might
>> change again ...
>
> I understand your concern. I see no way to solve it
with the current
> situation (trunk in production use), therefore I agree
that we have to
> be careful until there is a release. In the future, I
hope we won't have
> this situation anymore.
>
>
>>> 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).
>>
>> one can break things locally and then discuss it
with others.
>> This is one of the reasons why local workspaces are
a great thing.
>> I agree that one cannot share the local findings so
easily, but this
>> one of the reasons why we have
>> the sandbox
>>
>>> 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.
>>
>> I wouldn't call this broken
>
> OK
>
>> and I think it's important that we agree what a
term means.
>
> +1
>
> Maybe the term "broken" should be entirely
avoided. We should use the
> terms which apply to the actual problem:
>
> - functional problem
> - quality problem
> - usability problem
> - ...
>
it certainly makes sense to finegrain, but for instance
build broken
means to me build failure
(e.g. doesn't compile anymore)
or publication broken means to me Lenya/Cocoon is throwing
an
error/exception.
What terms would use for these two situations?
It seems to me that these are the most urgent problems which
can be
avoided through review and testing.
>>> Functional bugs can be fixed, I don't consider
them real problems
>>> (at least in an unstable branch).
>>
>> it depends on the siutation.
>>>
>>> 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.
>>
>> yes, this would be nice, but I am afraid these
things will always
>> slip through sometimes
>> (for instance some people might be on vacation or
it is weekend or
>> they have too much else to do and don't find
>> the time to work through the backlog)
>
> Sure, not everyone will always comment a proposal. But,
in general,
> I think there could be more participation in
discussions.
>
>
>>> 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.
>>
>> why are you discouraged?
>
> Sometimes I have the feeling that discussions either
tend to become
> endless and lose focus, become to emotional and
personal,
agreed
> or that
> there is a lack of interest.
> Yes, that shouldn't lead to the situation that
discussions are
> avoided. I sometimes dealt with this by lowering my
"discuss before
> commit" threshold, but I agree that the better
way would be trying
> to improve the quality and effectiveness of
discussions. Any ideas
> how to achieve this are appreciated ...
It seems to me that shorter messages are better than longer
messages.
Also mixing concerns within emails is a problem.
Restarting a thread with a summary also should help.
Using good subjects.
HTH
Michi
>
> -- Andreas
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache
Lenya
http://www.wyona.com
http://lenya.apache.org
michael.wechner wyona.com michiapache.org
+41 44 272 91 61
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org
|