What level of customization should we support by default? (without sites changing the source code)
Some parts of it are certainly #mvp, while others are not.
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.
The ones I highlighted. (the first two are implemented in terms of custom CSS, no?)
Btw: (me, 2019-10-19)
I’d oppose allowing sites to customize the codebase. That’ll create a maintenance hell at some point. I think we could allow
- custom css
- custom js
- 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.)
IMHO:
In addition, I would add:
) should be the same across all sites, but the points to be able to edit without review or whatever can vary.)I think we have consensus for the following:
If no one objects within 48 hours, I’ll write this into the spec-wiki and close this post.
My only objection: the consensus appears to be no custom JS 
@manassehkatz’s post says (in the context of custom js):
However I’ll edit my consensus-post too:
Allowing custom css/js is not MVP, but can be revisited later
Hmm, custom CSS is considered MVP. On the other hand, custom JS is something I strongly object to (and have yet to see someone disagree). I just see no reason for it…
(edit) but sure - as everything else, this needn’t be set in stone and can be reconsidered at any moment later.
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.
Allow me to clarify…
@manassehkatz nails it: “it should become part of the master project (…)”.
As I wrote in 2019-10-19 (mentioned in #4):
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:
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.
My considerations: To maintain long-term quality in the core software, basic code review is not enough: the implementation must fit well within the existing framework, at the risk of ending up with a chaotic codebase. At the same time, I really don’t like the idea of making it very easy to add custom JS for any given site, considering it can end up being even more chaotic to them, leading to conflicts and security concerns of various sorts without proper care. The alternative is, then, to make it a little more difficult, by requiring anyone who really wishes to serve custom javascript to go the extra mile and fork the repo - thus explicitly marking this an unsupported setup.
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).
I would consider Javascript/keyboard/etc. to be part of the software. It may be that certain pieces (like a Hebrew keyboard) only apply to particular sites within a given instance of the software. But the code should still be part of the master software repository which will be used to run that primary instance and all of the sites within that instance - with a configuration parameter to determine whether a particular code-based feature is on or off for each site.
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.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.
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?)