SIGs, projects, and leadership

[Karsten Wade]

Right after reminding us that steering committee (FDSCo) elections are
due right away[1], Paul asked on IRC this morning if we should consider
reverting to a SIG status:

http://fedoraproject.org/wiki/DefiningProjects#SIGs

I have concerns about that reverting concept based on the way a SIG and
a project are described there, but I think I have a grasp on what Paul
is saying.

A SIG has fewer requirements for leadership to do stuff such as:

* Hold and attend regular meetings
* Hold elections
* Report across to other projects in a predictable manner

We don't seem to be doing any of those three very well.  I'd be tempted
to follow the Fedora guideline of "when you cease being effective as a
leader, quit and get out of the way."  Another option is for more of us
(including me!) to be stronger leaders and embrace the role of making
the project details work, to support all of you in the great work you
are doing.

Regardless, these are matters that shouldn't directly affect our ability
to produce content.  But they do affect how we move into the future.  So
far, being a project seems to have helped our growth and focus.

What next?

A. Revitalize the Docs Project leadership, hold elections, and keep
things moving

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

[1] http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections
-- 
Karsten Wade, Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41

[Marc Wiriadisastra]

On Sun, 2007-11-18 at 10:28 -0800, Karsten Wade wrote:
>  Right after reminding us that steering committee (FDSCo) elections
> are
>  due right away[1], Paul asked on IRC this morning if we should consider
>  reverting to a SIG status:
>  
>  http://fedoraproject.org/wiki/DefiningProjects#SIGs
>  
>  I have concerns about that reverting concept based on the way a SIG and
>  a project are described there, but I think I have a grasp on what Paul
>  is saying.
>  
>  A SIG has fewer requirements for leadership to do stuff such as:
>  
>  * Hold and attend regular meetings
>  * Hold elections
>  * Report across to other projects in a predictable manner
>  
>  We don't seem to be doing any of those three very well.  I'd be tempted
>  to follow the Fedora guideline of "when you cease being effective as a
>  leader, quit and get out of the way."  Another option is for more of us
>  (including me!) to be stronger leaders and embrace the role of making
>  the project details work, to support all of you in the great work you
>  are doing.
>  
>  Regardless, these are matters that shouldn't directly affect our ability
>  to produce content.  But they do affect how we move into the future.  So
>  far, being a project seems to have helped our growth and focus.
>  
>  What next?
>  
>  A. Revitalize the Docs Project leadership, hold elections, and keep
>  things moving
>  
>  ... 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
>  
>  [1] http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections
>  --  
> From my point of view I'm not to sure of the history and my
> comment is 
probably invalid.  Is there a reason why meetings are attended?  Times,
days of the week?  I know I can't attend meetings because of the time.

Are there sufficient people in the docs.project to actually be a
project?  If not switch to a SIG and request that the marketing group
start marketing for more volunteers.

Can we have a calender to plan stuff similar to how packaging has a
target of what needs to be done.  The only difference for us is that we
are dependent on other people in some parts of the docs areas.  Plus a
lot of the stuff that is created is a revolving calender.

My $0.02

Marc

[Karsten Wade]

On Mon, 2007-11-19 at 09:04 +0900, Marc Wiriadisastra wrote:

>  Can we have a calender to plan stuff similar to how packaging has a
>  target of what needs to be done.  The only difference for us is that we
>  are dependent on other people in some parts of the docs areas.  Plus a
>  lot of the stuff that is created is a revolving calender. 
Yes, it's the project management where we are suffering over the years.
To be honest, I'm not as passionate about PM work, so I don't prioritize
it over other (fun!) stuff.

Let's appeal to John Poelstra to work with us.

Is there anyone here who is interested in PM work, scheduling, and the
like?  We could work with John to make up a Docs schedule that ties into
the overall schedule (like as a module).

BTW, I've seen some cool usages of TaskJuggler as part of automation and
build tools.  John has seen this, too, so I hope we'll be seeing some of
that in Fedora. :)

- Karsten
-- 
Karsten Wade, Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41

[Paul W. Frields]

On Wed, 2007-11-21 at 11:25 -0800, Karsten Wade wrote:
>  On Mon, 2007-11-19 at 09:04 +0900, Marc Wiriadisastra wrote:
>  
>  > Can we have a calender to plan stuff similar to how packaging has a
>  > target of what needs to be done.  The only difference for us is that we
>  > are dependent on other people in some parts of the docs areas.  Plus a
>  > lot of the stuff that is created is a revolving calender.
>  
>  Yes, it's the project management where we are suffering over the years.
>  To be honest, I'm not as passionate about PM work, so I don't prioritize
>  it over other (fun!) stuff.
>  
>  Let's appeal to John Poelstra to work with us.
>  
>  Is there anyone here who is interested in PM work, scheduling, and the
>  like?  We could work with John to make up a Docs schedule that ties into
>  the overall schedule (like as a module).
>  
>  BTW, I've seen some cool usages of TaskJuggler as part of automation and
>  build tools.  John has seen this, too, so I hope we'll be seeing some of
>  that in Fedora. :) 
As a GNOMEy guy, I am pretty disgusted at the lack of uptake on Planner
(nee MrProject) since it was "liberated" by Imendio.  No collaborative
features, no net-awareness, etc.  Maybe I'm just blind to whatever
they've done with it, but I haven't seen it.  I have no idea what sort
of collaborative web-based tools are out there for this stuff, but I'm
sure the TJ work John's doing will give us some sort of webby,
multiplayer interface to Do Useful Stuff.

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

[John Poelstra]

Karsten Wade said the following on 11/21/2007 11:25 AM Pacific Time:
>  On Mon, 2007-11-19 at 09:04 +0900, Marc Wiriadisastra wrote:
>  
> > Can we have a calender to plan stuff similar to how packaging has a
> > target of what needs to be done.  The only difference for us is that we
> > are dependent on other people in some parts of the docs areas.  Plus a
> > lot of the stuff that is created is a revolving calender.
>  
>  Yes, it's the project management where we are suffering over the years.
>  To be honest, I'm not as passionate about PM work, so I don't prioritize
>  it over other (fun!) stuff.
>  
>  Let's appeal to John Poelstra to work with us. 
Appeal accepted.  Glad to help however I can :)

>  Is there anyone here who is interested in PM work, scheduling, and
> the
>  like?  We could work with John to make up a Docs schedule that ties into
>  the overall schedule (like as a module). 
I just finished creating one (link posted in a separate thread) based on help from Paul F
understanding the durations and other behind the scenes stuff which I think is better
reflected in the schedule now--instead of a single milestone the incremental steps that
lead up to it are also listed. 

John

[Vladimir Kosovac]

Karsten Wade wrote:
>  
>  What next?
>  
>  A. Revitalize the Docs Project leadership, hold elections, and keep
>  things moving
>   
I'm with Karsten on this one.

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.

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.

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

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.

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.

Vladimir

>  ... 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
>  
>  [1] http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections
>

[Vladimir Kosovac]

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

>  
>  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.
>  
>  Vladimir
>  
> > ... 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
> >
> > [1] http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections
> >
>

[John Babich]

On Nov 19, 2007 6:29 AM, Vladimir Kosovac <vnk(a)mkc.co.nz&gt; 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!)

[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(a)mkc.co.nz&gt;
> 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

[Karsten Wade]

On Wed, 2007-11-21 at 13:11 -0500, Paul W. Frields wrote:

>  On Mon, 2007-11-19 at 12:02 +0300, John Babich wrote: 
>  > On Nov 19, 2007 6:29 AM, Vladimir Kosovac <vnk(a)mkc.co.nz&gt; wrote:
>  > > Vladimir Kosovac wrote: 
>  > > > 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. 
You know, having the progress bars for l10n hasn't hurt the volunteer
community:

http://translate.fedoraproject.org/releases/fedora-8

It is a very visible accountability and serves as a reminder/target to
shoot for.  People aren't afraid of being accountable or they wouldn't
have come in the first place.

Since our situation is much less complex, we could cook up some easy to
manually update graphics for our several guides.

Alternately, we could go to John Poelstra and get some help in cooking
up a proper TaskJuggler schedule. :)

- Karsten
-- 
Karsten Wade, Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41

[Karsten Wade]

On Wed, 2007-11-21 at 13:11 -0500, Paul W. Frields wrote:

>  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. 
You are right, I picked up on this as a theme and a way to get a
conversation going.

We just have overly-stretched leaders, but the project itself is
healthy.

As I'm trying to renew *all* the commitments in my life that have been
suffering over the months, I want to be sure that each one still needs
me and what I have to offer.

Also, I think it's good to have a strong leader for an important project
like this one.  I just want to make sure there is room in this garden to
grow other leaders.  When there are too few of us, we spread ourselves
thin, and it acts like a mulch that suppresses the growth of other
leaders.  It's a bizarre and ironic effect.

A solution is to rip ourselves up from doing tasks, thereby making room
for someone else to do that task, get the nourishment, and grow.

Therefore, elections *and* a review of who is doing what are both very
useful right now.  Let us proceed.

- Karsten

"Onward!" - Sacha Labourey
-- 
Karsten Wade, Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41

[Paul W. Frields]

On Wed, 2007-11-21 at 11:18 -0800, Karsten Wade wrote:
>  On Wed, 2007-11-21 at 13:11 -0500, Paul W. Frields wrote:
>  
>  > 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.
>  
>  You are right, I picked up on this as a theme and a way to get a
>  conversation going. 
Great -- I was afraid I might be misunderstood or, much worse, that I
might have given offense to you, among others.  To the rest of the folks
on the list who may be somewhat new, be assured that Karsten was one of
my original mentors in Fedora-land, and we are good buddies.  He knows
me well enough by now to know that I sometimes throw goofy ideas for the
sole purpose of having him show me why they're, well... goofy.

>  We just have overly-stretched leaders, but the project itself is
>  healthy. 
Strangely, this release I felt like, although there was quite a bit
going on, I felt pretty much on top of the things I was doing.
Nevertheless (read on)...

>  As I'm trying to renew *all* the commitments in my life that have
> been
>  suffering over the months, I want to be sure that each one still needs
>  me and what I have to offer.
>  
>  Also, I think it's good to have a strong leader for an important project
>  like this one.  I just want to make sure there is room in this garden to
>  grow other leaders.  When there are too few of us, we spread ourselves
>  thin, and it acts like a mulch that suppresses the growth of other
>  leaders.  It's a bizarre and ironic effect. 
Absolutely true, which is why I made the commitment to get out of the
way for release notes.  We have a growing number of people pitching in,
and I think showing them how to do business is our most important goal
right now.

>  A solution is to rip ourselves up from doing tasks, thereby making
> room
>  for someone else to do that task, get the nourishment, and grow.
>  
>  Therefore, elections *and* a review of who is doing what are both very
>  useful right now.  Let us proceed. 
Mush!  Mush!

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

[Vladimir Kosovac]

Paul W. Frields wrote:
>  
>  I fear my blurting out something that came to mind has made me seem a
>  little too much like an agent provocateur.   
Not at all. It is an important issue that needed addressing.

>  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.
>   
It worked out as a wake-up call to at least some of us.

> >>> 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!  :-) 
Yeah, I know - very bad choice of words on my part.


> > 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.   
I don't think it was. It was a right call (from both you and Karsten)
that could have come earlier, actually. I'm just sorry that none of us
had enough sensitivity to realise this beforehand and offer some help.

 This is a good time to be around in the Docs
>  Project and I look forward to many great achievements yet to come!
>   
:-)