Re: QC draft & community involvement

[P Jenner <psj@mustec.eu.org>]

	I apologise I think my comments were not best phrased and came out
a little strong.  I believe some points remain valid however.

On Fri, 10 Sep 1999, Alessandro Rubini wrote:
> Ok, this is about the part that I left behind in the draft, i.e.: "why
> do we need QC".

	I agree that we do not QC and I think we agree about the kind of
QC we do need - I just ahve questions about the details so that they do
not get in the way of community submission through that QC.	

> > whatever QC exists within the LDP organisation the best QC is the
> > community.
> Yes, but this needs some control.

	I agree with you here. The QC then becomes a community moderator
effectively.

> Every successfull project (I refer here to free sw/docs) has some sort
> of control; be it a person or a group.

	Yes and the role of that person or group is usually not primarily
producing but harnessing and organising the production of others. For
example on the GNOME project. A central core team organises the overall
development, web site etc. A larger group, not all known to the core team,
has CVS write access to the GNOME source archive. These people are knoen
to produce good and responsible work and are trusted to have write access
after asking for it. The larger community as a whole has CVS read access
and distribution access. They either bug-report via the web / e-mail or
preferably submit patches to those with CVS access who include them,
modify and include them or reject them as appropriate.

	I apologise for the length of detail in that description but I
think all of it is worthy of note. The system works because there is a
core team capable of harnessing energies and organising things (LDP
leaders and QC people), there is a wider group of developers who can write
to any part of the project but who only tend to produce good stuff as they
are committed and trusted (HOWTO maintainers and regular contributors) and
all others users who can make an improvement to the project have there
contributions faciliated by an easy to get involved system (LDP readers).
I am just worried that the QC manifesto could be read as saying simply
there should be only QC and leaders who can write documents to the LDP,
HOWTO maintainers are the only ones able to alter their own docs and then
only via QC and that all other users must go via maintainers who may not
have time or energy to facilitate their contribution.

> For the LDP to be successfull we need the same kind of control: bad
> contributions must be refused and mid-good stuff must be sent back to
> the author for making it better.

	I agree with the upshot. What I believe may be more profitable top
learn from the Open Source movement is that bad contributions should be
rejected with a clear explanation why and mid-good stuff should be worked
on by those able to (QC and contributors) to make it good.

> We just can't allow a crowd of newcomers to flood the LDP with
> low-quality material, as it will just lower the social role of the LDP
> as a whole.

	I agree.  However if their contributions are simply rejected
off-hand or not facilitated then any good stuff they may generate will be
lost to the movement most probably forever. I would argue anyway that
unless someone believes that something is genuinely useful and good they
probably would not submit it.

> Please note that *nobody* is preventing anyone in the community from
> releasing other documents through other means (I also wrote this in
> the draft), we just need to protect the brand of the LDP.

	I would have thought that this is probably not the best way
forward. If doc is good then the LDP should embrace it for the community.
If doc is bad then the community will ignore it and it will go unnoticed.
There is good doc out there which is not part of the LDP and could be if
facilitated.

> Since we can't ask Tim nor Guy to check every document that they get,
> we need to set up a group of people to split the workload.

	I agree strongly and I think we agree that this is the reason for
the QC.

> > Therefore community additions and modifications should
> > be given as much weight and consideration as official QC ones,
> I'm sorry, I don't understand this point. As usual, additions and
> modifications pass through the maintainer, unless someone wants to
> fork document maintainance (which is generally considered a practice
> to avoid whenever possible).

	I did not make myself clear - I apologise. I really meant to say
that submissions for corrections to the QC or maintainer from the
community are just as likely if not more likely to be valid than those
generated purely by the QC or maintainer alone. I know personally than
when I write anything, if I ask others they always without fail suggest
improvements I would never have seen alone. The community has a great
number of eyes for such a job - we would be silly not to use them.

> Oh, and I forgot to state that the LDP leader should be able to revoke
> a QC member with no prior notice. This is important, as one with a
> good resume could be accepted in QC and then boycott things out.

	This is the reason why I am not totally convinced that one QC
should be able to boycott things out. After all the community may want
something different from a HOWTO than the QC does. For example a QC may
have a strong idea that all docs should be vendor neutral but the
community could be having real problems setting up PPP under Red Hat
particularly. A member of the community may submit a ptach to the PPP
HOWTO covering that issue - something LDP readers could really use.
However the QC would reject it alone. Surely not a good thing.

	I hope these comments are positive and I hope you don't mind but I
CC'd ldp-discuss with this one as I believe certain of my comments here
are probably of discussion interest to others (if only to flame me :-).

	Yours,

	Paul

   -----------------------------------------------------------------------
	Paul S Jenner
	GNU/Linux Advocate

	E-mail:	psj@mustec.eu.org
	WWW:	http://www.mustec.eu.org/~psj/

	UNSOLICITED COMMERCIAL E-MAIL IS NOT WELCOME AT THIS ADDRESS
   -----------------------------------------------------------------------


--  
To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org