Sam Ruby wrote:

>Ted Husted wrote:
>  
>
>>Since committing is voting...
>>    
>>
>
>+1
>  
>
You can look at it the other way round:

voting is (in a sense) committing (yourself) to the project. :-)

My itch is that I have been overwhelmed with work, to the point that I 
can barely follow the codebase or the dev list. I think that I will 
slowly find myself in a role in the project again, like:

- When the frenzy dies, I can review and debug (I'm quite good at 
debugging), and document things, and ask (and answer) nasty questions 
about product architecture or implementation.
- I can point to interesting ways to improve the project (functionality 
and/or architecture).
- I can have discussions on future changes, I keep global vision since 
I'm more detached, ...

I have been worried during this whole thread, because I feel that I'm 
losing grip of my involvements with Apache. I used to be able to track 
closely lists and codebases for cocoon, turbine, tomcat and jetspeed. 
Now I barely track Jetspeed. I felt like my involvement as committer was 
dying.

But thinking carefully after reading this thread, I think I agree with 
Andrew's comment: the system works, don't touch it.

If I am respectful and I don't touch the codebase without asking people 
(except obvious patches for typo/bug fixing or documentation), I can 
still be useful to the project. While my comments are good shaped and 
reasonable they will be taken into account and agreed. If I start doing 
unreasonable proposals or messing with code, -1s will appear, and a 
conflict will be raised.

I just wanted to point that, in addition to taking the 
developer/commiter role as something more than code shaping 
(documentation, proposals, design, etc.) tasks like teaching newbies in 
the lists or raising awareness about the projects, are valuable in 
themselves. But I would not mess with the current roles in Apache, 
except for raising awareness of the fact that there are things beyond 
code lines.

IMO, the key issues for having a working system are:

- openness
- openness
- openness

The only think that makes the system work is that all discussions (and 
the decision processes themselves) are held in the open, so that people 
can follow design intentions without needing to have explicit 
instructions, and so that proposals are kept in archives for future 
people to implement them. Also, only an open system enables us to build 
and maintain the trust and respect network for the project. Turning back 
to my itches, while I'm trusted and respected in the jetspeed team, my 
decisions will be heard and taken into account. Unless my contributions 
are really valuable, the trust will extinguish slowly as I fade. If my 
contributions are valuable, I will manage to keep a low profile and 
still be a respected developer/commiter/younameit (i.e. an active member 
of the community). I have seen this happening with other people, which 
have a varying involvement in terms of time, but always bring valuable 
material in, and they are respected even after disappearing during 
months from the list.

Pardon me for this kind of rant/public confession. ;)

Regards,
   Santiago (reading mail after weeks outside teaching java/Apache code)

>- Sam Ruby
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>  
>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to