SIGs, projects, and leadership

[Paul W. Frields]

This has been on my Desktop for over two days and I finally got around
to sending it.  Sorry...

On Mon, 2007-11-19 at 12:02 +0300, John Babich wrote: 
> 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 fear my blurting out something that came to mind has made me seem a
little too much like an agent provocateur.  But in essence, this is
indeed what I meant: that with the few hands we have, perhaps we're best
served by eliminating as much administration as possible, to the extent
it frees up resources/time.

> > > 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.

Give up?!?  Never!  :-)  My only concern was in trying to remove any
over-commitment barriers.  In all honesty, it was all about trying to
make Karsten's life as FDSCo chair easier.  I hadn't run this idea past
him at all, and simply put it out in IRC.  I was worried that we had
created such a stir of administrative duties and responsibilities that
it put important work like editing and direction in a second-chair
position.  But the work of project management can't be seen as a
distraction, it's necessary for success.  With so few people available,
it's difficult to do project management when the few are saddled with
lots of the work.  The more we can encourage other people to get
involved and learning how to do good technical documentation, the better
off we'll be in the long run. 

> 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.

I know Karsten agrees that having more hands on deck recently has been a
real boon to the Docs Project lately.  That is the best sign yet that
we're producing valuable work.  People don't often line up to work on
something that they think is worthless, right?  

> > > 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.

/me raises two hands.

> > > 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 a very touchy thing, dealing with responsibility in a volunteer
project.  The notion of whip-cracking is a little daunting, but people
who are committed generally are also self-directing.  I would say that
if we ever got into the bind that we needed to remind someone about
accountability, we as a project are doing something wrong.  The folks
contributing time and effort should be appreciated fairly and
proportionally for what they do.

> > > 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.

Yes -- this is exactly why I have been trying to give as much help as is
wanted or needed to folks trying to figure out the less obvious parts of
our toolchain.  With more people able to do things like release notes
upkeep, XML conversion, publishing, etc., I know I'll have more time for
editing and possibly even toolchain development.

> > >
> > >> ... 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

I'm not sure I see how these couldn't be done in XML and CVS, but that's
entirely dependent on how much our contributors want to develop
additional skills.  If the people doing the work prefer to do this on
the wiki, then they should work there.  That never keeps us from
changing our minds later, and if it keeps momentum high, so much the
better.

> In conclusion, I vote for remaining a project and applying
> project management procedures similar to that applied to
> package committers and maintainers..

I'm glad this issue has spurred some discussion, but hope it wasn't
aggravating to anyone.  This is a good time to be around in the Docs
Project and I look forward to many great achievements yet to come!

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
           Fedora Project: http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20071121/f61187a2/attachment.sig>