As much as I would absolutely like Stack Exchange to be more customizable, this is not in the MVP. Let’s first build something that works.
Once we have something that works and that’s been field-tested a bit, let’s freeze the HTML/CSS/JS APIs and let people write extensions. Then let’s work on a mechanism so that extensions can be built into the site. And when people have started to write extensions and run into limitations of the existing HTML/CSS/JS APIs, we’ll design versions 1.x and 2.0 of these APIs.
I think implementing extensions is way out of MVP. This is taking about minimal customization aspects that shape the community’s personality.
That kind of stuff is important for communities, see how many people complained, when SE standardized the voting buttons. That’s why I think basic stuff like primary colors and header banners should be MVP! Not sure about custom CSS.
I’d oppose allowing sites to customize the codebase. That’ll create a maintenance hell at some point. I think we could allow
enabling some of a set of extra features that are available for all sites (e.g. MathJax)
This is what I meant by “Commits to individual site branches should be reserved to customizations”, with the exception of “custom js” and “enabling extra features such as mathjax”. Or, in other words: Custom CSS only.
Other features can be implemented in core and enabled/disabled as a config
These are the only considerations we must have clear from day one, in my opinion.
And by that I mean, our architecture will support it, not that we’ll be writing different custom CSS for a dozen websites from the beginning. (obviously.)
primary color vs. all colors? Colors in general should be customizable per site - just a little data, no code .
background images? Absolutely! Just a pointer to an image. We set guidelines and sites come up with their own images. DIY had some complaints (myself included) when SE “refreshed” the images and didn’t do a good job (to put it nicely).
custom css? Limited. Colors are part of this, and we could allow some other changes to, for example, let sites have a different look to the buttons. Will need to be documented well as to what a site can change and how they can change it.
custom js? No.That has too much potential for problems. Not “never”, but I would hold off on that for MVP. We can always revisit later, but I think most such features should be implemented system-wide with an option for sites to turn on/off. In other words, if a site needs that special new JS-driven capability, add it to the core and turn it off for the sites that don’t want it.
enabling/disabling features from a common set? Yes
In addition, I would add:
Customize “Tour”, “Help”, “FAQ”, etc. For example, DIY has a lot of images (and also a lot of non-technical users), so clearer instructions on adding images would be very helpful, but other sites may not need that.
Assuming we use some form of voting → reputation → privileges, allow sites to make adjustments, particularly to the reputation → privileges part. (Arguably, the points per Q vote and A vote (which should be different values ) should be the same across all sites, but the points to be able to edit without review or whatever can vary.)
I have use cases for custom JS (but not for MVP). A community should have a path to this, and that path needs to include review/acceptance by the folks running the server. I’d even argue that submissions of custom JS should be considered for addition to Codidact (so others can benefit too, if they’re accepted).
One use case is custom keyboards for sites that operate with languages that don’t use the Roman alphabet. Another is custom markdown extensions to support citations, media embedding, and the like.
Custom JS is not MVP. But it should be possible. I definitely think that since it is code and not style, it should become part of the master project - i.e., just like any other code changes. CSS, on the other hand, can much more easily (both technically and conceptually) be drop-in text that gets replaced, just like titles and privilege descriptions and any other text.
Other features can be implemented in core and enabled/disabled as a config
I had MathJax in mind, specifically, when writing that, but it really applies to all custom JS we can foresee as of now.
If one site needs a specific JS lib for a given keyboard layout, for example, this lib can very well be added to the core product and disabled/enable for specific sites via the admin dashboard. (Early on I suggested separate branches for individual sites, but as the site count grows it becomes hard to maintain.) A config should work well in the sense that you can enable it only if you need it, and if kept disabled you don’t pay for it - neither do your users - but it’s there for everyone’s benefit.
What I oppose is to allow specific sites to upload their own custom JS with the same ease that modifying CSS is supposed to present.
Custom CSS, on the other hand, is… well, pretty custom indeed, and there’s little point in facilitating its reuse, IMO. There are also pretty much no security concerns and little risk of breaking things.
Edit: If the need for actual custom JS arises at some point, I suppose the community can implement it in the same fashion as custom CSS (but with more care), or in some better way - first into a fork of the core repository, and if the implementation makes enough sense it could then be included in core.
I would prefer that custom JS be added to the core code and be available to everyone.
Here’s the scenario I fear:
Site: “We need this Hebrew keyboard. Here it is.”
Codidact admins: “Great idea, but we shouldn’t add individual-language keyboards to the code base; we should generalize this so that site that wants Russian can use it too.”
Site: “Ok, how long will that take?”
Codidact admins: “We’re pretty busy right now. We’ll add it to our backlog, unless you want to do the work for us?”
Site: “Um, we don’t know anything about Russian. We just want this keyboard we already wrote. Do we have to do it as a userscript instead? That won’t be as friendly.”
If we’re willing to accept anything (that passes basic code review), then fine. Things might get a little chaotic if there are a lot of these, but there probably won’t be many so it’s probably fine. If we’re going to apply stricter gatekeeping, we have to have a reasonalbe response for the case where the initial answer is “no”.
We do need fairly strict gatekeeping. But the key is that it will be the same we that:
Incorporates changes into the master repository
That won’t always be the case in that a separate instance of Codidact would be required/recommended (depending on the license) to send us the changes and then we wouldn’t have to include them in the regular distribution. But in the primary instance we are one group. A group with limited time & energy, but one group and not two very separate entities of “community” vs. “host company”.
So this will work fine.
Part of the job of the code gatekeepers (aka Tech Lead/team) will be to work things out so that the Hebrew changes can be expanded to Russian and other languages at a later time. But that should not stop implementation of Hebrew. etc.
A quite undesirable scenario; I understand your concern.
And can we change our mind about this later? As (almost) always, the answer is yes.
Exactly. And you know, I really understand Monica’s concern because, unfortunately, I’ve seen that happen. It’s not unheard of at all.
However we have to consider the software and the site separately. I could well imagine to implement a given Hebrew keyboard on the site as temporary solution, without integrating it into the software until a more general solution is found.
Indeed, I notice that too little separation between the software and the site is done here (I’m probably guilty of that myself, too).
Exactly. The bar for “run this on our site” should still exist (because it’s our server) but should be much lower than the bar for “add this to Codidact”. The latter should be a goal but we should not block the former on it.
I added #1 and custom CSS from #2 to the requirements. I said nothing about custom JS, so by default it’s not in but not barred.
#3 is kind of broad; we agree in principle but the requirements will probably need to be more specific. 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?)