[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QC draft
> However I am slightly worried about how the implementation of the
> mainifesto may impact community quality control.
Ok, this is about the part that I left behind in the draft, i.e.: "why
do we need QC". I assumed there was consensus about that, but it looks
like some explanation in needed. Please note that I am not the one
who suggested to have a QC group, however I support the idea based on
relevant errors I've seen in the technical press (some with no QC
> whatever QC exists within the LDP organisation the best QC is the
Yes, but this needs some control. People who trusts the LDP expects to
find correct information in the documents; if the information is
inaccurate or plain wrong, the LDP will just crash and nobody will
trust it any more (read: a lot of work gets lost).
Every successfull project (I refer here to free sw/docs) has some sort
of control; be it a person or a group. The simplest example is the
kernel: when you get the official Linux kernel you know that Linus
approved it, and Linus *refuses* a lot of the patches he gets (thus,
he's a QC entity).
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. 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.
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. 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.
> 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).
> such community submissions should be facilitated and encouraged as
> they are so successfully with Open Source code
Sure. And that's why we can't rely on one or two people to check it
all in order to guarantee the LDP brand.
> if QC modifications are consistently rejected by the community then
> that community should be respected - after all that is who we do
> this for.
Once again, I didn't understand.
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.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org