As always, I highly recommend against forking Vector. Its internals are dated and highly inconsistent after accumulated years of overengineering, and you will waste considerable time trying to clean that up/figure out what's going on, and even then you will undoubtably wind up with quite a bit of unnecessary code in your final product. Better to start from scratch: fork the Example skin, as recommended, and (re)add in the required features there. The result will be much cleaner, and ultimately easier to both make and maintain, following best practices.

And should you find anything that likely should have been in Example, as it should be available to and included in all skins, please submit updates there as well so others need not duplicate your efforts further.

The ability to differentiate a Wikimedia site (e.g. Wikipedia) from a third-party site running MediaWiki.

Just to confirm, by this you mean the new skin will not be the new default for mw and maybe not distributed with mediawiki, but still remain open source, right? (As opposed to say maintaining independent branding by making a closed source skin, which i would have a problem with)

In T234907#5558301, @Bawolff wrote:

The ability to differentiate a Wikimedia site (e.g. Wikipedia) from a third-party site running MediaWiki.

Just to confirm, by this you mean the new skin will not be the new default for mw and maybe not distributed with mediawiki, but still remain open source, right?

That's correct. The skin will be open source. By this requirement, we mean that we would like to establish a look and feel for the skin that is specific and most useful within Wikimedia projects. That said, if any third party finds it useful for their purposes, we wouldn't prevent them from using it in any way.

In T234907#5558954, @ovasileva wrote:

In T234907#5558301, @Bawolff wrote:

The ability to differentiate a Wikimedia site (e.g. Wikipedia) from a third-party site running MediaWiki.

Just to confirm, by this you mean the new skin will not be the new default for mw and maybe not distributed with mediawiki, but still remain open source, right?

That's correct. The skin will be open source. By this requirement, we mean that we would like to establish a look and feel for the skin that is specific and most useful within Wikimedia projects. That said, if any third party finds it useful for their purposes, we wouldn't prevent them from using it in any way.

Note that this was one of the objectives for Vector (with the intention to leave MediaWiki running MonoBook out of the box), and many third party users complained that their site "didn't look like Wikipedia", so it MediaWiki was changed to default to Vector. The differentiation may be hard to maintain if people are intentionally trying to look like you.

One other reason why Wikimedia-specific skin wouldn’t work is because WMF is still a (de facto) sole maintainer of MediaWiki software. If Wikimedia wikis move to a newer skin, unless there would be specific commitment from WMF to support the parity of MediaWiki skin and Wikimedia skin (what a naming!), the former would naturally become more and more dated and, thus, undesirable for end-users.

Though as someone who already redone Vector to be more Minerva-like for myself (see F30606154), I welcome the idea of newer look. I think forking Vector can inherit all its baggage (like it inherited Monobook’s), maybe a better goal would be to replicate it on a modern foundation and then do changes. Personally, I would like to see a day when our websites would look the same no matter the platform, though.

This new RFC was triaged in the TechCom triage meeting last Wednesday. It was found to have a clear problem statement and as such moved forward to "Under discussion". It also has several proposals already. I updated the structure to be more similar to other RFCs, making the sections easier to recognise for other participants.

I added a proposal 4 based on @Isarra's comment in T234907#5555593 for consideration.

I would strongly encourage you to make iterative improvements to Vector where possible. There is value in writing a new skin, yes, but a lot of what the Desktop Refresh project aims to achieve, especially more consistency between the desktop and mobile experiences, can be done with small iterative changes, so I suggest starting with that first.

As for larger changes, I would understand either writing a new skin or making significant changes to Vector (and I don't have a strong opinion at this point on which one of those two I like better), but I don't see why you'd fork Vector. It seems like the worst of both worlds. If you create a new skin, you get the benefit of being able to start over with a blank slate, at the cost of having to maintain one more skin. If you change Vector, you get the benefit of not having a bifurcated experience that users have to switch to, and the benefit of having existing tools (mostly) continuing to work, at the cost of having to deal with the existing code. If you fork Vector, you don't get the benefits either, and you pay the costs of both. You'll be a little bit freer to break existing things in a fork I suppose, but overall it would make more sense to me to either choose to make a clear break or to stick with Vector, not something in between.

I've shared it before – resolving several of the long-standing needs for changes to MediaWiki core's skinning system, see a.o. T114071: Let's discuss the skin creation process, would imply bringing those changes to both (Vector & new) skins. More so bringing it to all currently deployed Wikimedia skin. Even if we separate front-end architectural changes from product-inspired development efforts (f.e. new header appearance etc.), we wouldn't save a lot of work, rather have to invest more than iterating on existing skins.
Additionally to the partly unresolved maintenance question of current skins and future product developments, above leaves me to estimate that an iterative approach to Vector/MinervaNeue would provide a clear engineering cost advantage over an additional new skin mid- & long-term.

Thank you @Jdlrobson and @Isarra for the additional proposal of starting a new skin from scratch (and everyone who’s chimed in so far). During previous conversations with the web team, the option of a brand new skin was disregarded off-hand as being impractical. However, when considering the startup cost of fixing Vector vs. Building a Vector-like skin from scratch, I can see how the two might be comparable (having never written a skin myself though, it’s hard for me to judge).

The thinking behind forking Vector is that we would first refactor Vector in such a way that it could accommodate both the new and old designs. Architecting the skin in this way would allow us to slot in new UI elements on a per-component basis (e.g. new sidebar, header, etc.) instead of changing everything at once.

However, I see how this architecture could be achieved with all options (inside Vector, fork Vector, new skin).

I think it helps to look at some of the initial designs from the Wikimania slide deck when considering these options. https://www.mediawiki.org/w/index.php?title=File:Wikimania_-_desktop_improvements_session_final_version.pdf&page=28. I think it’s fairly certain that we will be making layout changes as part of this project.

We want the option to make these changes gradually, but I think it’s fair to say these changes will be big. If we make these changes inside Vector while maintaining the old Vector layout, to me that feels like we’d be making a skin inside a skin. We can refactor the layout inside Vector as well, but IMO, that risks breaking Vector everywhere in production. My primary rationale for advocating for a vector fork (or new skin) is the ability to make those changes without that risk.

I think I understand the product reasoning behind the technical solution. If I understand the goal correctly. We need to provide two things to users: 1- Make gradual changes, no sudden or gradual roll out of a completely new look, so next month we start collapsing sidebar items, the month after that, moving them to up (just an example), and so on. 2- Let people get back to the old look if they don't like the changes. It makes sense to make a new skin by copy-pasting the vector code and calling it "Vector 2.0" and rolling it out to everyone, no one notice any changes, it's the same code. but then slowly moving things around in "Vector 2.0" to let people simply change to "vector" skin if they don't like the changes (at any stage).

I don't know how bad the code for Vector skin is but if it's not much code and the code is really bad, making a new skin that looks exactly the same makes sense (even replacing vector with the new code as well) but if it's lots of code and it's not that unmaintainable, forking makes more sense to me.

we (the Reader’s Web team) have been giving a lot more thought to the new-skin & update-vector proposals recently.

As @Volker_E mentioned, the foundation doesn’t have a good track-record of maintaining skins or deprecating old ones. This raises the possibility that in three years time, or whenever the Desktop Refresh project is “finished”, the new skin might start getting neglected and end up just like Vector. Working within Vector would avoid this scenario altogether.

I see the new-skin and update-vector options as working towards the same goal but from different ends, the goal being a foundation that enables us to gradually introduce UI changes.

In both scenarios, we would have to first clean up the skin system to better separate the data and the presentation layer. Then, for the vector-update scenario, we would have to refactor Vector to make the UI components easily replaceable. For the new-skin scenario, we would make the skin highly componentized from the ground up, but we would have to first make it look and function like Vector, in order to meet the requirement of gradually evolving it.

When the choice is framed as building a new skin that’s essentially a polished Vector clone vs. polishing Vector itself, then to me at least, the polishing-vector approach sounds like the more pragmatic of the two.

Thanks for all the comments so far ! Just to note, we are planning to make a decision by 31st October 2019. If you have any thoughts on the subject please do jot them down here before then so we make sure we have as much information going into that decision as possible.
Thanks in advance!

Edit: Note, I've added an additional proposal that came up in discussions today that is a variant of the forked Vector idea.

Mind if I leave a comment or two here? I would pay need to @Isarra's suggestion. Vector is a unmaintained and complicated skin and as he said you will loose valuable time to figure out it's code and clean it up. Other proposals makes sense to me but I support the proposal one. Since Minerva is already optimized for mobile we won't need to work on it to improve mobile experience. True, Minerva does depend highly on MobileFrontend. But we'll have to break this dependency at some point per T171000. If you work on the proposal one you'll be passively working on the task too. We have several tasks here regarding Minerva third party support and you'll get a chance to work on those. My suggestion would be to leave fork or improve the desktop version of Minerva. Since it is currently under active development by Readers-web-team, I suppose they have more experience working with this skin than anyone else. Creating a new skin needs more effort, not to mention the maintenance costs. Phabricator would be flooded by new bug reports and tasks. You'll have to work extra to make the skin work better.

Thanks to all the feedback people have shared so far! It's been really helpful. If you are lurking on this ticket and also have thoughts, please do share them too!

In particular @TheDJ @Umherirrender @matmarex @Jdforrester-WMF @kaldari @ashley @Mooeypoo @Krinkle as people who have worked with the skin system or have worked on projects involving integrating with skins I would love some input from you here even if it's a simple "I don't think it matters" to help influence our decision before the 31st deadline. Thanks in advance!

Creating a new skin would be the default approach I'd take (whether by forking Vector or starting from scratch).

@matmarex Could you clarify further, why you would take that approach?

It sounds like you want to make fairly large changes, so that way sounds easier and less risky than adding special cases to an existing skin.

I want to second @Jdrewniak's point -- if we can refactor skins first so that skins really are a lighter presentation layer on top of a sensible base page structure, then whatever we choose for the rest of this doesn't matter so much. If we're not going to do that, there's a minefield ahead.

That said, assuming no major changes to how skins work...

Proposal 4 would be my pie-in-the-sky preference. It'd let us set a new baseline for things going forward, and clean off accumulated cruft. That's worth some pain, if we've got the political capital to see it happen and get adopted by the wikis.

Proposal 2 is my realistic choice. Incremental improvements within the existing Vector (maybe with Vector forked to a VectorClassic repo which we could push community maintenance of), which lets us slowly bring gadgets and extensions into compliance without any huge breaking changes, and hopefully avoiding any major community backlash.

I don't think we want to be in a situation where have to maintain more skins, especially no more skins with significant user bases. The amount of support we need to give each skin is proportional to the number of people using it. Accordingly monobook gets very little attention, but this is mostly accepted by the community. If we end up in a situation where VectorNew is the default for new users, but because it diverged too quickly, most of the experienced community is still using VectorClassic for gadget support or comfort, then this will translate into an increased developer burden.

I think the only way to avoid this would be to make small incremental changes to Vector, with appropriate deprecation/breaking change notices, so that the ecosystem can keep up (aka proposal 2).

There is no way to do what was, say, presented in those slides and not create a situation where a significant part of users will request to have VectorClassic no matter what, though.

In T234907#5616982, @Esanders wrote:

I don't think we want to be in a situation where have to maintain more skins, especially no more skins with significant user bases. The amount of support we need to give each skin is proportional to the number of people using it. Accordingly monobook gets very little attention, but this is mostly accepted by the community. If we end up in a situation where VectorNew is the default for new users, but because it diverged too quickly, most of the experienced community is still using VectorClassic for gadget support or comfort, then this will translate into an increased developer burden.

I think the only way to avoid this would be to make small incremental changes to Vector, with appropriate deprecation/breaking change notices, so that the ecosystem can keep up (aka proposal 2).

Proposal 2 has a part "with the current experience maintained in parallel." I take it you're saying not to do that aspect?

Otherwise, with the maintain in parallel clause of that proposal left in tact, I feel like proposal 2 is just as much maintenance burden as any of the other proposals. (But I am not a skin person)

fwiw, my 2 cents is separate skin makes the most sense, perhaps with the two skins sharing some common code (via subclassing or whatever). It sounds like we're talking about making 2 separate skins anyways, but don't actually want to do that. However, pretending otherwise isn't going to magically change the fact we are making two separate skins, and might just make things more complicated in the long run. Thus I think the cleanest option is to call a spade a spade, and if we want to maintain two separate user experiances then make it actually be 2 separate things. That said, this isn't really the usual area I contribute to

@Bawolff thanks for your comment. I agree that in an ideal world, a new skin would be the most sensible option. However, given the state of the skinning system, extension compatibility, gadget compatibility, community buy-in, etc. I don't think the ecosystem is in a state where an additional skin is maintainable. As you mention, the "current experience maintained in parallel" line in Proposal 2 recognizes that realistically, we can't get rid of the current Vector "experience" anytime soon.

So if we’re not getting rid of it, we may as well try fixing it. This is the gist of Proposal 2 - making changes within Vector - and after long consideration, the web team has chosen to go forward with this approach.

@DLynch summarized the reasoning for this approach very well. It’s essentially the most pragmatic option as it avoids major breaking changes. Maybe as @Jdlrobson suggests, we’ll be able to eventually spin these changes out into a new skin in the future, but we wouldn’t want to do that until the skin system is in better shape.

As @Jdlrobson mentioned earlier, the Web Team intended to make a decision on this by October 31 🎃.
I've updated the task description with our decision under the heading "RFC Outcome". Instead of forking Vector as originally proposed, we will be implementing the Desktop Improvements project inside Vector. Every option has it's trade-offs, and after considering the points made in this discussion, we felt that working in Vector was the most pragmatic way forward.
Thanks to everyone who contributed to this discussion!

I'd like to thank everyone who contributed to this discussion and commend the Web team on taking into consideration the tradeoffs. Looking forward to the results ahead.

@Jdrewniak please note that the RFC process is not complete yet, since the proposal has neither been approved nor denied.

To complete the process, TechCom is putting this proposal on Last Call until December 11. If no concerns are raised and remain unaddressed by that time, the RFC is approved as currently proposed.

I just wanted to highlight that we need to take precautions while working on the Vector skin. Some popular 3rd party skins/extensions depend heavily on Vector. For example Hydra developed/used by Gamepedia has HydraSkin, and the SkinHydra class extends SkinVector ( source code: https://gitlab.com/hydrawiki/skins/hydra/blob/master/SkinHydra.php ), therefore any bigger changes to SkinVector might break their sites.

It looks like at least one 3rd party is reusing Vector skin for their custom solutions. Therefore we can expect that many other 3rd parties do the same.

In T234907#5760432, @pmiazga wrote:

I just wanted to highlight that we need to take precautions while working on the Vector skin. Some popular 3rd party skins/extensions depend heavily on Vector. For example Hydra developed/used by Gamepedia has HydraSkin, and the SkinHydra class extends SkinVector ( source code: https://gitlab.com/hydrawiki/skins/hydra/blob/master/SkinHydra.php ), therefore any bigger changes to SkinVector might break their sites.

It looks like at least one 3rd party is reusing Vector skin for their custom solutions. Therefore we can expect that many other 3rd parties do the same.

In fact, i believe at one point this sort of subclassing was explicitly reccomended in the docs somewhere

In T234907#5760708, @Bawolff wrote:

In fact, i believe at one point this sort of subclassing was explicitly recommended in the docs somewhere

Ok, that's pretty useful information. It means that there might be many cases like that. Thanks for the information.

In T234907#5701283, @daniel wrote:

@Jdrewniak please note that the RFC process is not complete yet, since the proposal has neither been approved nor denied.

To complete the process, TechCom is putting this proposal on Last Call until December 11. If no concerns are raised and remain unaddressed by that time, the RFC is approved as currently proposed.

Can this be resolved now?

On 11 December the Last Call was evaluated and we did not yet hear back from participants that previously raised concerns where TechCom decided to wait a week longer before approving. (minutes)

On 18 December the RFC was approved in accordance with the process. (minutes)

This RfC might have been closed and I've had missed it, however, I haven't found a follow-up discussion, therefore I hope this comment is fine here.

Proposal 6: Create a new skin based on Skin:Timeless that encompasses all the advancements proposed

Many of the design ideas converge towards the design of Timeless, some of the mock-ups practically turn Vector into Timeless.

There's a lot in common between the Vector and Timeless skin. The content, the tools all have mostly the same styles, what's different is generally more up-to-date and simpler. The new skin would benefit from all the effort Isarra has put in her skin, saving a lot of tedious work to clean up Vector. There's been significant effort put into that project and it's now a finished product, that's ready to give its benefits.
While a new skin is being developed it's worth considering to make Timeless the default skin. That would be a real appreciation of her efforts.

Proposal 7 (orthogonal): Modularize skins, reuse common components (content styling, builtin tools)

Related to: T217158: RFC: Skin templating (on wiki)
Skins mostly differ in the header and sidebar (navbar), big parts of the skins are common, copied without change: the content, the tools like search, history, differences, logs, input forms are all styled in the same way.
Currently updating these styles would require editing by hand each of the 5 active skins: not practical. A lot of work can be saved by separating reusable components. I reckon the themes Minerva, Chameleon, and Vector already do some of this separation. Note that modularization can be done progressively, it's not a prerequisite for any development, but it benefits the new and current skins too.

By separating the components users can be given the choice of which sidebar to use. There can be a minimalistic sidebar for hardcore wikipedians and a full-featured sidebar with tabs (toc, navigation, tools, bookmarks) for the casual readers and editors.

The modules should be based on the most up-to-date implementation out of the 5 skins. Modularization is also an opportunity to update the html and css to the present-day html standard, for ex. clean up a lot of table and float-positioning, replacing those with flexboxes (supported by all modern browsers). This cleanup simplifies the DOM, reducing the number of elements and the code size.

Regarding forking or not

There haven't been significant changes to skins in recent years. MediaWiki operators expect the stability that their installs and customizations won't break after an update. For this reason, the skins should be forked for the significant changes that would be the outcome of these plans. The original skins would be deprecated and kept for backward-compatibility.
The updated skins, however, should retain the same name (in user settings), only changing the internal project name to ex. Vector2, or Vector2020, or VectorReloaded. Operators then can opt-in to switch to the revised skins by changing the list of loaded skins.