SUMO and communication
Majken Connor
wrong. I'm trying to point out things that I think we're not getting right
or could get more right. I think there are still some important ways SUMO
could improve how it communicates with and, (hopefully) therefore, grows the
community and participation.
- Contributor forum -
We moved (and I pushed for this) contributor discussion to the Contributor
forum on the site itself, to try and reduce the number of places people had
to go to stay informed and involved. This is a good decision as Tiki gives
us the options of email watches, as well as an RSS module, which are the
benefits the newsgroup gave us. Except for some reason email watches are
broken in the contributor forum since at least last September
https://bugzilla.mozilla.org/show_bug.cgi?id=454629 Looks like RSS support
has landed a few months ago (yay!)
https://bugzilla.mozilla.org/show_bug.cgi?id=454629 but isn't enabled.
I understand that this is on the radar and will be taken care of at some
point, and that's great and it's not the end of the world. I do think it's a
serious setback to building the community, though, not having this ability
for 6 months.
- Monday meetings -
I have a few suggestions for improving the experience of contributors who
may wish to attend these meetings.
1. Give better notice when a meeting will be cancelled. Preferably by the
Friday before.
2. Post the agenda to one of the communication channels - blog, newsgroup,
contributor forum - further in advance of the meetings, again preferably by
the Friday previous. Encourage people to suggest things to add to the agenda
or share their thoughts before the meeting if they can't make it.
3. Try and make the minutes a bit more informative, include a bit more meat
of what was discussed and more links to where discussion and work will
continue
- Goals/Milestones -
We need more dynamic communication about quarterly goals and more chances
for our contributors to give suggestions on how to accomplish the goals.
Posting the roadmap at the beginning of the year is a great step, but it's
also overwhelming and doesn't do the best job of letting people see where
they can help out. I would love to see more regular communication of the
next quarter's goals and milestones that helps break things down into easier
to digest chunks. Specifically what the goals and milestones are going to
cover and why. I think this would be appropriate in the contributor forum or
the newsgroup. Chris posted on the blog about the 0.8.2 push after it
happened. I think it would be great to post little summaries of the changes
on the blog after every milestone.
- SUMOdev Meetings -
What happens in these meetings vs the Monday meetings is very cloudy to me.
On the one hand I've been told that they were specifically for webdev to
triage and assign bugs, on the other hand I've been told that this is where
decisions were made with the SUMO team about the screencast goals and
implementation. Currently there isn't much communication with the community
about when these meetings take place as well as what they intend to cover or
what decisions were made in them.
- Newsgroup -
I think there's room to use the newsgroup to discuss development and feature
planning, as well as alert people which meetings are going to discuss which
features. I see PRDs and such for several features linked from the SUMOdev
meeting notes and on the Roadmap, but both of those links aren't
communicated very broadly, and keeping on top of news and changes would
require watching a lot of wiki pages and that new pages are linked from the
old ones.
I'm not trying to say that the pages aren't good. Of course they are, and
they fill their purpose very well and are definitely informative. Just that
their purpose is limited and they can be hard to find. Keeping people up to
date on what's being worked on could really use something more dynamic.
Something that helps people find and discuss these pages more effectively.
paulc
but here's my two cents.
I think you've made good points, especially about communication. I
know when I started out I would have liked to be presented with a
place from which I could start chewing my path to decide best what to
do, how to help, etc. Instead I had to find places for information
myself (wiki, intranet, google docs, newsgroups, irc, bugzilla, etc).
Often times those were impossible to find and so I had to ask people
for resources. And then a good part of those times nothing was ever
written so I talked to people to find out. So yes, I had and still
have this impression that sometimes what happens at Mozilla is chaotic
and undocumented, which comes with the degree of flexibility and the
OS attitude (certainly the "module owner" concept plays a role). This
stuff happens in any company, though.
The best thing I could say is that we're understaffed to do all of
this communication, though it is a habit and maybe some restrictions
could be enforced so that people communicate and document their doings
more. Certainly centralizing everything to one site, one place, that
could handle all our needs, would help, but takes so much work... It's
good to keep suggesting things that need to be done, eventually they
pick up... so I'm glad you pointed out so many issues.
On the SUMOdev piece: I attend those meetings. They're usually short
and focus on implementation (webdev). Many times that also connects to
what goes into which milestones and how much of what we hoped to do is
going to get done. I think having the community prioritize would be a
good idea, but I don't think having many people attend these meetings
would be productive. There should instead be other ways for the
community to show the devs what priorities they have - there's simply
no time to talk to all the community members and get feedback. So
maybe polling at the beginning of one quarter for the focus goals in
the next quarter (e.g poll in January for April goals). Community
feedback is most useful to decide what to do next. Trying to have the
community affect development as it's being done will likely lead to
the moving target problem... That said, I agree that it's great to get
the community more involved and make it easier for them to do so. So
it would be nice to have a place for devs to place ideas that they
would like feedback on from the community.
Majken Connor
things you've said, I don't see how it applies to what I've requested.
I'm very worried that what you're trying to say is that the SUMO team
is too busy to make a blog post saying "we're working on this PRD,
please share your thoughts" or "We just made a push, here are the
things we improved." Or even "Hey no meeting on Monday."
We had fewer people working on SUMO when it was created and if you
look at the newsgroup back then it was very vibrant. Obviously
discussion is still going on, or progress wouldn't be made. I think
moving that discussion back somewhere (eg the newsgroup) that it can
be followed is solving at least half the problem. It matters less if
you have time to stop and blog about it if it's somewhere that people
can access on their own time.
I'm also concerned with the idea that staffing needs to increase to
increase communication. Mozilla is a community project and this is
demonstrated nowhere better than SUMO. Communication should already be
a priority. Sure webdev might be too busy as you've all got different
projects, but the SUMO team itself should be able to make this a
priority if nothing else. Maybe even make a community member
responsible.
-Lucy
> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>
Majken Connor
> I respect everything you've said here on the surface, but several
> things you've said, I don't see how it applies to what I've requested.
>
> I'm very worried that what you're trying to say is that the SUMO team
> is too busy to make a blog post saying "we're working on this PRD,
> please share your thoughts" or "We just made a push, here are the
> things we improved." Or even "Hey no meeting on Monday."
>
> We had fewer people working on SUMO when it was created and if you
> look at the newsgroup back then it was very vibrant. Obviously
> discussion is still going on, or progress wouldn't be made. I think
> moving that discussion back somewhere (eg the newsgroup) that it can
> be followed is solving at least half the problem. It matters less if
> you have time to stop and blog about it if it's somewhere that people
> can access on their own time.
>
> I'm also concerned with the idea that staffing needs to increase to
> increase communication. Mozilla is a community project and this is
> demonstrated nowhere better than SUMO. Communication should already be
> a priority. Sure webdev might be too busy as you've all got different
> projects, but the SUMO team itself should be able to make this a
> priority if nothing else. Maybe even make a community member
> responsible.
>
> -Lucy
>
> On Thu, May 7, 2009 at 3:07 AM, paulc <paul.cr...@gmail.com> wrote:
>> support-planning mailing list
>> support-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/support-planning
>>
>
Been doing some more thinking about this while waiting for more people
to jump in. I want to be specific about something that might not have
come across in my original post.
I'm not saying that we shouldn't make decisions without collecting
feedback from the community first. In fact that was one of the things
that frustrated me early on. While none of us had previous experience
running a support operation, in theory we were all brought on because
we had specific skills and experiences that would lead us to make good
decisions. I absolutely think that design by committee or turning
everything into a democracy is counter productive and disrespectful to
the people supposedly hired because they knew what they were doing.
My problem though is that we still need to give the community a chance
to weigh in. Especially in Mozilla's context we're going to get
interested people with experience themselves. In the cases of the PRDs
where these are things composed over time there's definitely no reason
not to give the community the chance to weigh in, in tandem with the
work being done. This won't make anything take longer, unless of
course someone has some really good ideas that mean we need to
rethink.
In terms of other decisions that happen faster, I think the adage
"strong opinions loosely held" is really appropriate. If one of our
team members or leaders has an idea or makes a decision that they feel
strongly about, they should absolutely be allowed to pursue that. But
I think the community still needs to be kept informed of the
decisions. Maybe someone wants to help, or maybe someone had a similar
idea and would have been doing redundant work. Or maybe someone has
some experience that gives them insight into why the decision should
be handled differently.
It's also incredibly valuable for people who come in later in the game
and want to understand past decisions. If they can understand what our
goals have been and what has been driving development and process it's
easier for people to participate more effectively and make more
relevant suggestions and ask more relevant questions.