When to switch over release-coordinators? :-)

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

Hey,

I thought this would be a useful question. Let's get it out on the table so 
we have an agreed mechanism for rotating folks through the 
release-coordinator job.

I don't plan to scale down my involvement, nor being active in XML/XSL/FO 
advocacy. It just occurred to me that after a few months of being release 
coordinator that one starts thinking of oneself as the "Voice of FOP". :-) 
Maybe this is a personal failing. I don't know. :-)

We've got any number of people that can, and should, get a shot at doing 
this. What do you all think?

Anyhow, I was thinking that we have identified some process areas that need 
looking at. There are associated duties that could be assigned in addition 
to each developer's individual design/coding interests. I propose:

1. Release coordinator
2. PR/evangelist/POC (point of contact)
3. Docs
4. Issues/defects tracking
5. CM/versioning
6. Architecture/high-level design
7. ...

Having these duties broken out simplifies, IMO, the stuff that people are
doing.

Arved

Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"

Re: When to switch over release-coordinators? :-)

[Fotis Jannidis <fo...@lrz.uni-muenchen.de>]

Arved, 

> I thought this would be a useful question. Let's get it out on the table so 
> we have an agreed mechanism for rotating folks through the 
> release-coordinator job.

I think, as long as the acting release-coordinator wants to go on and nobody vetoes 
this, everybody seems to be happy. 

> I don't plan to scale down my involvement, nor being active in XML/XSL/FO 
> advocacy. It just occurred to me that after a few months of being release 
> coordinator that one starts thinking of oneself as the "Voice of FOP". :-) 
> Maybe this is a personal failing. I don't know. :-)

Probably this kind of identification is one of the reasons, why open source projects work 
and as long as all are happy with the 'voice', it is good to have one. 
 
> We've got any number of people that can, and should, get a shot at doing 
> this. What do you all think?

somebody should fill in this role. If somebody else wants to step in, this would be ok too, 
but you shouldn't feel urged to move. 
 
> Anyhow, I was thinking that we have identified some process areas that need 
> looking at. There are associated duties that could be assigned in addition 
> to each developer's individual design/coding interests. I propose:
 
> 1. Release coordinator
> 2. PR/evangelist/POC (point of contact)
> 3. Docs
> 4. Issues/defects tracking
> 5. CM/versioning
> 6. Architecture/high-level design
> 7. ...

We have the specialists who wrote some part of Fop and, who are the 'natural' contact 
for any related matters. I don't know whether we need  PR/evangelist/POC (point of 
contact) beyond that what a release coord. is doing anyway. 

I have managed the docs, but - not being a native English speaker / writer - I am ready 
to step back, if somebody wants to take over. My time is so restricted that I can only do 
one of the things you mentioned (3./4./5.).  As long as nobody takes over the docs I will 
look after them, because I believe good documentation is an important factor in  pushing 
innovative software.  
 
Another important point at the moment would be some bug tracking system. I don't know 
whether and when bugzilla on xml.apache.org will be working again. Until then, we need 
someone who keeps track of the bugs and 'activates' some contributor to look into one. 
We could start with promoting the use of a note like "[bug]" in the subject of emails 
which report bugs to make management of them easier. 

Fotis

PS: I looked up "Dreirad": tricycle (for my son).