forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <>
Subject Re: Things to enhance as committer
Date Mon, 05 Sep 2005 01:51:47 GMT
On 9/3/05, Thorsten Scherler <> wrote:
> Dear committers,
> Disclaimer:
> I wrote this mail original to the PMC list, because it is directed to
> committers only, and David, as PMC Head, asked me to post it to the dev
> list. It is *not* addresses to devs nor user, it it addressed *only* to
> *committers*. If you are not a committer I am *not* talking about you.
> On Fri, 2005-09-02 at 10:06 +0200, Thorsten Scherler wrote:
> > BTW I want to announce that I will lay lower with forrest for a while.
> > There are too many things in my real life happening right now that I
> > need to leverage my time better. I will still be subscribed but only
> > doing work when I can (mostly that will be view related).
> On Fri, 2005-09-02 at 18:42 +1000, David Crossley wrote:
> > Okay, we can only do what we can. I do hope that
> > i did not put you off. That was not my intention.
> Actually it is not David, nor any other committer or dev in special. I
> will just not have too much spare time in the following months. The time
> I have I want to use efficient.
> The way we started to handle things in forrest are IMO ATM the opposite
> of time efficient.

I think there may be some very valid and valuable reasons for some of
what you perceive to be inefficiencies.  I am neither discounting your
points nor saying there's not room for improvement -- my comments that
follow are simply to provide another point of view.
> It seems we prefer to kill a momentum that arises (and that somebody had
> a hard time to start) by starting a debate on principles. Latest example
> is the lenya forrest integration momentum (which should be the base for
> DOCO). What happend to the "Commit-then-review" method for
> decision-making?

When that momentum brings our principles into question, it's not so
bad to debate them.  I think there are a couple reasons for this.  1)
to discuss the direction of the momentum itself and 2) to teach new
devs/pmc/committers by openly discussing things (e.g. YOU've taught me
a lot via the latest example you mention and that might not have come
any other way).

It seems to me that our role as PMC members is to look out for the
strategic direction of the project.  How can we do that as a whole
without looking at individual actions through the lenses of a
strategic scope and discuss it?  Some of us aren't long time members
and just may take a little extra discussion to "know where you're
heading with something" -- a part of the learning process.  I
generally don't acquiesce for not knowing -- I prefer to learn and
weigh in based on what's learned.
> We say one step at a time, which is perfectly alright, but still we need
> to do the first step. If somebody offers to do the first step then try
> to lead his way and not building barriers.

i agree -- but more importantly, if you see barriers then highlight it
because I doubt that *anyone* on this project desires barriers, which
leads me to believe that someone is being misunderstood.
> It seems we prefer to have endless discussion and well meant
> recommendation that do not contain any specific examples (e.g. code
> discussion). If you want to change something give an example that is
> working and we can discuss this.

I assume you're talking about view resolver/fallback/lm stuff here.  I
think this was covered properly in the other thread.  If another dev
has a thought on a way to do something better but doesn't have time to
implement it, would you rather not even hear the idea?  As always, you
can simply say "ok, in your spare time, you refactor it that way, but
for now it's working."  That, for example, is essentially what Ross
told me when I disagreed with the xslt-based locationmap mounting
stuff IIRC.
> If somebody took the time to come up with a solution/recommendation you
> should better spend your time to enhance that instead of recommend
> something different (e.g. with another focus).

Even if the something different is a better long-term approach?

> It seems we (committers) open issues that could have been fixed at the
> same time as we opening them. Just go ahead and fix it and save the
> resources of the ASF and the project (every issue produces overhead:
> mail, time, ...).

This would be nice right? I mean, who has the time for a *potential*
several hour detour when they're trying to get something done?  Some
may seem trivial but often aren't.  I long ago learned better than to
say "I'll just fix this bug real quick then I'll get to XYZ.."  I
think casting a negative connotation on JIRA Issues is not a good
idea.  IMHO experience teaches us to log it -- an additional JIRA
issue doesn't cost that much I think.
> It seems we (committers) ask whether some components work or not. Just
> go ahead and try it (that is what the rest has to do as well).

Call us out.  It might be me you're referring to, if I ask something
obvious, please don't hesistate to call me out on it.  I try to read,
code, then ask as best I can but I'm thick skinned enough to be called
out on it when I fail to do so.

> I would love to keep on helping lenya *and* forrest in the future. I
> hope that we can keep the time ratio between discussion and decision as
> low as possible. Otherwise it will cost to much time to keep up this
> support. Lets please live again our commit-then-review method for
> decision-making.

I think CTR lives on with respect to code.  

As PMC members, our responsibilities to the project and community go
beyond code though.  I'd also say that we've taken on quite a few new
folks lately and in doing so, hopefully you all understood that a
along with that would come an increased amount of
questioning/discussion/debate (e.g. email) -- you did think about
that, right?  I didn't accept the PMC offer lightly -- I took it
seriously and want to trully understand this stuff so that I can be an
effective PMC member.  That, unfortunately, may require some extra
discussion for a while.  You guys have had the luxury of working
together for a long time so that you may be able to communicate
meaning in a few words and completely understand each other. 
Hopefully I'll get there with everyone too, but for now I prefer a few
extra words/emails to ensure that the complete meaning is being
transmitted.  Remember too, that mentoring doesn't end with someone
accepting a PMC offer.

Rather than respond to a whole new email, I'll paste in what David
also said and respond to that too:
> I am concerned that some people might not see the value
> in the non-code discussions. I hope that i am mistaken
> because getting the community practise and composition
> on a correct footing is more important than the code.
> It will lead to efficiency in the long run.

+1, as I look back through the archives, I find some incredibly rich
concept, architecture, design, and implementation discussion happened
that now gives me good insight.  I think we owe it to those that end
up picking up our slack to provide the same.  Many of the people
active now contributed on those threads that I now lean on.  Don't
forget where <generally>you<generally> started -- lot's of googling
with "" as the parameter, right?

On a side note, your email contains a lot of apparent references to
real things.  I personally would prefer that you just correct me
straight out when I do something dumb (e.g. ask an obvious question)
instead of letting it build up.  I've got very thick skin and won't be
offended with a "RTFM"-type response when it's appropriate.


View raw message