Ian (and everyone),
The difference is two-fold:
- Projects use bugzilla for tracking purposes. Bugzilla has a
database behind it and thus it can be queried, etc. But that's the
minor reason. (I, myself, do not enter website changes for the project
pages into bugzilla when I'm making the changes myself.)
- The major reason is that if we only see the end result (the page
on the website), then we do not see the process by which that result
was arrived at.
- It is by looking at the trail of effort that an outside person
can evaluate whether the candidate is ready to be a committer. For
example, if I see a bug that person X submitted a patch for and then
the committer says "I tried it and it failed" and I see that happen
again and again, I think that person X is not ready to be a committer.
If I see a bug that person X submitted a patch for and the committer
said "perfect, and wow you fixed these other problems too", then that's
good evidence that person X is ready to be a committer.
- Without the bugzilla trail, I only see the result - I don't see
how many iterations and how much coaching went into the result.
- Being a committer is about being stand-alone, so that public
trail of the work is an important piece of data.
I believe that once Nathan becomes a committer we/you/he will stop
using bugzilla as much (at all) and return to your previous processes
(emails, IMs, or whatever). I will have no problem with that.
- Bjorn
The content
is
live on the web site and everyone gets to see it? Maybe I am missing
something?
|
