What groups to create?

Site Feedback
#1

One of a few posts to start discussing the “go-live” configuration. Obviously we can roll forward as our uses change.

Groups got some attention during our testing, and right so. They have a lot of flexibility - they can be public or hidden, open, request-to-join, or invite-only, can have an incoming email address associated with them, and can be used to @-notify from forum posts and private messages. They also allow for flair & badges so that people can see you’re in a group.

The aim is to create themed groups that people can self-select to join because they care about bugs/discussions/etc on that topic. So, what groups to create? We have 63 teams on GitHub, so mirroring that might be a bit much, but it’s a starting point. How about:

  • Core
  • UI/UX
  • Proxy
  • Installer
  • CLI / Hammer
  • API
  • Forklift
  • Infra
  • One per plugin that has more than one member on GH

I’ll also add a “developers” group that can’t be @-notified (too many people, too spammy, I think), so that developers can be easily identified. Did I miss any?

1 Like
#2

For those who are observant, you’ll see a Foreman hat on my avatar. That’s a flair for anyone in the “developers” group, which is request-to-join. Hit me up if you should be in it, I haven’t really added anyone yet :wink:

The idea here is that it makes posts from developers very easy to identify for those new to the community, and also helps them learn who’s who.

#3

I’ll get to creating these groups during the next few days. Most groups will be:

  • Visible to all
  • Open to join (no need to request access)
  • Can be @-mentioned
  • Cannot be private messaged

There’s a couple of exceptions:

  • Developers - not free to join, must request
    • This is because the group confers a status that most in the community would use to indicate senior status, and that would be easy to abuse if it was free to join
  • Infra - not free to join, must request
    • This group is likely to handle sensitive stuff regarding accounts, systems access etc, and that should be safeguarded
    • I’ll enable messaging and an inbound email address for this group, so we can test if it makes sense for automated systems to send notifications to the group

We mooted the idea of a security group too, but I think we might want to revist that once we’re fully migrated, the existing secuity process is working for now.

#4

Been out most of the week due to illness, but finally got around to this just now. I didn’t quite create a group for every 2+ team on GitHub (it was getting silly) but I have created groups for all those with multiple active contributors (I think, get in touch if I missed one).

I’ve added an owner to each, I’ve tried to pick people on the contributor list but also who played with Discourse a bit. Existing owners can of course add new owners as required.

I’ve not added any other users to the groups (not much time sadly) so please do add yourselves to the groups you feel you should be part of (or owners can do it for their groups).

Groups do confer titles to display in the rest of the UI, but AFAICT only admins can select which title shows if you’re in more than one group. Message me (or another admin) if you want your title changed. I may raise this upstream, seems valid…

Enjoy!