Getting Involved Guide

[Marc Wiriadisastra]

<snip>
> I don't think Paul is proposing that we *drop* end-user content, but
> that we add writing and maintaining contributor content, put up as at
> least the same level of priority.
> 
> We already have more end-user content to maintain than active Docs
> contributors can handle.  Unless we find a way to grow this project,
> we'll end up dropping some of that content (again.)
> 

I personally think that is getting better since the new people involved
in the project are helping out.

> It is satisfying to help one or a handful of users to accomplish
> something important.  It is equally satisfying, and arguably more
> important, to teach one or more people how to get involved and become
> part of the solution.
> 

I agree

> It's the old, "Give them fish and you feed them for a day, teach them
> how to fish for themselves and you feed them for a lifetime."
> 
> > The next step is the contributor documentation which is mainly
> > consolidating the information that's already around.  
> 
> My recommendation here is guide rather than consolidate -- point to
> where the content exists, which is often maintained by the sub-project
> itself.
> 
> - Karsten

My definition of consolidate does not mean take control rather make it
accessible to people who don't know where to look not the docs project
write it and control it.

By way of example: I had a question on #fedora-devel today about where
to find python packaging examples now I knew where to look because I had
spent time searching the web previously.  If we had a 'consolidated'
guide on where to find things such as packaging docs -> python then even
if it is owned by the packaging people it would be easy to find.

In the two diagrams what do you mean by formal and informal?  I agree
with the overall concept but I don't see how we can achieve this.  I had
a concern that we were moving away from end user docs rather we are
broadening our horizons.

Cheers,

Marc