Open House
Ben Goodger
is to get involved with the Mozilla project because of the confusion
about where to take questions, discussion; the mysterious private or
unadvertised mailing lists; multiple channels of information
dissemination, etc. Even within established contributors, understanding
what's going on if you're not within one of the central groups can be
very difficult. This sort of thing breeds all kinds of nasty problems
that are not good for the long term health and happiness of everyone.
In mozilla.dev.planning, several of us expressed interest in helping to
fix this problem.
Here's some ideas for what we can do:
COMMUNICATIONS
1. Collect a list of all the private discussion forums (lists, meetings,
etc)
2. Evaluate their content, and determine if they can be done on
lists.mozilla.org lists.
3. Where _specific_ needs exist for private discussion (like security,
partner feedback, release timing) create lists for those discrete
purposes with names reflect those purposes. (This ensures no one takes
general discussion that should be public there).
4. Set up all the required lists.
5. Burninate the old lists.
COMMUNITY
1. Engage with the community to continue to ensure (ongoing) that the
set of lists available via lists.mozilla.org is adequate and relevant (I
think Gerv is on top of this)
2. Advocate lists as the canonical place for development discussion on
the web site.
3. Communicate the list of private lists, why they're private, and how
to use them.
WEB SITES
Now that mozilla.com is the primary vehicle for /product/ distribution,
mozilla.org should undergo a content redesign for usability for
contributors.
Considering the mozilla.org website as a "product" for contributors,
some product requirements might be:
Ability to quickly locate in less than 10 minutes for someone who has no
idea of what Mozilla is:
- what, why and how Mozilla is and operates
- how to get the source and build it
- how to contribute to lists, patches, etc.
- find out what projects exist
These pages should contain only as much information as necessary. Create
a graveyard for obsolete or extraneous documents. Much of the
information in mozilla.org/hacking is very verbose or not optimally laid
out for someone who wants a big picture quickly. And the front page of
mozilla.org is not optimally laid out for this either.
One project that does IMO a really good job of this is the Apache
Software Foundation.
http://www.apache.org/
http://www.apache.org/dev/
I'm not a member of any of those communities, but I was quickly able to
figure out what to do if I were interested in helping.
This is a lot of information to process. I think we should focus on the
COMMUNICATIONS section first, and the rest will be pretty simple.
-Ben
Fritz Schneider
making these improvements. While trying to land safe browsing for
consideration, I would've been completely lost on many fronts (how to
get a component in bugs? how to get an owner for it? etc) if it
weren't for the veteran moz folks sitting around me. I'm still lost
when it comes to some things.
As a concrete example, consider the following. I landed safe browsing
on the trunk for consideration as a base upon which to build an
anti-phishing feature. However I'm not really sure what the process is
to determine whether this features makes it onto the branch, into
Firefox, and in what form. Who decides? What's the critera? Timeframe?
And so on.
Documenting some of these processes would be really helpful to newb like me!
(Thanks for listening).
Axel Hecht
This is a extreme edge case of our obvious problem and I don't think
that your case should be anywhere in our target audience.
Newbs really should start off creating new features for one of our
products worth separate components in bugzilla and own them. Your case
really only makes sense because you have guys to walk you through and
that watch if the stuff you do is useful.
That is not an offence to either you or safebrowsing, but just a comment
that selecting ones target audience is vital to the success of a
documentation project.
Axel