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
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
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
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.
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
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 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
On Nov 19, 2007 6:29 AM, Vladimir Kosovac vnk@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 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!)
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@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
- 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!
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@mkc.co.nz 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
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
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 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!
:-)
-
John Babich -
John Poelstra -
Karsten Wade -
Marc Wiriadisastra -
Paul W. Frields -
Vladimir Kosovac