We’re designing a mighty fat system right now. Yet we’re calling it MVP. Building MVPs regularly at work my observation is that our M currently stands for mighty not minimum.
It’s mostly an endless list of wishes and feature request that were ignored on SE.
We’re currently talking about features that SE didn’t implement until years after launch and call them MVP relevant. I’m a moderator on a small site and there are discussions and assumptions about features necessary for launch which I haven’t even touched on SE more than a handful of times — if ever. We don’t need those now — maybe never.
Every feature we have in our Mighty Viable Product moves the launch date back.
Minimum viable products by nature try to do three things
- be a product
- be viable
- and above all else being out there as fast as possible by being minimal.
In my observation we’re bad-ish at 1) and honestly horrible at 3).
Why bad-ish at being a product?
- We don’t know if we want to
- launch a Q&A community with our own SW which happens to be open source or
- build an open source Q&A SW which we also happen to host once ourselves.
- Those are two hugely different things from a product perspective but that should be discussed in another thread.
Why horrible on being minimum?
We are apparently (subconsciously) planning for the full scope of SE on day one, even though we have hard data that we don’t need that.
Example Flagging: Over the project we have literally dozens of SE moderators who have access to all sorts of data about number of flags on sites of various sizes telling us how many flags we can expect in the beginning.
We can verify over several communities, but it will be around 1-2 a day. Max.
We don’t need a bunch of flag types users with a certain trust level validating flags and whatnot.
We very wisely said DCMA & GDPR requests are handled manually in the beginning.
Let’s do the same for flags.
Let’s design the MVP for that.
- Users can flag posts and comments.
- Moderators have a list of active flags and a way to mark them cleared.
That’s it. That’s the flagging MVP.
That way we just shaved a week of our launch roadmap.
If we do that for the rest we’ll be live for Easter — if not, Christmas.
Disclaimer regarding the example: The summary is “fine” it’s the way we handle all MVP features here. I had to pick one. I’m questioning our current modus operandi not this specific summary.
Editing / Flagging / Closing Example
that are not locked (locks are not MVP)can be edited.
Authors can edit freely. Users with the appropriate trust level can edit freely.
Users below that trust level can suggest edits.
All edits use the same affordance (“edit” link or whatever) and interface,
except that users who cannot edit directly are told the edit will be reviewed before starting and get a notification of pending review on submission.
The author of a post receives a notification of a
pending or directedit.
If there is a pending edit on a post, the post shows an indication of this fact. Users with the trust level to edit can review pending edits. The author can also review a pending edit. Reviewers can accept or reject.
Not doing “…and edit” / “…and improve” – if you want to edit after an edit, then add another edit.
How many approvals are needed, from reviewers other than the author? Don’t say two just because SE does; what’s the right number?
Intentionally omitted: edit review queue. We don’t have review requirements for MVP (yet, at least). We’ll need some way to surface pending edits, but it doesn’t have to be a review queue. Maybe there’s just a list of links to posts with pending edits available?
Users can flag posts and comments.
There is a default list of flag reasons plus “other” (free text). List TBD.
There’s a a flagging mechanism. There are no types of flags.
For questions, “should be closed” is an available flag reason. Close flags are like close votes except for not being votes.
Users with the ability to handle flags see an indication of a flag alongside the content. Acting in accordance with the flag (deleting the target, voting to close, etc) validates the flag.
Moderators have access to a list of all pending flags.
Closing and reopening questions
Questions can be closed if there is some problem that prevents answering them. ( Need to find the forum post that proposes short list of close reasons. )
Closed questions can be reopened.
In both cases, a voting affordance on the question is available to users with the appropriate trust level.
TBD: Number of votes needed to take action.
TBD: messaging to author of the question.
The author receives a notification if a question is closed or reopened.