Organisation of Discourse within Mozilla

Archives Community Ops/Discourse
#1

Currently the organisation of the different aspects of Discourse within Mozilla is a bit messy, with there being no real separation of those rather different areas, and everybody doing a little bit of everything. While this worked well to begin with, now I feel it’s actively harming our expansion, both in bringing in new contributors and in expanding to more areas within Mozilla.

As I see it, there should be three Discourse teams: frontend, backend and dev.

Backend encompasses:

  • Hosting Discourse

Frontend encompasses:

  • Requesting new features
  • Triaging requests for new features
  • Prioritising the importance of requests for new features
  • Creating categories
  • Moderation

Dev encompasses:

  • Thrashing out the technical details of requests for new features
  • Creating new features (through plugins & upstream)

Of course, that’s not to say there won’t be lots of communication between these teams, and people contributing to more than one.

Thoughts? I’ll update this list based on replies, and add some of my own below.

#2

This post was motivated by my own frustration at me seemingly being the judge, jury and executioner when it comes to extending the functionality of Discourse to match Mozilla’s needs. The great ideas from both within and outside of Community Ops of what features we want in Discourse - a lot being in old threads I’ve been looking through, because of my recent work on discourse-mozillians - seem to live and die based on my ability to remember them and commit time to programming them. It’s a very solitary experience - it doesn’t feel like there’s any team behind me, let alone around me.

I accept that some of this is down to me maybe not designing things with participation in mind, but I’m fundamentally not a… participation-er. As the badge says, I’m a bit of a code monkey - I’m a programmer whose skills seem to lie in writing code with the help of little documentation and with very little clue how or why it works.

But I feel as if a more ordered structure would allow the dev team (or, currently, me) to stick my hand up and go “Hey! I need some help from participation over here” a little more easily.

Some other thoughts:

I’m not entirely convinced myself of the split between frontend and dev. They feel somewhat different, but maybe dev is more of a subset of frontend.

I’m thoroughly convinced of the need for a split between back and frontend. I don’t care how Discourse is hosted, as long as it is hosted.

We need to re-evaluate the tools each of these teams uses. In my mind, for the things I’m working on, the JIRA experiment hasn’t worked. I don’t want to be spending half of my life updating JIRA with the things I’ve said on Discourse because of the things I’ve done on GitHub, particularly because there’s such a high barrier of entry to JIRA that basically nobody looks at it. I’ve been attempting to use it for the past few months and mostly failing, so what hope does a new contributor have to understanding how to use it? What hope does an old hand at Mozilla who wants to lend their expertise have?

Furthermore, I feel like a more formal structure will mean better organisation of topics on Discourse. I want a place I can spam with stuff on plugins, give status updates, and thrash out ideas of what to work on next.

I think we should take inspiration from the Discourse project itself. (As far as I can see) they don’t have a public facing issue tracker other than Discourse. Releases, bugs, documentation and feature requests, rfcs and tech specs are all on Meta Discourse. I think if we want to show how versatile Discourse is to the rest of Mozilla, we should at least be eating our own dogfood rather than using all manner of 3rd party proprietary tools.

Pinging various people who might not see this discussion, who I think can provide useful input, observations and experience (and who I can think of off the top of my head): @r_oVhPfcJCUUC5wbm6i4_C2Q @gerv @pierros @george @comzeradd

#3

I agree that there are like three profiles of people involved:

  • The team that hosts the forum (Community Ops)
  • People moderating and thinking about specific needs (Community Ops, community managers and some functional leads)
  • Devs interested in helping with the identified needs (Community Webdev project maybe?)

Also I think we haven’t been able to communicate between these groups very well because the roles had been very informal.

With the increase need of relying on Discourse for different initiatives I think we can figure out how to solve this in a more formal way.

2 Likes
#4

I can attest that jira is potentially useless for a new contributor (me?). I logged in to jira after hearing a lot about it in #communityit to figure out what’s happening with community hosting. What I was presented with was Dashboard - which was totally empty for me. Then, on the top navigation bar there was link to Projects - and I chose Community hosting. Almost 85% of screen space was useless on that page. In one column there was somethings that looked like github issues. On clicking any I see a something popup on right side with a lot of details about dates, status, people, etc. But no info on what that issue is about. Only then do I scroll down that issue and figure out there’re comments on bottom. And then I’ve to repeat this for all the issues on the board.

Basically, jira hides everything from you.

But using a discourse category with subcategories for ideas and development would instantly solve the problem of visibility.

2 Likes
#5

Honestly, the only thing I like about Jira is the kanban board. I want Jira for my life, because it would work well to help me organize stuff personally, but I still don’t understand why we’re using it for Community Ops.

#6

I’m not a fan of using 3rd party (especially proprietary ones) services for infrastructure Mozilla already has in place (eg. Jira, Confluence, etc).

I agree with the team separation Nuke made. Modifying Discourse and implementing features has nothing to do with operations, so it makes sense to live outside Community Ops.

So the team (currently just Leo) “responsible” for doing development work on Discourse should have the final word on where to host and organize development ideas and feature requests. To be honest my first thought was Bugzilla, but Discourse project itself uses a Discourse instance for this job.

2 Likes
#7

These “teams” in my mind have always existed but since there’s a handful of people working on Discourse, everyone does a bit of everything. I think we’re at the point now where these teams have a lot of stuff to do individually we’re going to need to separate them a bit further. Some help around development is definitely needed but I think due to it all looking like it’s one team under Community Ops, devs aren’t interested.

I think this is related to

Up until recently we had both the frontend and backend mushed together in a single JIRA project which made the difference between them not really clear and overall not very nice to use for either purpose. I made the infra project to try and solve that and it has it’s ups and downs but I haven’t customized it too much. Something inbetween a simple project and an agile one would be ideal (which i think is essentially what bugzilla offers).

#8

I think we agree on ‘dev’ being a separate team, but having thought about ‘frontend’ a bit, it seems odd to me to have Community Ops as one of the teams driving it. It certainly will involve people from Community Ops, but not doing ops things.

I suppose it’s somewhat ironic that this topic is currently in the Community Ops category, but this seems to be the de facto (but I would argue, wrong) place for these sorts of discussions. Indeed, the whole structure seems backwards to me currently - everything seems to be a subset of Community Ops. Instead, I think there should be a Discourse team which then tells Community Ops and Community WebDev what it wants out of them.

So under my envisaged structure, the default (and proper) place for almost all discussions about Discourse would happen in the Meta category, with Community Ops/Discourse being for discussions about infrastructure and maintenance and so on.

Urrrrrrrgh. I am interested in feedback from people about JIRA, but I now realise I probably should have done it in another topic, because it’s made this discussion almost as mushy as our current Discourse structure. :stuck_out_tongue:

I think it’s an important discussion to have, but I think it only makes sense to have it within these separate teams because, as others in this thread have said, different teams are going to have different requirements.

@Kensie I feel your voice lacking from this discussion so far, not only because you’re the project manager for the team which Discourse currently resides under, but because I would see you as the Discourse team manager, too.

#9

You are right, I agree with that, Community Ops should be in charge of Ops but not leading by default Mozilla Discourse evolution.

That would give us:

  • A Discourse team in charge of thinking how to improve, promote… (ideally formed by cross functional people)
  • Community Webdev to implement features or changes needed.
  • Community Ops hosting the tool, as any other tool
1 Like
#10

Yes, I’ve been busy.

Yes, you shouldn’t have brought up JIRA here :-p You can’t say the experiment hasn’t worked without defining the bounds of the experiment. We’re not even done figuring out how we want to use it, and it’s definitely gotten zero love with regards to the experience for someone who isn’t on our team. For keeping people informed who aren’t on the team and doing hands-on work, the pathway is still supposed to be Discourse.

We have a plan to make communication better, but we’ve been slow to implement it. Slightly frustrated that the result has been to start a totally new discussion topic without that context, rather than helping to implement the plan we already have. We need to announce the “Using Discourse” category, which was waiting on organizing the topics. If someone wants to help with that, let me know.

I agree with the 3 categories of contribution. They look good, and the don’t really seem like anything revelatory based on how we’ve already been thinking. We just need to start making more progress. It’s a catch 22, we need more hands. We haven’t had many people saying “can I help?” We need more of that.

Rename "Using Discourse" back to "Meta"
#11

I said the experiment hadn’t worked for what I’m working on, not generally. For what I’m working on, it gets in the way.

I think Discourse should also be the method of keeping people involved who are on the team. Furthermore, there’s a whole loads of JIRA issues which need discussion before they can be done, discussions which should surely be happening on Discourse.

But I didn’t intend this to be a discussion about communication, I intended this to be a discussion about the organisation of Discourse within Mozilla.

I think this should be renamed back to Meta, and should be where the Discourse team discussions happen, but I’ll start another topic about that.

They’re not just categories of contribution, though, they’re separate teams. Different categories of contribution doesn’t stop discussions which have nothing to do with ops happening in the Community Ops IRC channel, in Community Ops meetings and in the Community Ops category here.

Rename "Using Discourse" back to "Meta"
#12

Should we then move this topic to Meta? :wink:

#13

We should, but as I said here, this is currently the default, but wrong, place for discussions about Discourse. Also, since we don’t currently have a Meta category, I think this category was maybe the better fit.

#14