1 p.m.
Hi
I see a large number of mails here about meetings, processes and tools
but the primary output of the documentation team that is useful for end
users is good quality content that they can refer to but there doesn't
seem to enough interest or progress being made. If the number of
meetings and steering committee members are more than the number of
active documentation we maintain, I would say the priorities are wrong.
Did folks notice that or agree with me?
Rahul
7:15 p.m.
On Wed, 2007-08-01 at 23:30 +0530, Rahul Sundaram wrote:
Hi
I see a large number of mails here about meetings, processes and tools
but the primary output of the documentation team that is useful for end
users is good quality content that they can refer to but there doesn't
seem to enough interest or progress being made. If the number of
meetings and steering committee members are more than the number of
active documentation we maintain, I would say the priorities are wrong.
Did folks notice that or agree with me?
I notice it and don't agree with you.
Rahul, don't make me waste time explaining why making an open source
project have a good infrastructure is necessary. One word explains it
-- leverage. When people are enabled to contribute with enough tools
and processes, the toolers and process writers and leaders have
multiplied their own efforts exponentially. The other alternative is to
give up all that good work and just spend our time writing something,
where we are multiplying our efforts by a whopping "one."
Also, do you think you should dictate what people spend their time on?
If someone wants to work on tools instead of content, who cares? Who
are you to try to make people feel bad for working on what they are
interested in?
I agree we have a huge lack of active writing contributors.
I don't know why, but I presume thinks like requiring the GPG-signed CLA
for the Wiki are a part of it -- since that is the only difference
between this open documentation community and most others.
So, I've done all the work to fix that, we're just waiting for Moin 1.6
to drop.
Another is a very noticeable lack of content from Red Hat when we got
started; quite different from the rest of Fedora, who had an entire
distro to start with. Heck, even Infrastructure had more hardware to
start than Docs had content. Every other team, from Art to Engineering,
has had a paid person supporting the project, and therefore some kind of
budget. Everything we have done in Docs has been boot-strapped.
But ultimately, in the last three years, we have:
* Opened the CVS wide open
* Taught Wiki and XML fundamentals
* Taught writing and editing fundamentals
* Produced the best release notes
* Written and maintain solid installation content
* Responded to all content ideas and edit requests to the best of our
collective ability
* Done all we can to lower the barriers to entry so we are almost the
easiest project to get involved in
* All with a team of writers, editors, and techies that (at most time)
could be counted on two hands
- And often those were the same people you are berating for spending
too much time dealing with "meetings, processes and tools".
So, if all of that and opening the Wiki (so it is a larger body doing
community documentation) and adding Plone (so more than three people can
actual publish content on docs.fedoraproject.org) aren't enough, then I
guess I've failed. Good thing I've already said I won't stand for
leader re-election, since I guess by your account I don't deserve it.
- Karsten
--
Karsten Wade ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
7:37 p.m.
Karsten Wade wrote:
I notice it and don't agree with you.
Rahul, don't make me waste time explaining why making an open source
project have a good infrastructure is necessary. One word explains it
-- leverage.
Steering committee or elections for who would be in the steering
committee is overhead. In a large team it might yield some visible
benefits but it seems that kind of overhead is unnecessary for a small
team. I mean, if everybody who is really part of the documentation team
is part of the steering committee who are you steering?
Infrastructure improvements is all well and good and I have suggested
several myself including atleast one of what is part of the current
Google SoC work now so I do understand the value of that.
Also, do you think you should dictate what people spend their time on?
If someone wants to work on tools instead of content, who cares? Who
are you to try to make people feel bad for working on what they are
interested in?
I am not dictating anything to anyone and I of course have zero control
on what people do so that's not the point but it is important to take a
step back and look at what we have accomplished that matters directly
for end users. I will say the only things that has mattered is
1) Installation guide
2) Release notes
Another is a very noticeable lack of content from Red Hat when we
got
started; quite different from the rest of Fedora, who had an entire
distro to start with. Heck, even Infrastructure had more hardware to
start than Docs had content. Every other team, from Art to Engineering,
has had a paid person supporting the project, and therefore some kind of
budget. Everything we have done in Docs has been boot-strapped.
I have been through that flamewars and got that point through to
everyone I could possible but you know what? It's high time we moved on.
- And often those were the same people you are berating for
spending
too much time dealing with "meetings, processes and tools".
That is indeed my point. If we focus more on end user documentation
could the same people have accomplished more instead of say dealing with
the election? Could the irc meetings be say monthly and more discussions
happen on list. Just maybe something to think about.
Everyone who is active is doing a good job. No doubt about that. The
question is only on whether we are having the right priorities here. My
suggestions are going to be simple
1) Dissolve the steering committee and associated elections etc
2) Try and reduce the barriers to the team itself so that we can spend
more time producing solid documentation for end users instead of dealing
with overhead.
Rahul
9:13 p.m.
On Thu, 2007-08-02 at 06:07 +0530, Rahul Sundaram wrote:
Karsten Wade wrote:
>
> I notice it and don't agree with you.
>
> Rahul, don't make me waste time explaining why making an open source
> project have a good infrastructure is necessary. One word explains it
> -- leverage.
Steering committee or elections for who would be in the steering
committee is overhead. In a large team it might yield some visible
benefits but it seems that kind of overhead is unnecessary for a small
team. I mean, if everybody who is really part of the documentation team
is part of the steering committee who are you steering?
You are implying that we give out FDSCo membership as a prize for people
who do something, which could not be further from the truth. All the
folks who stood up for elections did so because they wanted to help
encourage contributions and to build ways for people to do it more
easily. If contributors want to form teams around specific work -- as a
few have done in the past, and which strategy works very well as a rule
-- having sufficient FDSCo resources to track those teams is important.
Karsten wisely decided to err on the side of having too many chiefs in
case some of our recruitment efforts paid off. It's unfortunate that
didn't happen, but seeing as how no one here is getting extra pay,
there's nothing gained or lost by keeping that particular wheel turning.
Infrastructure improvements is all well and good and I have suggested
several myself including atleast one of what is part of the current
Google SoC work now so I do understand the value of that.
The value of infrastructure is not just "well and good" -- if anything,
it's greater than simply writing user docs. I work on the user docs
because I want to make sure people get at least some minimal assistance
when they start a task. I work on the tools to make sure that when
someone follows one of the innumerable links to join Fedora, there are
actually ways for them to do that easily.
> Also, do you think you should dictate what people spend their
time on?
> If someone wants to work on tools instead of content, who cares? Who
> are you to try to make people feel bad for working on what they are
> interested in?
I am not dictating anything to anyone and I of course have zero control
on what people do so that's not the point but it is important to take a
step back and look at what we have accomplished that matters directly
for end users. I will say the only things that has mattered is
1) Installation guide
2) Release notes
I disagree that these are all that has mattered, since we have (or have
had) a few contributors working on a number of other documents such as
the Users Guide, a Kernel Building Guide, and others.[1] With the
progress toward a portable live distro (i.e. boot device + user
storage), the Installation Guide may actually end up being LESS useful
over time rather than more so. Nevertheless, I would welcome
contributors helping to improve and maintain it. I've offered countless
times to tutor people (as necessary) in doing so.
> Another is a very noticeable lack of content from Red Hat when
we got
> started; quite different from the rest of Fedora, who had an entire
> distro to start with. Heck, even Infrastructure had more hardware to
> start than Docs had content. Every other team, from Art to Engineering,
> has had a paid person supporting the project, and therefore some kind of
> budget. Everything we have done in Docs has been boot-strapped.
I have been through that flamewars and got that point through to
everyone I could possible but you know what? It's high time we moved on.
Karsten's not making excuses, he's pointing out, as a direct
counterargument to you saying we're not getting enough done, that
everything we've done, we've built from scratch. One more time, since
it was snipped out, let me refer back to your words:
"...[T]here doesn't seem to enough interest or progress being made."
I'll be happy to put our work here up next to any other subproject as
being at least as productive per capita. Karsten laid out a very brief
list of the progress we've made.
> - And often those were the same people you are berating for
spending
> too much time dealing with "meetings, processes and tools".
That is indeed my point. If we focus more on end user documentation
could the same people have accomplished more instead of say dealing with
the election? Could the irc meetings be say monthly and more discussions
happen on list. Just maybe something to think about.
If your problem is merely that we're having elections, let me assure you
that we spent very little time on that particular issue. If you measure
the coverage based on FDSCo minutes, list traffic, and IRC logs, you'll
find that to be the case. I'm sure we took a few minutes of Toshio's
time to enter some data for the elections -- not to minimize at all his
assistance, for which we are, of course, grateful -- but it wasn't much
in the grand (or even daily) scheme, frankly, since the app was already
built.
I would refer you to http://fedoraproject.org/wiki/DefiningProjects
which requires that projects have a governance model. Although the
specification does not require {s,}elections, the idea of elections was
discussed many times over the last few years and the FDP community (not
just two or three of us) agreed it was the way to go. Number of members
in FDSCo are not a reflection on, nor a result of, how much work is or
isn't getting done. I think our committee situation can easily be
compared to FESCo + Packaging, for instance, where there is a very large
total committee membership, and all of the people involved there are up
to their elbows in the real work too. The fact that the most active
FDP'ers are also interested in running for FDSCo should come as no
surprise, although threads like this make it somewhat more difficult to
remember why.
The one point of agreement I have with you here is to do more on-list.
That's why I've made that point (and not by myself) repeatedly in
meetings and on IRC, and asked people to move discussions here. I'll
say it again: USE THE LIST! (Er, on-topic, please.)
Everyone who is active is doing a good job. No doubt about that.
Golly, thanks, but then why the "there doesn't seem to enough interest
or progress being made" comment? You can't drop bombs like that, Rahul,
and not expect to ruffle feathers among those who are shouldering a lot
of work. And since I split my time fairly evenly between tools work and
end-user docs work -- including both the docs you mentioned, the IG and
the RelNotes -- I feel perfectly justified raising my hackles a bit.
The question is only on whether we are having the right priorities
here. My
suggestions are going to be simple
1) Dissolve the steering committee and associated elections etc
2) Try and reduce the barriers to the team itself so that we can spend
more time producing solid documentation for end users instead of dealing
with overhead.
With this sort of thinking on the development side, we wouldn't have a
Fedora platform that anyone could custom-build to their liking.
Furthermore, it seems like you have a very skewed idea of what our
"overhead" is. I haven't heard anyone complain about lost time in a
FDSCo meeting yet, but we have the ability to self-modulate if that
occurs, just as we have in the past.
There is no barrier to team membership beyond what is required for
overall Fedora Project membership -- you introduce yourself, roll up
your sleeves, and get to work. That's all we ask. You only have to be
able to write passably in a chosen language to work here. If that
language isn't English, you may need to scare up a translator so the
monoglots among us can be of more assistance. We offer to help with
everything else, and can teach many skills, including better writing, if
and as the contributor desires.
Our priorities are to create not just documentation but also a toolchain
that allows any free community using Fedora (or other platforms with
some common tools, for that matter) to build documentation, in the same
way that the developers are providing a platform for people to build
functional code. Our mission statement says exactly as much.[2]
You are simply beating the wrong bushes here. We have dedicated time in
the past to making one-on-one contact with big rosters of community
members who had introduced themselves and then immediately gone quiet,
in the hopes that they would be convinced to help out with small tasks.
The returns from even this personal outreach initiative were quite
meager -- although a few of those who responded have stuck with us, for
which we are grateful and continue to work with them and be responsive
to their contributions.
Instead of trying to reset our priorities, why not spend that energy
finding volunteers? Technical skill is not as important as writing
skill; we can teach the former much easier than the latter, and in so
doing, find additional ways to improve our Documentation Guide[3] -- oh
wait, did I mention I've been doing quite a bit of work on that too? --
so that other contributors can learn how to participate more easily.
* * *
[1] http://fedoraproject.org/wiki/Docs/Drafts
[2] http://fedoraproject.org/wiki/DocsProject
[3] http://docs.fedoraproject.org/documentation-guide/
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project: http://fedoraproject.org/wiki/PaulWFrields
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
9:27 p.m.
Paul W. Frields wrote:
You are implying that we give out FDSCo membership as a prize for
people
who do something, which could not be further from the truth.
What I am saying is that a steering committee only makes sense to me
when there is a large team of members participating which is not the
case here similar to art team and not like packaging. When you are small
team, being loosely organized is a plus.
> Everyone who is active is doing a good job. No doubt about that.
Golly, thanks, but then why the "there doesn't seem to enough interest
or progress being made" comment? You can't drop bombs like that, Rahul,
and not expect to ruffle feathers among those who are shouldering a lot
of work.
It is the same people doing the work all the time and enough interest
should be from *other people*. That is progress to me. Anyway if people
are happy with they have and think it isn't a problem of additional
overhead, then continue right ahead and I will drop this off.
Rahul
12:34 a.m.
On Thu, 2007-08-02 at 07:57 +0530, Rahul Sundaram wrote:
Paul W. Frields wrote:
> You are implying that we give out FDSCo membership as a prize for people
> who do something, which could not be further from the truth.
What I am saying is that a steering committee only makes sense to me
when there is a large team of members participating which is not the
case here similar to art team and not like packaging. When you are small
team, being loosely organized is a plus.
We aren't a small team, really. F7 probably saw participation from 45
people in producing content included in the distro. I include l10n for
more reasons than just because you dismiss tools as not being of value
to Fedora end-users. I notice that the number of translations has
*increased* release after release, and this is a direct result of tools
and processes and leadership. How can you dismiss that so casually?
As we now know, content creation and translation are intimately
connected projects. We need strong leadership in both areas to ensure
success. Loosely organized quickly becomes, "I don't know who to talk
to about X."
Art Team is a difficult analogy to the Docs Project. For a while, we
had someone who was paid by Red Hat to lead that effort. This is part
of why Mike can run a different organization, he's the guy who is in
charge because Red Hat pays him to be in charge. No one has ever been
paid to work on Fedora content, beyond the stuff Tammy did at the
beginning, and the early FC release notes Ed worked on. Mainly, no one
has been paid to lead.
Seeing the writing on the wall (so to speak), I decided for the
betterment of the project *and* myself to set the goal to grow enough
leaders in this project so that I could be replaced.
So, just when I have things in place where I can transition that
leadership off my shoulders and onto someone else from the community,
your big idea again is ... what?
Anyway, that's why this is a bit of a silly distraction. Save it for
when the proof is there one way or the other.
- Karsten
--
Karsten Wade ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
12:31 a.m.
On Thu, 2007-08-02 at 06:07 +0530, Rahul Sundaram wrote:
Karsten Wade wrote:
>
> I notice it and don't agree with you.
>
> Rahul, don't make me waste time explaining why making an open source
> project have a good infrastructure is necessary. One word explains it
> -- leverage.
Steering committee or elections for who would be in the steering
committee is overhead. In a large team it might yield some visible
benefits but it seems that kind of overhead is unnecessary for a small
team. I mean, if everybody who is really part of the documentation team
is part of the steering committee who are you steering?
I think Paul responded to this bit just fine, so I'll leave it at that.
Infrastructure improvements is all well and good and I have suggested
several myself including atleast one of what is part of the current
Google SoC work now so I do understand the value of that.
>
> Also, do you think you should dictate what people spend their time on?
> If someone wants to work on tools instead of content, who cares? Who
> are you to try to make people feel bad for working on what they are
> interested in?
I am not dictating anything to anyone and I of course have zero control
on what people do so that's not the point but it is important to take a
step back and look at what we have accomplished that matters directly
for end users. I will say the only things that has mattered is
1) Installation guide
2) Release notes
First, where is it written that value in Fedora is only measured in
benefit to end-users?
Second, what do you define as end-users?
How about those hobbyists? I'm 100% certain there are people using our
toolchain as *downstream* consumers of the benefit of a solid,
easy-to-use DocBook XML chain. We care enough about them to identify
them as end-users in the Docs Project:
http://fedoraproject.org/wiki/DocsProject/
"The Fedora Documentation Project ("Docs Project") provides 100%
free/libre open content, services, and tools for documentation."
If you remind me in a few weeks, I'll be glad to write up a, "What Docs
has done for Fedora" page. We give benefit to end-users of all sorts,
in all sorts of ways, and have since FC1.
/me wonders why the SELinux FAQ didn't make it into Rahul's list of
useful stuff. ;-P
> Another is a very noticeable lack of content from Red Hat when
we got
> started; quite different from the rest of Fedora, who had an entire
> distro to start with. Heck, even Infrastructure had more hardware to
> start than Docs had content. Every other team, from Art to Engineering,
> has had a paid person supporting the project, and therefore some kind of
> budget. Everything we have done in Docs has been boot-strapped.
I have been through that flamewars and got that point through to
everyone I could possible but you know what? It's high time we moved on.
Goodness, Rahul, in all the email you have ever read from me, how much
time do I spend whining?
The reason I make that point is, "zero" to "where we are now" is not
nearly as bad a picture as the way you paint it: "There doesn't
seem to enough interest or progress being made."
Oh, uh, thanks?
> - And often those were the same people you are berating for
spending
> too much time dealing with "meetings, processes and tools".
That is indeed my point. If we focus more on end user documentation
could the same people have accomplished more instead of say dealing with
the election? Could the irc meetings be say monthly and more discussions
happen on list. Just maybe something to think about.
If you have some good suggestions about how to simplify the lives of
contributors to this project, by all means make them.
There isn't anything I can read in your original email that gave me an
idea you were bringing solutions to the table. It read to me as
flamebait disguised as a mini-rant. And it worked, because here I am
explaining obvious stuff to you instead of doing something *meaningful*.
Everyone who is active is doing a good job. No doubt about that. The
question is only on whether we are having the right priorities here. My
suggestions are going to be simple
1) Dissolve the steering committee and associated elections etc
2) Try and reduce the barriers to the team itself so that we can spend
more time producing solid documentation for end users instead of dealing
with overhead.
Did you catch the last meeting minutes where I brought up the same
points? Was that what sparked this discussion for you?
http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/Meetings/Minu...
So, yes, I've been wondering similar things. But the standing governing
body reached a consensus to proceed as planned with elections and keep
discussing over the next year. Year. Not, "discuss over the next
week." If you want to kick up shit over that decision, fine, but be
aware YOU ARE CAUSING MORE WORK AND STRESS.
Above you profess an interest in helping the overworked, if I read you
correctly. I request you follow Paul's suggestion and do more
recruiting. I can't imagine how it would help a recruiting effort to
say, "Look, they just dissolved their steering committee and now they
just Do Stuff as an autonomous worker collective. Sound like where you
can fit in?"
We supposedly already scare people with all our "barriers" and
"tools"
and "processes", do you really think new contributors are going to be
comfortable with "anarchy"?
- Karsten
--
Karsten Wade ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
1:49 a.m.
Karsten Wade wrote:
First, where is it written that value in Fedora is only measured in
benefit to end-users?
This is the most obvious audience. Everything else is secondary
benefits. You might improve some workflow, some tools but these must be
side effects and not the primary focus IMO.
/me wonders why the SELinux FAQ didn't make it into Rahul's list of
useful stuff. ;-P
The wiki pages have a lot of good information now the SELinux FAQ is
abandoned.
"There doesn't
seem to enough interest or progress being made."
Oh, uh, thanks?
Should be seen in context.
Not, "discuss over the next
week." If you want to kick up shit over that decision, fine,
but be
aware YOU ARE CAUSING MORE WORK AND STRESS.
Just wondering loudly if I am the only one seeing the current situation
as a problem. Looks like it is now or alteast not many
We supposedly already scare people are talking. with all our
"barriers" and "tools"
and "processes", do you really think new contributors are going to be
comfortable with "anarchy"?
There is a lot of space in between anarchy and what we have now. There
have been alternative governance models in other distributions. A single
technical and non technical community team and a lead for example. I
honestly dont see any advantage in having a steering committee in docs
as opposed to just a good documentation team with a lead.
Also my suggestion was limited to using existing resources in a
different way as opposed to recruiting more people.
Rahul
8:22 a.m.
Rahul Sundaram wrote:
Also my suggestion was limited to using existing resources in a
different way as opposed to recruiting more people.
Rahul
Rahul,
I think you should stop criticizing because although I know you have
quite enough interest in continuing the discussion and you're obviously
putting a lot of effort in making your point meanwhile I don't see much
progress being made so basically this entire thread is overhead.
Kind regards,
Jeroen van Meeuwen
-kanarip
--
I'm sure that if you read it again you'll appreciate the analogy made here.
6112
days inactive
6113
days old
8 comments
5 participants
participants (5)
-
Jeroen van Meeuwen -
Karsten Wade -
Paul W. Frields -
Rahul Sundaram -
Rahul Sundaram