forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: Things to enhance as committer
Date Sat, 03 Sep 2005 15:29:39 GMT
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. 

Great thanks. We want to encourage as much discussion
as possible to happen in the community. The pmc@ private
list is reserved for necessarily private discussions
(such as personal and security issues) and copied when
certain actions happen (such as creating a committer account).

The rest should happen on the dev list, because it gives
the whole community a chance to understand the issues,
thereby making a stronger development community.

That said, if people really do feel uncomfortable
with a certain topic in public, but think something
needs to be addressed, then please do send to pmc@forrest

Otherwise be brave, use the dev list. We are friends.

By the way, Thorsten said "PMC Head". No, that is not
right, it is "chair" i.e. the poor bastard who does
the administrative stuff and trys to keep the meeting
in order and let everyone speak. No-one is head,
we are all equals and each person's opinion has the
same importance.

Here is my reply from that list copied here ...

David Crossley wrote:
> Thorsten Scherler wrote:
> > Dear PMC,
> 
> [pmc chair hat on]
> Why is this discussion happening on the PMC mail list?
> I am obliged to ask, every time that it happens. That is
> not the way to do things at ASF. There is nothing private.
> [pmc chair hat off]
> 
> The other trouble is that you have a great list
> of recommendations for efficiency below. Unfortunately
> they are now private and the community will not
> know that that is our desire. Hence will eventually
> be repeated out there, hence more mail.
> 
> You are absolutely right. All projects need to develop
> ways to be more efficient. Less mail, more doing,
> and leading by example.
> 
> This next bit is not directed at anyone in particular.
> I have wanted to say it for a while and it fits here.
> 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.
> 
> > 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).
> > 
> > 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.
> 
> Substitute "We prefer" with "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. What happend to the
> > "Commit-then-review" method for decision-making?
> 
> That method only relates to code.
> 
> I just see discussion in response to some questions
> about which way to go. Sometimes that discussion
> goes longer than it should.
> 
> I wonder if it is best to not even ask questions
> about code. Just do it the way one thinks is best.
> Others can change it, or evolve. Of course, there
> are still other times when we do need to discuss.
> 
> But maybe you are referring to the vote about
> svn access. The issue is bigger than just giving
> Lenya svn access, so it needed some discussion.
> 
> Anyway there is no rush on that, nor reason to
> hold up any development.
> 
> > 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 don't see barriers, just constructive discussion.
> If anyone perceives a barrier, then speak up at the
> time please. Nip it in the bud.
> 
> > 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. 
> > 
> > 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).
> > 
> > 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, ...).
> 
> Yes.
> 
> If you are referring to the XHTML2 issues in Jira
> then we decided a while ago that we needed to experiment
> with Jira to assist with co-ordinating our development.
> 
> > 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).
> 
> Yes, that is a big one. We need more doing.
> 
> > 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.
> 
> For most code decisions, yes.
> 
> Thanks for taking the time to discuss this.
> Not being facetious, it really is useful.
> 
> -David

Mime
View raw message