175024 - Evangelism - Process and Procedure definition

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Bob Clary [:bc] (inactive)]

Summary says it all. Please add comments on how we can improve our process to be
more effective and recruit more help from others.

Comment 1

[Bob Clary [:bc] (inactive)]

Note that the process should support bug 175026 as well. How do we categorize
bugs so that we can determine trends and documentation needs. I am not sure that
the current 'procedures' are effective for that. Comments and suggestions welcome.

Comment 2

[Brant Gurganus]

If the Evangelist believe there should be documentation for a bug, I think a
keyword of "NeedsDoc" would work.

Comment 3

[Bob Clary [:bc] (inactive)]

The use of a status whiteboard value to flag an issue has merit. We also need to
try to find the issues which benefit the most from documentation. How do we
discover and track those so that we can determine that document a will benefit
100 sites while document b will benefit 10?

On another note: I think we have relied too much on "official" communication
from evangelists to convince sites to update. I think the reporters and any
other person who is concerned about a site, should take the initiative and
contact the site as "a customer" and tell them that the site is broken for them.
If enough people care about a site and complain then we will have more of a
chance to convince the site to change.

Comment 4

[Jacek Piskozub]

> I think we have relied too much on "official" communication from evangelists
[...]

True. We should do both. In Poland there is an organized group of users around
www.mozillapl.org server. They write directly to the offending companies *and*
report bugs to Bugzilla at the same time. This way the company gets feedback
both from the users and us. Sometimes this work. But not always :-(

Comment 5

[Bob Clary [:bc] (inactive)]

juguero on IRC mentioned promoting open source in non-profit organizations. That
sounds like a good technique as well. 

Comment 6

[Bob Clary [:bc] (inactive)]

Started using TECHNOTE-NEEDED and TECHNOTE-DONE in bug 177888. What do you
think? Ok to make official?

Comment 7

[Brant Gurganus]

On second thought, I think we should search Documentation > Web Authoring and
make sure the issue is not a duplicate.   If it is a new issue, we should file a
bug with a description of the issue.  Whether it is a duplicate or not, we
should mark it as blocking the appropriate documentation bug.  In this way, we
should be able to sort by number of dependencies for bugs in Web Authoring and
there are also examples of the problem under various conditions so that the
final documentation will be complete.  This method will have to be discussed
with the Documentation people probably, though.

Comment 8

[Bob Clary [:bc] (inactive)]

Good point that we should make sure there is not an existing documentation bug
for the issue and that we should assign them to the documentation product. That
would help others who are involved in documentation but not involved in
evangelism see that the tech note has been scheduled. We should also discuss it
with the documentation folks.

Upon review of the existing documentation bugs however there do not seem to be
(m)any that relate to the kind of tech note I was envisioning. Short to the
point note about a specific issue. In the example above it was about the
addition of objects to forms in 1.2+. These issues could arise from our triaging
evangelism bugs but could also be used by developers and qa teams to flag an
issue that should be documented.

For new tech note needs I don't want to do a default assignment to
documentation. I would rather have someone who is committed to writing the tech
note assigned. The person filing the tech note bug should either commit to
writing it or find someone who will write it in a reasonable time frame.
Otherwise we will just have documentation bugs and no tech notes. Any person who
is interested in documentation can also query tech-evangelism for
TECHNOTE-NEEDED and sign up to write it as well.

I think that the dependency/blocking of bugs kind of gets involved. I think that
once the tech note exists, whereever it lives, we can make a list of the
technotes and the problems to which they apply that evangelists can use when
composing their messages to sites.

Comment 9

[Bob Clary [:bc] (inactive)]

adding new bugs for the bug field and qa documents.

while triaging a bug that someone closed today, I realized we don't have
instructions on verfifying bugs nor on prohibiting closing bugs until
mozilla.org policy allows closed bugs.

Comment 10

[Bob Clary [:bc] (inactive)]

tech evang june 2003 reorg
fixed