Before offering a list I want to highlight two things.
Firstly, with this list I do not want to say any of these features are bad. I’m just saying from an MVP design standpoint they probably don’t need to be there at launch.
Secondly, don’t take estimations about how each of these features individually take too seriously. In product management speak our development velocity is completely unknown. The only thing we do know is that for each feature we do work on we don’t work on something else.1
Lastly before the examples. This is not about any of those features individually. This is a challenge to what we consider our MVP and how we want to go on with deciding what’s in it and what’s not.
I would list the following under non-MVP which are currently listed as MVP-consensus.
- Tag descriptions (including all the trust level issues and editor necessary for that)
- Almost everything regarding user profiles which is implicitly defined in other discussions
- Trust level based rate limiting
- Flagging complexity
- Close reason complexity (Leave it at one, have meta figure out the rest)
- “New contributor” label (By definition everyone is a new contributor on launch)
- Threading of comments (which is easy in DB, but a hassle in UI)
- Sockpuppet investigation by Admins (They are admins, use the DB)
- Any site categories beyond Main & Meta
- Most of the tbd sections of the functional spec, e.g. “for each post, access to the feedback feature (to be further specified separately)”
One last thing to consider. Any MVP is designed under the assumption that development continues through launch day. Descoping something in MVP does not kill a feature.
1 At least for all intents and purposes we cannot assume in designing an MVP that we have an architecture that allows infinite parallel development on core features while still “staffing” the parallel streams with enough developers.