442024 - Creation of evangelism.mozilla.org (Integrate reporter, socorro, and bugzilla together to a certain extent)

Status: RESOLVED WORKSFORME

(mozilla.org Graveyard :: Webdev, task)

Description

[u88484]

I am proposing the creation of evangelism.mozilla.com after reading Robert Accenttura's blog post on Opera's evangelism tactics (http://robert.accettura.com/blog/2008/06/25/operas-evangelism/).  This website would basically tie reporter and bugzilla together to make an easy to read and put blame and shame on websites for crappy coding/UA sniffing.

The main page should start out with a paragraph explaining evangelism and why no coding to standards or ua sniffing hurts the web as a whole.  Give link to most common sites for code help (like listed on the evangelism template email http://www.mozilla.org/projects/tech-evangelism/site/letters.html).  Next should be a huge search bar, like found on AMO.  The main page should then list out the alexa's top 50 website and make it linkable to all reports filed against the domain then sort by sub domain (or whatever its called).

Yes, the initial setup of this would take a good while but the rewards are great.  I'm sure we could find a lot of volunteers to help sort things out and help out with the creation of pages.

After the initial creation, have a huge PR release about the site and maybe even do a spreadfirefox.com type campaign on spreading the news.  Mozillazine users would sure use it a lot to show people that it is crappy coding by those sites that are causing the problems.  Having a open and freely accessible site to put blame on the sites should be enough reason in its own to shame the companies to a degree and give them the nudge to fix the issues.

Comment 1

[u88484]

I forgot to paste the part about reporter.mozilla.org.

Yes, there is a reporter.mozilla.org but to be honest.  It sucks!  The automation of it does not weed out all the crappy reports like...

URL:http://google.com/
Host:Reports for google.com
Problem Type:Behavior wrong
Behind Login:Yes
Product:Firefox/2.0.0.12
Gecko Version:20080201
Platform:Win32
OS/CPU:Windows NT 5.1
Language:zh-CN
Character Set: 
User Agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Config:--enable-application=browser --enable-update-channel=release --enable-official-branding --enable-optimize --disable-debug --disable-tests --enable-static --disable-shared --enable-svg --enable-canvas --enable-update-packaging
Date Reported:2008-02-13 15:59:42
Description:  

Where is the description?  What behavior is wrong?  Would not be posted on evangelism.mozilla.com.

Next one is basically the same as above with the first three lines.

Description: not letting me connect to website...Coneection has timed out" keeps appearing and all my other web sites work.(myspace, yahoo, photobucket,etc...)  

Definitely not a google problem. Would not be posted on evangelism.mozilla.com. 

My point is I bet 95% of the reports there suck. Everything posted on evangelism.m.c would have a human that read the report and added some technical information. Like if some box padding was messed up, have a link to a site that shows how to properly code it.  Even give a code box that someone can put the fixed code in there for the site.

Comment 2

[Brian Toledo]

What if instead of emailing the contact listed on the site (like @ Opera), a warning page is displayed listing the site as one with problems, like what is being used with phishing?  I would think this would get someone's attention quickly.

Comment 3

[Reed Loden [:reed]]

--> Webdev

Comment 4

[u88484]

This would probably be done best wiki style

Comment 5

[Robert Accettura [:raccettura]]

(In reply to comment #1)
> 
> Where is the description?  What behavior is wrong?  Would not be posted on
> evangelism.mozilla.com.
> 

We decided long ago not to force a description instead opting for more data.  In the majority of cases there's enough that do fill it out.  The rest of the submissions essentially act as "votes" when you view by popular hostnames.  What should really be added is an indicator of which contain descriptions when viewing a list of reports... for much quicker sifting.


> Next one is basically the same as above with the first three lines.
> 
> Description: not letting me connect to website...Coneection has timed out"
> keeps appearing and all my other web sites work.(myspace, yahoo,
> photobucket,etc...)  
> 
> Definitely not a google problem. Would not be posted on evangelism.mozilla.com. 
> 

anything on google.com, and mozilla.com is pretty much crap.  The only way to prevent these misguided attempts is to block the domains (which never sounded like a good idea).  Hence generally... just ignore those.

> My point is I bet 95% of the reports there suck. Everything posted on
> evangelism.m.c would have a human that read the report and added some technical
> information. Like if some box padding was messed up, have a link to a site that
> shows how to properly code it.  Even give a code box that someone can put the
> fixed code in there for the site.
> 

The original plan was it would go into bugzilla (but that's before wiki's really took off).  And YES this is what should happen.  Nobody has coordinated it thus far.  

The data is mined in various ways by various people (including a few webmasters who from time to time poke in and check their sites).  But for evangelism it needs a two stage effort:

1.  Sift/sort/organize - as the above states, find new problems based on the data and document it in a bug, wiki, whatever.  Not to much automation can be done here since the real "meat" here is raw human input (typing).  Machines can't really tell good from bad... at least not until Mozilla2.

2.  Evangelism - contact webmasters and try to remedy issues.

Comment 6

[Robert Accettura [:raccettura]]

(In reply to comment #2)
> What if instead of emailing the contact listed on the site (like @ Opera), a
> warning page is displayed listing the site as one with problems, like what is
> being used with phishing?  I would think this would get someone's attention
> quickly.
> 

I actually implemented something like this at one point as a mockup.... based on safebrowsing code.

It's an interesting concept... but in many cases the bugs aren't obvious to all users (1 thing on an entire page is rendered incorrectly for example).  Now users will wonder "what's wrong?".  This might add confusion where there would otherwise be done.

A better approach might be in the response when a user submits a report to tell if it's an acknowledged issue... but this can get tricky as sites can have multiple separate issues on one page,  or one issue can span multiple properties.  We may know about it, and not even realize it.  Or not know, and think we do.

My concern is ultimately misinformation.  One thing I love about the safe browsing and malware protection is that it avoids misinformation, since it's somewhat moderated.  Keeping a similar design is really important with anything done in this area.

Comment 7

[Brian Toledo]

So, if a wiki were used would this come up with a message pointing you to the wiki when the site is accessed?  Much like when installing an Add-on from an unknown site?  

Comment 8

[u88484]

I created two very rough wiki pages as an example. 
Main page: http://code.google.com/p/uctb/wiki/evangelism
Linked site: http://code.google.com/p/uctb/wiki/test

Yes the linked page is basically a bugzilla bug report but this would be nicely laid out and the whole e.m.o site would be easily searchable unlike sifting through the hundreds of thousands of bugzilla bugs and these issues would be sorted by each domain.

Comment 9

[Reed Loden [:reed]]

(In reply to comment #8)
> and the whole e.m.o site would be easily searchable unlike sifting

Can we think of a different name for besides "e.m.o"? That brings up bad connotations. ;)

Comment 10

[u88484]

I just thought of that when I typed e.m.o. also.  I can't think of anything else except reporter.  Maybe we could just revamp reporter.m.o and make it better and add a wiki.  Keep the raw data separate though and of course still searchable as is currently.

Comment 11

[Samuel Sidler (old account; do not CC)]

See also bug 405364.

Comment 12

[Michael Morgan [:morgamic]]

What do you guys think about input.mozilla.com and its role in this?

Comment 13

[Michael Morgan [:morgamic]]

input.mozilla.org seems to fit the bill.  breakpad and bugzilla have integration points too.

Comment 14

[Samuel Sidler (:ss)]

(For the record, input.mozilla.com – not org – has no integration points with Socorro or Bugzilla. Does Reporter still exist?)

Comment 15

[Michael Morgan [:morgamic]]

reporter doesn't, but there are ties between socorro, bugzilla and support.mozilla.com that are in the works.

Comment 16

[Chris Lawson (gone)]

(In reply to comment #15)
> reporter doesn't, but there are ties between socorro, bugzilla and
> support.mozilla.com that are in the works.

That suggests, at the very least, that this bug is still unresolved, and should be RESOLVED FIXED when -- and only when -- such ties actually exist.