I’d say that a good admission criteria for a category is to have one or more people responsible for maintaining the “pinned post” at the top of the category and assuming moderator control of it. This basically entails keeping an eye on the scope of the discussions and keeping the post updated for newcomers.
I’d be happy to moderate a Core-and-friends (Base, Core, Core_kernel, Async) category, if that’s a sensible scope.
I’ve created a Core/Async category – go ahead and create a pinned post in there.
Does it makes sense to have a category or sub-category for ICFP? Since it’s just a few months away. I want to follow the discussions if such things are happening currently.
I created a post, but don’t know how (or if) I can pin it.
I’m not sure if it’s easy to re-categorize posts a-posteriori, but if so I would naturally go @dbuenzli’s route, creating categories as we see that becomes useful. Note that the Rust Discourse has very few actual categories (help
, announcements
, uncategorized
, community
, tutorials
, meta
), maybe the Discourse interface does not make it as useful as for a traditional forum.
Among their categories, help
corresponds with beginners
(both names are fine), and I think announcements
is a reasonable idea as well (that is a regular source of content for the caml-list, although one can also wait to see if people want to cross-post them here as well), and meta
may be relevant anywhere.
I don’t expect ICFP to generate enough discussions to warrant a category, but feel free to open a topic to discuss it (and co-located events)!
Should OPAM related threads be categorized as Build
for the time being?
FWIW, I’m also in favor of broader categories to start with and then subdividing/recategorizing as certain topics become more popular.
Instead of a new specific category, I’d just suggest the creation of a generic one (“OCaml - general discussion” or such) and only split it when actually needed. At the present time many (most?) topics would not fit in “build”, “beginner” or “core/async”, yet “uncategorized” does not sound that good (your eyes tend to skip it since it looks like standard off-the-box Discourse stuff, which it is).
May be we should promote tags for now with a few top level categories.
I’ve now activated the “tags” feature on the site, so you should be able to set your own tags on posts. Regarding @mfp’s suggestion, I think (but may be wrong) that we do not need a "genera"l category, since uncategorised posts are supported. So we can just create topics as uncategorised, and then categorise them when appropriate.
One area this may fall over is for beginners, since we don’t want to scare away newcomers with floods of unrelated advanced-looking topics. It would be good to pin a “Beginners” post with encouragement, and make that something we show prominently on the main page as a permanently pinned item.
Rather than having a Beginners’ category, I wonder if it would be better to have the welcome post encourage you just to post a question rather than worrying about where to post it? In a small community, just aiming to keep the bar to joining in as low as possible? For common questions, that would include linking to the oldest relevant answer and hopefully increasing the popularity of the answer (and limiting the risk of the duplicate question?)
That’s fine by me too – I imagine that we could allow moderators to categorise new posts into Beginner to save newcomer the trouble. It’s very little overhead.
I do think having a Beginners category is useful though, since it forms a safer space where it’s explicitly ok to chat about basics, and also ignore the traffic in the rest of the forum. I’m not yet sure how good Discourse will be at letting us all filter different categories into different email folders/etc.
As a beginner, I don’t have strong feelings about this question, but I’m not against having a special category for beginners’ questions. The only complication is knowing when you have enough experience to ask a question outside of the beginners’ category, but that can’t be helped.
Can people subscribe to receive posts as email? If so, do categories make it easier to choose which emails to receive? Would many experienced users who receive posts by email want to avoid seeing beginners’ questions in their inboxes? If a moderator has to move a beginner’s question into the beginners’ category, would that occur after the question had gone out to mailing list subscribers?
-Marshall
In Emails Section under Settings, you can enable Mailing list mode to recieve all topics but you can mute specific categories that you are not interested.
Do we want to make it that default or have people explicitly optin for specific? If we want people to explicitly optin to mailing list mode, probably it would be good idea to write a small guide with screenshots and pin it as global topic.
I think the issue with this one is that “infrastructure” is too vague. Though I followed the discussion when this list was created, I can’t remember right now what it should or should not be used for.
I think that’s a good idea. Right now the default is to miss discussions when you’re not logged in to the web interface, which I imagine will be the case most of the time for most people.
Then it seems there would be a benefit to encouraging beginners to ask their questions in a Beginners’ category, since that way only those email subscribers who’d opted in to getting beginnners’ emails would receive those questions. Some beginners would post in other categories at first, but here could still be a policy of not attacking beginners who mistakenly post elsewhere.
Yes, but you can always check in later. That’s the advantage of a system like this one.
Is it okay to create a category about ReasonML/BuckleScript? They are mostly the same group of people who are interested in web development
I think the issue with this one is that “infrastructure” is too vague. Though I followed the discussion when this list was created, I can’t remember right now what it should or should not be used for.
True. I’ll table this one until the rest of the forum settles down; we can figure out how the various *.ocaml.org pieces make sense to integrate at a later stage.