making review/bug filing optional for some docs changes

[Myk Melez]

Shane H. W. Travis wrote:

>That is, in part, what this discussion is about; lowering the bar so that
>documentation patches can get in more quickly/with less effort, so hopefully
>things stay more current.
>  
>
For me, that's entirely what this is about: removing bug and review 
requirements for certain kinds of changes to make possible more and 
better documentation.  Note that unlike Gerv's earlier proposal I'm 
suggesting we remove these requirements for small changes and additions, 
not large ones.

>This, then, is part of my problem. It seems like people are saying, "I'd be
>happy to contribute! I just love writing documentation... but you've got all
>these messy *procedures* in the way that are stopping me."
>
That's not what I'm saying.  I'm saying that I *don't* love writing 
documentation, but I do understand the importance of it, so I *am* happy 
to contribute, but I have limited time to do so, and if I spend time on 
process I won't have it to spend on documentation, which means I'll be 
able to contribute less documentation, and the value of the 
documentation I won't be able to contribute is much greater than the 
value of the improvements to it that going through the process will provide.

>The underlying
>message seems to be, "If I can't have complete and free access with nobody
>else restricting me, questioning me, or second-guessing me... then I just
>won't do anything at all."
>  
>
That's not it at all.  I just think that for some kinds of changes such 
restrictions, questions, and second guesses are unnecessary and harmful.

>The prevailing argument is that documentation could be fixed later... and I
>agree that it could, *if people notice that it needs fixing*. The people
>reading the docs are not, typically, people who are completely conversant
>with Bugzilla.
>
That doesn't make them incapable of figuring out when the docs are 
wrong.  After all, they may not know Bugzilla, but they're reading the 
docs specificly to apply its instruction to their copy of it.  If the 
docs are wrong, they'll figure it out, because their Bugzilla won't do 
what the docs say it should.

Of course, this doesn't obviate the need for us to minimize errors in 
the docs before we ship them to our users.  But shipping errors in docs 
is not the end of the world, and we have to balance efforts to reduce 
the error count with their cost.  In my mind, requiring one review for 
all changes and a bug for every fix, regardless of how large or 
controversial the change is or how good the documenter is at writing 
good docs, doesn't balance these costs and benefits well.

>I have University credentials as both an English Teacher and a computer
>programmer. I have contributed quite a few code improvements to Bugzilla. I
>have fixed more documentation bugs in the last six months than anyone else
>has in the last 30. If anyone was going to be awarded Trusted Docs Hacker
>status, I'd like to think that all of those things would put me on short
>list... and not only do I not want the honour, I don't think that the
>position should even exist.
>
That's OK, you don't have to accept the position.  I'm not suggesting 
that quality Bugzilla documenters should be forced to go without review, 
and I certainly don't think it should have anything to do with how much 
documentation you've contributed in the past.  It should be awarded 
solely on the basis of known capability to write good docs, and anyone 
who gets it should be able to choose to have all changes go through 
review if they so desire.

>Just because a girl isn't as popular, doesn't mean she should 'put out'
>more so people will be willing to be with her; just because documentation
>isn't perceived as a glamorous (or even, sometimes, valued) contribution
>doesn't mean we should relax the standards on it.
>  
>
Sure, but glamour and value has nothing to do with it.  I value docs, 
and I'm suggesting this change because I think it will make them better 
(higher quality, more comprehensive), relaxing the process, not our 
standards.

-myk