Individual communities on a Codidact instance should be able to customize certain aspects of site behavior, which can have implications for the software (such as configuration hooks that must be available). I’d like to assemble a list of what kinds of things we think communities should be able to customize, so we can account for them in design of the software and database schema. Here’s my start at such a list.
Most of these capabilities are not MVP. I’m bringing it up now, and tagging this post “mvp”, so we build in the flexibility we’ll need later. Enablement is MVP but these features are not.
Communities should be able to customize:
privilege thresholds
standard flag reasons
help, to add topics
help, to modify topics
certain? most? all but those with legal implications?
is this a fork, so they never get updates if the core instance topics are updated?
content of any just-in-time guidance (e.g. help that’s offered during question composition)
Communities should be able to import (license-compliant) content from SE if they choose: all of it, everything a particular user touched (user-triggered import), everything matching a query (e.g. only upvoted, only these tags, etc), nothing (fresh start).
Communities should be able to add custom static notifications to the site. See the “professional services” disclaimers on some SE sites (Law, Medical Science, MI Yodeya, maybe others).
Should we allow communities to modify the scoring algorithm for posts? Only in certain ways? (We might not be able to answer this until we work out what our scoring algorithm is.)
I’m sure I’ve missed lots of stuff, and people might disagree with some of what I included. This is meant to be a starting point. What’d I miss? What’s wrong? What needs to be tweaked?
This post is strongly related to that other one I wrote:
However the difference between these posts is, that this one is about behaviour and the other one is about design. (This is just a clarification, why I think that these posts are not duplicates)
I was thinking “didn’t we already discuss this?” And we did. As far as I am concerned, while there are some policy questions here 'n there, by and large the customizations in this post and the other one are much the same: A set of “things” that should be configurable both per instance and per community. And basically “everything” should be sitting in a database so that there is nothing to change in code - about the only thing that should be in a separate data file is the credentials for the database. Everything else - whether for an entire instance or for a community within that instance - comes from the database. That includes privileges/reputation/votes/etc., text (system title, domain name, help pages, etc.) and features (turn on/off MathJax or special keyboards or whatever).
As far as MVP: Everything should be database-driven in MVP. However, I don’t think we need full Admin Pages for these things in MVP - they can initially be handled through a simple interface by System Admins (i.e., instance rather than community) as the changes to these items will be generally rare after the initial setup of each community.
The reason I separated this out is that, for example, custom CSS is just “add this file”, while customization of privilege thresholds requires those values to be in a table (we knew that) and customization of flag reasons requires realizing that they even need to be customizable (we might not have known that). I’m trying to go beyond “yes customization” to a little more detail, to help us understand all the places that customization issues can lurk.
Also, while everything’s in the database, it might still be that things are easier or harder to adjust depending on how we represented it. For example, on SE comment flags are a special kind of comment vote – so if a site said “we don’t want voting on comments”, it would lose flags, which is undesirable. We’ll never anticipate all issues, of course, but maybe we can avert some non-obvious problems at the design stage.
(And agreed on not needing full admin pages for MVP. An admin typing SQL meets the need.)
Replying to both pages here - I couldn’t reply on the other page as it appears to be closed/locked (except I guess for Admins).
Do we have consensus that customizing help is MVP? All of it? Only certain parts? (How much help is MVP? Clearly we need something, but how extensive?
Any help that is MVP (or later) is to be stored as text in the database and should have “site master copy” vs. “community specific” tag. If a community doesn’t have a particular specific help then it just defaults to master. Real simple. How much/how many pages/etc.? No idea. We make a table and tag the stuff appropriately as we need it for FAQ, Question Help, Answer Help, Comment Help, Close/Reopen Info, whatever. And then the code just references it with a simple SELECT to get what it needs. That also makes it real easy to provide language localization - just throw another field language (default = EN-US) and if/when we want to add more languages we just copy records and edit them.
So we do it differently. Either make flags != votes. Or make flags & votes all part of one “thing” but give separate options (e.g., upvotes yes (with rep. value if we want that), no; downvotes yes (with rep…)/no, flags yes/no - plus the types of flags available will be configurable too (we may think we know what they will be but I am sure they will change and therefore could vary by community); etc.
For this, we can do as SE does - have an enum of PostTypes: 1 is Question, 2 is Answer, maybe we have 3 as Comment if we’re keeping those in the same table - but we can also have 4 as WikiPost and 5 as HelpArticle, etc etc.
The help articles themselves can be posts; we copy them over from the default when a new community is created, and then the community is free to edit them as it sees fit.
My point in bringing up comment votes/flags is that there was an unintended linking of the two that would have bitten us if we’d done it that way. We won’t because we know. What else might bite us because we didn’t think about it? I don’t want to fall into an analysis-paralysis trap (I want to get moving); I just thought it’d be worth us identifying some needs that seem to me like they affect design.
The approach you describe for storing help makes sense, and that’s a good point about also solving localization.
When I get to an initial detailed database design, it will likely include what will seem to some people as more “extras” then needed. But I have learned over many years that storage is cheap but schema & design changes are not. The more we plan ahead, the better. If some of the fields end up not getting used for a long time or ever, it really costs us little to do this (as long as they aren’t index fields on big tables, but most of this is about small fields and/or small tables) and allows for a lot more flexibility if/when we need it.