## Proposed Ansible Community Forum layout

A forum needs careful thought in how the categories and other functions are laid out and used. We'll first consider some different personas, and how they might use the forum, and then propose a structure to match

GOAL: The purpose here is to give ourselves "enough" to work with - not to set every last detail in stone. Discourse is hugely flexible, and we *will* find more tools/extenstions/plugins that help us. BUT we'd like to get this "good enough" to launch with so that we don't tweak it too much in the first few months - if we confuse people with the new tool, they'll avoid it.

Guidelines: A forum is like a house, and its categories are its walls. One wall won't hold the roof up, and 30 walls is a maze…

(If you need it, the wider community strategy can be found at [Ansible Community Strategy 6-pager](https://docs.google.com/document/u/0/d/1VEiuP7-uc5qDiDsKKdwzQ7MwXTb_cOcqFCHv8VgVjk4/edit))

## Recordings / Demonstrations

[Events Plugin usage in Discourse](https://drive.google.com/open?id=17HKpEw0Tpt4eaKnQBkjZ8uq9FPOWGPOW)

## Personas

### A user with a question

This person wants to get help with something - they might be used to StackOverflow, or using more social things like Reddit or Matrix.

They don't want to spend a lot of time figuring out *where* to post a question, nor do they want to be passed from place-to-place being told to ask someone else. They may be prepared to search for similar questions first, so marking solutions helps them.

We may want to consider written language-specific sub-categories here ([Example](https://discussion.fedoraproject.org/c/ask/non-english/85)). We can initially have a "Help in other languages" subcategory and expand as needed.

### Users answering questions

Someone who wants to give back a little - likely a user with some time to spare after asking their own questions, but also could be contributors to collections or developers too.

They want to know which questions are still "active" or unsolved, so they don't spend their time on *finding* things to answer, but actually on answering them. Complex searches by tag and unsolved are helpful here.

### Contributors of all kinds (working group members)

This could be collection maintainers, project developers, architects, decision makers, etc - the people building new stuff and/or fixing bugs. Today, these people largely join working groups to get things done.

They'll want a space to discuss the work they're doing and figure out how to progress it. That may be architectural discussions (which could be cross-project) or discussions on how to solve blockers to an agreed feature.

Keeping this strongly themed seems important, as topic titles & bodies are likely to lack context outside the project (e.g. a topic of "UX roadmap discussion" would mean something very different in AWX vs the new community website WG).

### Community Advocates

Anyone working on outreach or organisation - conferences, meetups, finding speakers, blogging rings, etc.

Today Ansible does not have a good way for maintainers of such things to advertise their work to the community, nor to support each other. A public community-maintained calendar of upcoming events, talks, CFPs, and meetings will show the rest of the community how active this space actually is.

A private space for organisers may also be useful, as this work can often feel quite isolating. Enabling them to support each other seems a useful thing to do - but as a private space, we'll have to work out under what conditions an organiser might lose access to it.

### The Red Hat Ansible Community Team

As the overall architects of the community, we also have needs - things like signup, CoC acceptance, data analytics, etc are handled by default anyway. We will need an announcements category (linked to the community blog)

## Structure

We'll do this per-category, with general defaults at the end.

### "Announcements"

Fairly straightforward - limited write access, and linked to the new website so that Discourse powers the comments on the blog.

We could consider sub-categories later for things like the YouTube channel, or cross postings from the product blog.

### "Get Help"

The main support channel. Applicable to all projects in the community, we'll use tags to categorise them - this means users have only one place to go and ask for help.

We'll want the "solved" plugin so that questions can be marked as complete, and we may want to allow high-level community members to close questions too (often users will forget)

### "Project Discussions"

The main development area for projects, holding discussion topics. At this time I'm leaning towards tags for this as well - for comparison, consider [Fedora Project Discussion](https://discussion.fedoraproject.org/c/project/7) using tags like mindshare, etc. This buys us flexibility as project wax & wane in traffic, and avoids having to explicitly create 30+ sub-categories for the existing projects.

Thanks to the "tag-sidebar" theme component we can still have a "landing page" for a given project/tag (see https://discussion.fedoraproject.org/tag/mindshare as an example)

Tags have extensive controls around who can create new ones (based on group/trust level) as well as defining tag-groups and tag-synonyms (to collapse typos / common words) which gives us a lot of power here.

### "Ideas"

A good usecase for a community-wide forum is to discuss potential proposals, and scope them out before a more formal PR-based workflow begins (A PR is better for collaboration on the wording of a document, while the forum is better for visibility and gathering input). This category would be for discussion of these early-stage ideas (c.f. https://discuss.python.org/c/ideas/). Tags can be used to address which parts of the project a proposal touches or is relevant to.

#### (Option) Sub category: "Proposals"

Once an idea has reached a mass of support, then it will enter a more formal workflow in GitHub. We could use GitHub integration to try and increase visibility of those discussions with a sub-category and webhooks to auto-create topics that match the PRs, with limits on how/when replies can be created & by who. The [Python PEP Proposals](https://discuss.python.org/c/peps/19) category is similar.

### "Events"

This will be the public part of the evangelist section. Making use of the Events & Locations plugins, we'll be able to run a public calendar ([example](https://community.theforeman.org/c/events/13/l/calendar)) which can be editable by those with sufficient trust. We can also automate including all known meetups from Meetup.com, and use the Discourse API to display some of these on the new website. Trip reports and event writeups will obviously be welcome here too.

We can also consider sub-calendars for Working Group meetings, and for CFPs of interesting conferences.

#### Sub category: "Event Organisers"

A private space for people creating/hosting events to share support, possible speaker info, etc. We'll want to be sure about the criteria for access *and* for being removed (i.e when an event is no longer active), but otherwise this is a straightforward category.

### (Option) sub category: "Speakers Bureau"

Some care needed here, but a place for speakers to offer talks, or be requested by organisers might make sense. Needs a great deal of care to avoid job-huting, self-promotion, etc, but could be good.

### Site Feedback & Requests

A place for any user to request changes. A general catchall for things that need to be implemented on Discourse itself (new tags, groups, categories, plugins, etc) or bugs that need to be fixed.

### Archive

We'll need a place for the mailing list archives to live - this is it. There will be one sub-category per imported mailing list, read-only for everyone. Helps to give us the search over older topics (and protects us from Google Groups going away).

#### Sub category: Meeting logs

We currently host meeting notes on fedoraproject via zodbot, as well as copying them to GitHub. Bringing them here (and using the Discourse API to post new ones) is an obvious move.

This could perhaps be under "Project Discussion", open to debate.

### General functionality

* Signup has to be easy:
* We have no SSO of our own (unlike Fedora Accounts etc)
* Login methods: Email, GitHub. Google would be nice-to-have
* The mailing list import will autocreate a *lot* of staged users that people can claim for themselves
* This is actually fairly clever, and works as follows
* A staged user will never have mail sent to them unless it's in Private Message (companies use Discourse to interact with contractors, job applicants, etc this way)
* A user may "claim" the staged email address by simply registering it as normal (since they'll have to receive a mail to confirm the account, they *must* own the address)
* At this point the staged account is upgraded to a real account, and the user gains ownership of all their posts to the old mailing list(s) from that address
* Users who have had multiple address *can* have them merged by an admin, but we'll want to have a process for that. It's not an urgent thing.
* Plugins we'll want:
* discourse-checklist (Add checklist support to Discourse)
* discourse-data-explorer (Interface for running SQL queries on the live database)
* discourse-calendar (Allows you to manage events in Discourse)
* discourse-solved (Add a solved button to answers on Discourse)
* discourse-github (Integrations with GitHub)
* discourse-gamification (to score activity - we'll want to restrict leaderboards)
* We'll want to make good use of trust levels, and where appropriate, trust level 2 or 3 should be given access to extra things.
* Groups are critical - we'll want one for each project, at least. They have multiple ways to be configured, so we can tweak their working to the needs of each project
* Tags are likewise important - making use of [tag-sidebars](https://meta.discourse.org/t/discourse-tag-sidebars/111114) is a good idea
* Admins will be the Community Team, for now
* Need rules for creating mods - leads from each project are a minimum, I think
* Agenda / wiki posts for groups to use to track work / meetings / agendas
* Integrations with other platforms are possible, for example we have tested posting Discourse notifications to Matrix rooms (see screenshot) and we can do GitHub too.
* 

* Other things are likely possible on request (let me know your usecase)
* Discourse 3.x supports a live-chat system, but we'll disable that so as not to compete with Matrix (although they [may one day be compatible](https://meta.discourse.org/t/matrix-protocol-for-chat/210780/)!)

## Inspiration Sources

Some existing community forums for ideas:

* https://discussion.fedoraproject.org/
* https://discourse.pulpproject.org/
* https://community.theforeman.org/
* [https://community.letsencrypt.org/](https://community.letsencrypt.org/categories)
* https://discuss.python.org/
* https://discuss.kubernetes.io/
* https://discourse.ubuntu.com/
* (feel free to add more)