Next steps for Discourse

Meta
#1

Hey all,

Now that we’ve got this up and running with one or two minor things that need to be addressed, I think it’s time we start to look at how and where we want to use Discourse. There are two things that stand out to me at the moment:

  1. Creating a procedure for Mozillians to get a category created for them
    • Should we require approval from anyone? Who should they be? Reps or other?
    • Who will handle creation of the categories?
    • Bug for form on bugzilla
    • One suggestion I’d like to put forward is that while each category will have their moderators, their powers will be global (obviously only stepping in for other mods when needed). This would be beneficial if we have any spam and that particular category’s moderator isn’t around.
  2. Start reaching out to communities who we think Discourse would be useful to
    • I’ve already talked to multiple people and we have both the SUMO Hindi l10n community and a small mentoring group for marketing emails interested in using Discourse.

Thoughts and questions would be appreciated!

1 Like
#2

Some interesting points, I think it would be great if we allow everyone to do it, but we should probably have some policy about disputes over control. Both IRC and now Mozillians have basically curated groups with ownership, we should try and borrow as much policy as we can.

What would be really awesome is if we could integrate with Mozillian groups somehow. So the group curator can be the category owner. In come cases though teams may want to hand off moderating the discussion forum to someone else.

1 Like
#3

I wonder if we need rigid controls initially. There’s something about being very open and flexible to allow users to see how/where Discourse can fit.

I’d suggest something like that while we figure out the Module Ownership & Peer structure for Discourse and whatever category creation process/polices are necessary. One shouldn’t block the other and one probably requires some greater understanding of how Discourse fits into the world.

1 Like
#4

Totally agree with this, This is more of a “looking forward” thread. Right now we will use the bugzilla form to take requests from everyone for anything, but it would be nice to be thinking about how we will deal with this in the future.

As far as I can tell, Discourse doesn’t yet allow category specific moderators, so we’d have to keep that in mind.

William R also brought this up, either myself or Tanner will post to the dev mailing list asking for people who can help us be able to restrict certain categories to Mozillians only, and further down the line maybe get rid of discourse groups entirely and pull from the Mozillian’s groups.

#5

I moved a post to a new topic: Yammer and Discourse

#6

I think the procedure should be similar to requesting a new mailing list, which is open to anyone with a light policy to control what’s created.

#7

I agree. Once Discourse had a module owner, they and the peers should be
able to approve/reject requests. @Jan wants to approve colors for the
category, so that they fit his theme, and I have no problem with that.

1 Like
#8

I’m on the fence about policing the colours :-p Though I’m curious how this would work anyway, we use institutional colours so at some point we’d run out of combinations for teams. I think we should just let people pick the colours they want.

#9

Good thoughts.

It doesn’t feel like it makes sense to policy the colours, at all. They aren’t really used much except in a rectangle for each category. In fact, I think that it’d be quite cool to have a rainbow of them across the forum.

Maybe @yousef @jan or @tanner could make a bright pink category, just out of interest to see how it looks?

#10

That’s my exact thoughts.

After speaking to @comzeradd he seems happy to take it into the hosting approval queue (where bugs from the WIP bugzilla forms will go anyways), but I’d like to know the groups thoughts on this?

#11

Fair enough. I would prefer we don’t have any colors that make eyes hurt, at least… Hot pink, bright yellows, etc. probably aren’t good.

#12

Yeah, I’d prefer it too, but shouldn’t be a policy.

Maybe we could ask communities not to request such things (alongside ridiculously long category names)? If someone continues to request a over-the-top category colour, we should probably ask them if there’s any other colour that they could use, but not specifically say “No”, and carry on with the request if they still want the colour.

#13

I’m coming in late - for me curated groups and discourse are the perfect match. Is that not the intention?

#14

Perhaps we can start by trying to restrict it to the Mozilla family of colours: orange, red, blue, grey, yellow, purple.

The idea is to make it easy to see at a glance what category something is without having to read the label. We might be able to go pretty far with combinations of colours from the above families.

#15

We are a small, but growing, group of intrepid community members (staff and volunteers) that believe Mozilla should help protect the web through Machine Translation.

For more information: https://wiki.mozilla.org/Intellego

#16

Can we please stop creating a new category for each project a group of people is doing in Mozilla? If everyone did that we would run out of colors, and space and create chaos on categories space.

Please try to Create over-arcing categories like Education, Coding or things that would actually have sub-categories :smile:
Thanks!

#17

@pierros we’re discussing creation policy here.

BTW, categories can be edited at any time and assigned a parent or have their colours changed.

#18

Keep in mind that there is no such thing as sub-sub-categories. In case we want dev/planning/firefox we should think about what the parent category would be.

#19

Or we should hack sub-sub categories :wink:

#20

Sounds like something we could do with a plugin, and might not be super hard.