On Mon, 2007-06-18 at 18:19 -0400, Sam Folk-Williams wrote:
Karsten Wade wrote:
> /me approved this non-member post
> On Mon, 2007-06-18 at 11:42 -0400, Chuck Ebbert wrote:
>> On 06/18/2007 10:42 AM, Sam Folk-Williams wrote:
>>> Thanks for the explanation Karsten. Makes good sense. I wonder if this
>>> page should be a community page and not a formal page? I took the
>>> initiative to create it, but I'm not the subject matter expert. We
>>> definitely need those subject matter experts (like Chuck) to be able to
>>> edit. If making it a community page is the best way to do that then
>>> perhaps we should.
>>> Or if we could add specific people to the ACL for this page it that
>>> would also be good.
>>> Chuck - do you think this page should be editable by anyone or should we
>>> control access somewhat?
>> I think access should be controlled.
> Note that access is controlled in that one needs a Fedora account to
> edit the Wiki pages.
> I'm inclined to think that we want to have this be editable by account
> holders. Only ones with an interest and knowledge in the subject are
> likely to edit it, and Sam and others watch those pages, and he can run
> any questions by Chuck and others.
>> Maybe we can just tell you what
>> needs changing...
> It's good to work with the writer who is working on the content,
> especially if he is amendable to being the 'mouth piece.'
> However, if it is easy enough for a subject matter expert to fix it,
> that's probably the best way; then Sam or others can clean up the
> language, etc. Aside from the value of community documentation, as we
> do with community code, there is the fact that Fedora writers are
> volunteers who can use all the help we can get. :)
I think part of the problem here is that I don't necessarily see a BZ
like this one that gets filed. I made those changes.
If someone needs to make changes and they aren't an account holder... do
they email me directly? Do they email this list? Open a BZ?
Any official documentation should have a link to a pre-filled Bugzilla
ticket. Here's what I find works best:
1. Fill in everything *except* the Summary. Filling in the summary
encourages people not to bother with it, meaning any bug list will have
meaningless boilerplate text there.
2. Include very short boilerplate text in the Description field, such
as "Include details on problem here."
3. Log problems to the "docs-requests" component. These are pretty
general, and a copy goes to this list so any subscriber with access can
try to fix the problem.
4. Surround the link (best turned into a TinyURL, see
to get one) with a bit of text about why the person
might want to use it. We have boilerplate language in several
documents, such as here:
Email to the list isn't a problem but requires the person to join the
list first, which isn't fun when they just wanted to inject a couple
lines about what's wrong.
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
: stickster @ #fedora-docs, #fedora-devel, #fredlug