Unfortunately during today's ForumWG call, we did not have enough time to fully discuss @trwnh@mastodon.social's desire to solicit feedback regarding the Fediverse UX for forums.
The next best thing is to collect those user stories via the fediverse and discuss again at the next meeting, so here we are!
@trwnh@mastodon.social will start off the discussion with a reply here.
OK, so here’s what I’ve got so far, I’d really appreciate if others could add onto this with their expectations. This is basically the skeleton for what used to be FEP-9988 (which I’ve put on hold, since it doesn’t quite make sense as a FEP in its current state – maybe later, though!).
forum
: A central hub of discussion bound by an audience
user
: Someone who makes posts
post
: An article of discussion
topic
: A collection of posts grouped by a common title and/or subject
category
: A collection of topics grouped by a common title and/or subject
@julian For some reason the post on SocialHub didn't federate, so here it is: https://socialhub.activitypub.rocks/t/desired-ux-for-forums-and-accompanying-user-stories/4181/2
A common property of topics in forums are pinned and locked states.
A pinned topic is always shown at the top of the collection, and CAN have an expiry.
A pinned topic CAN be ordered relative to other pinned topics.
A locked topic does not accept new replies to its collection. (Reject activity?)
This user story deals with expected behaviour when encountering a topic/context/first-order collection.
Perhaps it is discovered when declared as the context for an Object. The collection can then be used as the canonical source for content for that context, and it's members queued for asynchronous processing.
A scaling issue exists here in that a collection could be massive and cause an undue delay in processing a new Note if every other member of the collection needs to be processed first. Implementors should take care to not require the full context during processing of an Object.
In addition to splitting topics, topics or their posts can also be merged into another topic. The UX for this is quite variable; sometimes entire topics can be merged into another, sometimes a certain range of posts within a topic (post 5 … 10 from 15 posts), and sometimes a selection (post 5 and 10 from 15 posts or just a singular item post 5 from 15 posts).
For #Flarum topics can also not exist in a Category (we call them tags and that extension is optional, like all of our extensions). Even when using a Category, once the Category is deleted, we do not hard delete any topics contained within but unlink them, making them less visible but still existing within the Forum.
Regardless, to us, Topics CAN exist in a category, it’s not required.
This sounds as if this is a given, I don’t think it’s guaranteed in every Forum software. But if can implies optional, then 