I see it as serving two major user types, with further distinction within them.
Customers: They come to us with questions about Bitcoin, bank transfers, etc. Their often not looking for a community of peers to discuss something of interest to them, they’re just looking for help. Our business is heavily regulated, which sometimes results in angry or confused customers.
Developers: We have a bunch of APIs, and we help devs use them on our forum. This is the fun part, and the group that presents and opportunity to build community within. The developers category has a lot of sub category, and I hope that it feels like a separate forum to those visitors.
Beyond that I won’t talk too much about the specific challenges I’m trying to solve, but I’d love to hear from others with a similar use case, and hopefully we can help one another out.
Our (very different) company uses it for user-to-user support. When customers have a question that only we can answer we usually push them to contact us via traditional support methods. In your case I’d focus your forums around developers and maybe have a “General bitcoin discussion” board or something where less technical discussions can be had. Because of the sensitive nature of financial transactions, you don’t want to risk a stupid confused customer accidentally posting their banking information on your board.
The discourse I help moderate (discourse.stonehearth.net) is heavily support oriented, but I am not sure if I would describe it as primarily support oriented.
The forum is for a game in active development, so a large bulk of discussion on the forum is in regards to bug reporting, but there is also discussion regarding the game’s development (as a whole), modding, suggestions, and other discussion.
It certainly happens, but we do our best to make sure it doesn’t. Personally, I track all topics created and watch the support related categories. There are 4 active moderators, and we do the primary triage and “level 1” support for users. For us, most of the posts in our support category are bug reports, and thus an immediate fix/solution doesn’t happen. When we do have a more “traditional” support request, like a crashing game, we usually treat it as first come, first serve. Whichever mod posts first handles the case, and can ping others as needed. Further, we support 8 developers, and as such bring them in where needed/distribute the bug reports.
No. With a few exceptions we do not close/lock old posts. We actually prefer that posts are “necro-ed” as it allows the developers to see that an issue still exists/has returned.
It certainly happens. We do have a number of pinned topics in different categories with common solutions, but we get a fair number of them.
This is one of the situation where we do close threads. If something is reported that is a duplicate, we close the thread, split all posts into the “original” topic, and then move the duplicate to a separate “other reports” category.
This is where I think we differ a bit, in that many of our customers are consumers, so we tend to get things like “Do you accept paypal?” repeatedly. I think it might make sense to start closing those, and linking to the one canonical response.
Definitely different there, but the forum did previously handle more questions like that back when the game was doing a Kickstarter and was sold only through Humble Bundle (now it is on Steam).
We just started using the tag plugin, but in a slightly different way. Being a game, most of the bug reports deal with different aspects of the game (ie. Building, AI, terrain, crafting, etc.). We now tag all support topics with tags related to the bug type, as well as tagging based on the game version and bug report status. Let me give an example:
Bug report comes in related to water in the latest stable release, no tags are applied.
Moderator see post, acknowledges it via a post, and adds tags. In this case we might apply terrain and a12r472 (alpha 12, release 472).
Another user posts a few days later with the exact same issue.
Moderator adds confirmed_by_users tag, that way developers can easily see that it is not a one off issue.
Developer posts in thread acknowledging bug, potentially requesting more details, or announcing a fix. acknowledged_by_devs tag added to let users know that it has been seen.
Bug is patched in a future release. All exisiting tags are removed, resolved tag is added, topic moved from bug report category to resolved reports category. It is NOT closed, that way if the error returns (or was not fully fixed), a user can post there and we return the thread to bug reports and re-apply tags.
As the moderators, we maintain a large list of the tags we use, and have a number of other tags used in specific situations. For example, we have a not_reproducible tag that we can apply to a report when there is not enough information provided by the user and they do not respond to requests for more details, or when the developers cannot reproduce the error despite having enough information. We use not_a_bug when a user reports something that is not in fact an error. We tend to get these when features are changed in a way that is not clear to users. We use no_longer_applicable for reports related to old features, systems, or code that no longer exist, and therefore are not technically “resolved,” but are not an issue either. Finally, we have a few tags used to detail certain report details that are especially helpful, like crash.dmp_provided, log_provided, and save_game_provided.
Overall, the tagging system helps all 3 groups of discourse users. 1, the “users” can see the status of their report quickly as it moves along, 2, the moderators can see when a new report is submitted (no tags) and keep an eye out for duplicates (if all tags match is a good clue), and 3, the developers can see if a certain build or feature is having more issues than others, and when bugs are seen by multiple people versus just one.
http://community.nethserver.org is product based and primarily support oriented but not just this, it’s really similar to meta
New features, bugs, community discussions, feedback, testing, translations, etc…