SIGs, projects, and leadership
jmbabich at gmail.com
Mon Nov 19 09:02:35 UTC 2007
On Nov 19, 2007 6:29 AM, Vladimir Kosovac <vnk at mkc.co.nz> wrote:
> Vladimir Kosovac wrote:
> > Karsten Wade wrote:
> >> What next?
> >> A. Revitalize the Docs Project leadership, hold elections, and keep
> >> things moving
> > I'm with Karsten on this one.
I vote for continuing as a project, building on the hard work already done by
people like Paul and Karsten.
> > Documentation Project grew over time to a pretty complex entity with a
> > lot of moving parts. It's not getting simpler, either. To have any
> > chance of being successful, it needs to be managed like a project.
Let's apply sound project management principles, then. I know it's difficult to
persuade a volunteer group to agree to a certain set of processes and
procedures. However, this is already what it takes to be a Fedora committer
or maintainer. Creating and maintaining documents should be no different.
> > I think I also understand where is Paul Frields coming from but I don't
> > agree that it's time to give up. Instead, let's do what procedurally
> > needs to be done - announce and hold elections and see how can we move on.
I appreciate that Paul and Karsten, to name but two, are extremely busy and
perhaps over-committed. We may just have to "limp along" until the future
leadership naturally emerges. I, too, get discouraged At the same time, I see
some encouraging signs, both in the popularity of Fedora 8 and the new wave
> > Few ideas that come to mind, in a not so coherent shape:
> > Before the results are in (very important!) get together all
> > contributors who are, depending on the state of the individual activity
> > over the past year, happy to extend/renew their commitment to writing
> > content. I shall be the first one to pledge this commitment (renew option).
Despite some recent business and personal commitments forcing me to
cut back somewhat, count me in.
> > The other important thing that we seem lacking is a way of measuring
> > accountability. I realise we are all volunteers with a variety of other,
> > more pressing commitments in our lives and that it is extremely
> > difficult to enforce this. But I am also pretty sure that every single
> > one of us had at least a vague idea of what are we getting ourselves into,
> when signing-up with the docs project.
> **Thats how it was supposed to read **
Thanks for the clarification, Vladimir.
Signing up for the Fedora Docs Project is not a straight-forward process.
Surely, someone signs up with his or her "eyes wide open".
Once a person volunteers, I think it is reasonable to ask them for a specific
commitment of time or talent. If someone fails to deliver, it should be noted
and that person should be asked respectfully if there is a blocking issue or
another priority preventing the completion of the task. I include myself in this
process of accountability.
> > It's only fair to establish this in some way. Project leaders cannot be
> > the only individuals with accountability attached to their roles.
> > Then, to make project leader's life bearable, do what FDSCo page says:
> > "As roles are defined in the process documentation, the chair will
> > delegate various roles to the members of the FDSCo to manage."
> > Share the burden, guys, then do the similar down the hierarchy ladder in
> > your assigned areas.
> > Try to set the milestones for every written bit, not only stuff that's
> > closely tied to $release. Do this with DUG, SAG, everything.
> > It shouldn't be too hard to get some momentum going, though - stuff is
> > in a good shape, just needs a little bit more effort from all of us.
> >> ... or ...
> >> B. Reduce complexity and scope of leadership to focus on a SIG and just
> >> getting stuff done
> >> I've been trying to find my way back to A, and if that is our consensus,
> >> I'll work harder at making it happen.
> >> thx - Karsten
The amount of work related to $release is pretty clear. In order of
priority, it is
1. Release Notes
2a. Installation Guide
2b. Administration Guide
2c. Desktop User Guide
These are edited on the wiki and eventually converted to DocBook XML
and published as immutable web pages.
There is also plenty of wiki docs that may not be suitable for DocBook
conversion, due to their fast-changing content:
These may include such special topics as:
- Live CDs & Spins (fast-evolving)
- Virtualization (likewise)
- Upgrading in place (getting more standardized)
- RPM guide (overlapping with rpm.org)
- Yum (being incorporated into AG, IG & DUG)
- Translation, I18n and L10n pages
In conclusion, I vote for remaining a project and applying
project management procedures similar to that applied to
package committers and maintainers..
Volunteer, Fedora Docs Project (and proud of it!)
More information about the docs