I was suggesting some of this in r0hkx discord and twitch chat, but it can’t hurt to consolidate it on the forum itself.
set up the calendar plugin for community events
start the wiki
I would like to document some mod rules on there, there is a missing place in the community for long form writing that doesn’t really fit in a thread but has no other place in besides a doc which is not discoverable.
make some custom user fields
pronouns
media (youtube, twitch)
social (discord, twitter, bluesky)
change the name field description to preferred or alternative name or similar instead of full name (which is not really applicable in this community)
adopt a new announcement structure instead of copying over the Javacord one. threads for each of:
PSAs (new glitches, staff changes, general communication with the running public)
this could be done in conjunction with a larger change involving Javacord channels and SRC announcement use, also @r0hkx suggested a blog and connected mailing list would be the actual appropriate way to centralize announcement which I agree with, although implementability of that is questionable.
I would personally prefer to disable badges but it would be best to get everyone’s opinion on that.
certain badges seem unobtainable, such as reply by email and react. if badges are not disabled entirely Ideally the ones that are impossible should either have the behavior they require enabled or be removed if possible.
I will definitely set this up once frontcage has a bit more activity, since it will only be useful if maintained.
Afaik, wikis on discourse are just a type of post that more than the OP can edit. Currently TL3 can create wiki posts and TL1 can edit. There could be a dedicated category for them too? I’m not sure what the best thing to do here would be.
Pretty sure I’ve disabled the full name field, since there wasn’t any option to rename it to something more suitable. I think that means you can’t change your display name without changing your actual username though, so that might not be a good long term solution.
I’ll also look more into fields for other accounts, but I’m not sure there’s and easy and clean way to do that. The pronouns field is added now too.
This is more of a leaderboard staff team question than a forum thing so we should probably have this discussion with those people.
I kinda like them but am mostly indifferent, if anyone else wants to weigh in feel free (on this or anything else too).
Replied there!
I think I found the issue and it should be fixed now for new users, and I’ll manually promote anyone with activity that is TL0. If you’re reading this and want to be promoted to TL1 before it’s really possible to get promoted normally, DM me or reply here.
Interesting, I was imagining something more like GitHub wikis although there’s really no justification for that. If it’s just a type of post then there’s no real point in separating it so long as it’s discoverable enough but maybe something to add to How should tags be used on frontcage?.
I liked the field, I had it as “Justin” and I could mention myself with that as shorthand. The field was just called “Name” so I don’t think that was a problem, I was just trying to say that we should investigate modifying the description of it because it’s still useful as a way to share a preferred name in the UI and it would be nice if we could encourage people to use it in that way.
This might be useful for something like the written analog to ismexion’s submission video guide (https://youtu.be/z2n2fCV1GY0) and my idea for mod usage documentation, but it could be hard to determine what’s a canonical documentation entry for an ‘unofficial forum’ vs just a post that has the qualities of a wiki, so exactly how it is to be used should be determined before it is added. However I do like the idea of the structure that plugin provides for use in on-boarding people to general MCSR concepts and necessary knowledge (community locations, submission guides, intro to the rules, etc).
Another thing is we could do with a custom icon, the default one is pretty drab. Unsure if there is a desire for a unique brand over just the classic end crystal?
a doc entry is usually a separate category of its own, and is pretty hard to mistake for a normal forum thread. Here is an example for discourse’s documentation as an example: Documentation - Discourse Meta
I mostly meant in the sense of the decision of what should be a doc entry vs. what should just be a regular wiki entry anywhere else. I guess that distinction will become clearer with time when we find out how it’s used vs how we predict its used, but I was just trying to say we should start with a developed idea on what that separation is to avoid the issue of having something that doesn’t have a clear place to go.
strategy and tech, not under documentation to avoid making a distinction on what user-authored guides are authoritative. we can however link to guides liberally in the documentation. but still likely to be wiki posts.
I would argue that guides should be merged with Setup, because otherwise setup is likely to be split between guides and help. we can try to direct people looking for setup help to #help via the join messages.
category: mods
a topic for any mod, legal or not. will explain the use and settings of each, as well as some dev info like where each repo is for all branches, and the status of development. I don’t think this should be under documentation because it should be for active use, and would be weird if we talk about an illegal mod in one place, then it becomes legal and we have to move it over.
category: rules discussion
for proposals, explanations, nuanced questions, etc.
help - general questions, useful to keep the rest of the forum cleaner and with high-quality categories. the solutions plugin would be very useful for this. people can also document prior knowledge in the help channel with wiki posts.
Generally I would like places to host a lot of essays for topics that are just not explained anywhere. Documentation can be doc category (above-mentioned plugin) to make discovery better, but the others should just be regular categories because they can host regular topics as well. Ideally if we have a mods category we should also have a help category to try to quarantine those types of posts both to protect the rest of the forum and to make sure the right eyes get on them.
A note on timeline: I have a long break from the 10th to the 14th, I want to spend it doing a lot of documentation work whether on GitHub or preferably here.
I think this is all a good idea, but I don’t want to establish all this structure before there’s anything to occupy it. Everything that you’ve listed can go into existing categories (mostly General), and if it becomes apparent that a new category should be created, it can be created and topics can be moved.
First, thank you for wanting to spend time documenting. For now, I think documentation of this sort can live in General or maybe Setup, and can get moved to another category in the future if/when it makes sense to.
Ah, I completely misunderstood the purpose of Setup. In that case I think a help category is even more justified.
I’ll try to draft enough of a body of work so it can be categorized while transferring over then, that seems better than just tossing a bunch of connected pieces in the mix without any structure.
Maybe I’m missing something but I don’t see any benefit to establishing structure before having content. With discourse, it’s really easy to add or modify structure and recategorize the content after the fact.
I would prefer to let frontcage develop as naturally as possible, fitting the role of whatever the community wants to use it for. For that reason, I’m a bit hesitant to add hard structure or baked in documentation this early on, without knowing much about how the broader community is going to use the platform.