Sander Striker wrote:
for many people, yes!! It is very hard to even find people willing to work onHang on a minute. Why does everyone need commit access to this one? All ASF members have commit access to it. And more than a few others. I'm sure it isn't that hard to find someone to commit sent in patches. Is generating and sending in a patch considered too high a barrier?
documentation, and when you do find them if you make it even slightly
nontrivial to do their thing, they will often JustDoIt elsewhere or not at all.
that's why wikis are so successful: their barrier to entry is extremely low. Between
finding an error or area that deserves improvement and actually seeing the change you
made live on the website are 30 seconds with a wiki instead of two days or more for
a patch.
for example, there is a useful bit of info about cvs @
http://wiki.cocoondev.org/Wiki.jsp?page=CvsAndFirewalls
that would be nice to have on www.apache.org/dev/.
Consider the amount of overhead for the average casual apache contributor in getting it up on that page. It involves something like:
- navigate the wiki for place to add the page - click "edit this page" - add a new link - click "save" - click the new link - enter content - click preview - verify correctness, edit again - click save
time taken? maybe a minute or so if you're familiar with wikis, maybe 15 minutes if you're not.
now consider how one gets this information up on www.apache.org/dev/:
- navigate the site for place to add the page - figure out where/how the site is maintained - read the documentation on how to help maintain it - check out relevant cvs modules - learn anakia xml format - find the xml file to edit - transform content to xml, add page - add link to this new page from the faq - run anakia - view results - verify correctness, edit again, run anakia again - learn how to generate patch - figure out where to send the patch - generate patch - type e-mail - send patch with e-mail to infrastructure list - followup on the responses - make a change to your patch as requested by infrastructure team - send another e-mail - check whether the patch was properly applied and the website was properly generated
time taken? maybe 10 minutes if you've got experience with submitting patches,
using ant and anakia, etc. Maybe an hour or two if you're not. Not counting the
time taken by the person applying the patch.
The latter process is acceptable for software, but for documentation it means
that oh, lets say, 95% of your potential documentation contributors do not
even bother to contribute.
Now, giving lots of people cvs commit access does not make all that easier, but it replaces all of
- learn how to generate patch - figure out where to send the patch - generate patch - type e-mail - send patch with e-mail to infrastructure list - followup on the responses - make a change to your patch as requested by infrastructure team - send another e-mail
with
- commit the change
which might cut time taken in half for your average jakarta committer who has
experience with using ant, anakia and cvs.
no, the barrier is not high. Yes, it is too high for many, many potential contributors.
I can hear you think, "yeah, but a wiki doesn't have enough security". Well, applying standard risk assessment practices, I would think that HTTP basic authentication with passwords available to anyone with an @apache.org e-mail account is enough protection for the content on www.apache.org/dev/. We really don't need public key SSH encryption and CVS commit right partitioning here.
back into my corner! cheers,
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
