On Nov 19, 2007 6:29 AM, Vladimir Kosovac <vnk@xxxxxxxxx> 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 of volunteers. > > 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. > > Agreed. > > > >> ... 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) - Games - 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.. Best Regards, John Babich Volunteer, Fedora Docs Project (and proud of it!) -- fedora-docs-list mailing list fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
