Talk:A modern, scalable and attractive skin for MediaWiki

Latest comment: 10 years ago by QuimGil in topic Ready for 3rd parties?

General comments

edit

Hi, thanks for your proposal! Nice to see this problem now has some attention. Some things.

  • Throughout the proposal, it's not clear what things are going to happen in core and what in the skin itself/an extension. Please clarify body and title. For instance, if the focus is having a skin for/like wikiHow, I'd expect this to end up at wikiHow skin revamp or similar (much shorter).
  • Based on the clarifications above, I think the schedule needs some overhaul. It's not currently clear where the bulk of the work is going etc. I think you can't just let code review surface where things are need most work, leaving all such hard things to an afterthought/after-the-fact patching. I'd like you/us to use past skinning experience to identify the pain points beforehand.
  • How was wikiHow's skin chosen? Is wikiHow interested in using this new version? Is the skin representative of most of the issues most skins have, or how do you know that implementing this one skin will benefit others too? It would be nice for you to contact the authors of most important skins so that they can comment here.
  • With "works on the latest stable version of MediaWiki", do you mean 1.22 or which releases specifically?
  • Absolutely avoid this: "GitHub or Gitorious will be used as a backup". If the unlikely event of the repo being late, bully someone at San Francisco, get the gerrit admins' phone and call them, blackmail the goddess of git, whatever, but don't work on GitHub. We've seen very poor results from GSoC students who did so.
  • Thanks for mentioning i18n. How did you estimate that point, how big a pain point is it for custom skins in the wild? You only mention adding i18n support to one skin, what's your experience with MediaWiki i18n in general?

--Nemo 08:08, 18 March 2014 (UTC) P.s.: First candidate from outside far East!Reply

Hi Nemo, thanks for the comments and questions! Let me try to address the concerns you have.
  • The title is somewhat intentionally long and descriptive; it is also site-agnostic, describing the feature rather than its origin. I plan on forking the wikiHow skin and developing it further instead of "just" cleaning it up (which, mind you, would already be quite a task). Focusing too much on the origin of the code has the potential to unnecessarily confuse people; that's why BlueSky's default color scheme (theme) won't be the "wikiHow green" currently in use on wikiHow.com — the project does not aim to create even further brand confusion.
  • I confess that I'm not the best person when it comes to scheduling things and seems that you're the first one who's spotted that. :-) Only time will tell how much time is necessary, but I think the initial schedule described here has enough of air in it to account for any and all unexpected things and delays.
  • wikiHow's skin is available under a free and open source license (GPLv2, as is most of MediaWiki's codebase and most third-party extensions and skins) and it incorporates elements of modern design, while still supporting even legacy browsers in an acceptable manner. The skin has been praised by wikiHow users, but given its interdependencies on wikiHow extensions and core patches, it's not like you can just download and install it like any other custom skin.
  • Despite my numerous attempts at discussing with wikiHow regarding collaboration with upstream and easing future upgrades, it seems that essentially nothing's changed and the statement on src.wikihow.com is still true: "We are not accepting patches to the source code". Personally I view this as harmful to everyone, but especially to wikiHow — open source and more importantly, open collaboration is an opportunity, not a threat. I can understand that the engineers' time is limited and that their engineering team might not be as big as that of Wikia's or Wikimedia Foundation's, but it's still not a valid excuse in my opinion; smaller sites (such as ShoutWiki and Brickimedia) with even smaller engineering teams are able to contribute to upstream just fine because they are willing.
    I would love nothing more than to see the tools developed by wikiHow get the attention they deserve, in terms of patches and internationalization support, but right now this doesn't seem likely. Creating a fork is very easy, but keeping it in sync with "upstream" (in this case, wikiHow) changes is not, and that's the biggest issue with forking wikiHow's creations.
    Finally, you may find the file imports.php in the wikiHow source code root directory interesting. (It's a file which gets included from LocalSettings.php) There's a section titled "English-specific extensions" in there; this is something I hope we wouldn't have to see in 2014, given that MediaWiki has had exceptional internationalization and localization support for many, many years. Yet it's reality.
  • Based on my experience with MediaWiki skins, I'd say that the wikiHow skin is a rather good example of common issues that third-party skins have. Of course there are some extra hoops and whatnot in the skin file, given the complexity of the skin combined with the fact that it's used on a top 200 website.
  • The definition of important can be problematic; are we able to agree on a definition? Are only FOSS skins important, or do popular skins that aren't (yet) freely licensed qualify as important if they're used on notable websites? And so on — I think you get the point. For what it's worth, I've been discussing with Matma Rex (core developer who maintains the Cologne Blue skin) and UltrasonicNXT (Brickimedia developer, primary author of the Refreshed skin) about issues related to skinning.
  • "Latest stable version" means the 1.43 branch (and thus, by extension, the latest development version is also supported).
  • What's the reason for avoiding GitHub or Gitorious? "Poor results" sounds rather vague and not really specific enough for issues to be addressed adequately. GitHub is extremely popular with various FOSS developers and organizations developing FOSS — which, in a way, is ironical, given that GitHub itself is not free and open source software. I have to say that I'm extremely fond of the ability to commit to a GitHub repository via SVN, though — but since the code isn't open, it's not like we're able to implement that for git.wikimedia.org. Gitorious is fully free and open source and it's the second most popular Git hosting service. Of course, having the code hosted on the official repository does bring an additional level of trustworthiness, at least in my opinion, but the whole issue is mostly theoretical — so far I haven't had any bigger issues with the repository creation process, although I gotta say I do miss being able to "just do it", as you were able to during the SVN era. It's much more in line with our guidelines of being bold when changing things or spotting something you think needs to be changed.
  • Internationalization is a big pain point for skins. Either skins try to reuse core messages as much as possible (which is something), or then they don't do any (extra) i18n at all (which is, obviously, very bad). While my developer portfolio doesn't go in-depth detail on what I've done with each and every extension listed there, I'm no newcomer to MediaWiki's i18n framework. Social tools, for example, either had very poor i18n support or no i18n support at all. Nowadays it's possible to use any and all social tools from SocialProfile to FanBoxes and beyond in your native language (provided that a translation exists in said language, that is).
Do let me know if you have any follow-up questions and I'll be happy to answer those! --Jack Phoenix (Contact) 03:08, 19 March 2014 (UTC)Reply
  • Ok, but I still have no idea what the project is about and in particular if you plan to do some changes in core and which.
  • I might be the first but I also am the first commenting on wiki.
  • TL;DR: we like this skin. Ok.
  • The difficulty in defining "important" extensions is no reason to avoid contacting any; it's not hard to send messages to few people and excluding some is better than excluding all but two friends. However, due to point 1 I don't understand, maybe the needs of other skins are not in scope for this project.
  • See Mentorship programs/Lessons learned, "These tools require more discipline, and open the project beyond the mentors to the rest of the community". Please use gerrit.
  • Thanks for adding some details on i18n.
--Nemo 09:40, 19 March 2014 (UTC)Reply

About the mentors

edit

Thank you for this original proposal. I'm curious about the interest and contributions of the mentors in this proposals. Isarra, Emufarmers, are you in sync already or are you volunteering separately? Have you discussed this project before or did you just volunteer when you saw the proposal? Do you think between both of you have the skills needed to mentor Jack or do you still think that more backing would be needed?

Have you considered contacting WikiHow, inviting them to assign a co-mentor, like for instance the main developer of this skin?--Qgil (talk) 21:40, 21 March 2014 (UTC)Reply

We're in... sure, that, and should be able to cover most all of it, assuming Emufarmers is as good as his shirt says. Also something something about wikiHow's limited resources and general history with such projects, but Jack's the expert there. -— Isarra 02:42, 22 March 2014 (UTC)Reply
Cahoots, that's the word. We're in cahoots. -— Isarra 06:46, 22 March 2014 (UTC)Reply

Contrary to the goals of GSoC

edit

I oppose this project, only because it seems contrary to the stated goals of the Google Summer of Code, which include allowing projects "to more easily identify and bring in new developers". In this case, the student is a longtime MediaWiki developer - who in fact has already mentored a GSoC project. Accepting this project would mean taking a slot away from a student who did need an introduction to an open-source project, whether that was MediaWiki or something else. If this project is useful (and it does appear that way), I would think the Wikimedia Foundation should sponsor it directly. Yaron Koren (talk) 15:53, 23 March 2014 (UTC)Reply

Not necessarily. Google themselves seem to think it's fine so long as the student meets the eligibility requirements. The stipend would support Jack while he works on this (which you seem to agree is useful), if he is selected. I'm not sure the WMF would be willing to sponsor the project otherwise. wctaiwan (talk) 16:11, 23 March 2014 (UTC)Reply
Ah, my apologies, then. I looked around for a statement like that from Google, but couldn't find one. I still think this project, at least, is a violation of the spirit of GSoC, but clearly that's not a universal opinion. And if the WMF wouldn't fund a project that has this much support behind it, that probably merits a separate discussion... Yaron Koren (talk) 16:21, 23 March 2014 (UTC)Reply
Hi, Yaron. For reference, here's a non-exhaustive list of existing community members/developers that Nemo gave me the other day: Michael Dale, Niklas Laxström, Jeroen De Dauw (in 2010), Brian Wolff, Robin Pepermans, Liangent, Salvatore Ingala, and Harry Burt. Of course, some of those people had had only limited involvement in the development community beforehand, but I think helping existing developers move from the periphery of involvement closer to the center is a worthy goal too.
One of the goals of our selection criteria is: "We want to nurture long term contributors, either recruiting new people or consolidating current members." And our priorities "favor the distribution of bets among known technical contributors, known editors going tech and absolute newcomers, with and without prior free software development experience." We could have a general discussion about revisiting those goals if you feel strongly about the issue, though you can probably tell where I come down on the issue. :-) —Emufarmers(T|C) 17:15, 23 March 2014 (UTC)Reply
It's certainly true that there's been a long history of existing MediaWiki developers becoming GSoC students - but (a) whether that's fully positive or not is a different story, (b) as the number of slots assigned to the WMF keeps growing, I would think more attention should be paid to these kinds of issues, and (c) I think in some ways this would be the most extreme such case - it may be the first case of a WMF mentor-turned-student. I agree that consolidating developers who are on the periphery is a worthy goal - is that the case for this project? That's not a rhetorical question; I don't know the answer. Yaron Koren (talk) 18:01, 23 March 2014 (UTC)Reply
(It's true I made those names to Emufarmers but they came from the top of my head, don't consider that a conclusive list.) Yaron, yes, I think this project potentially could help "consolidating developers who are on the periphery" as you put it. The reason why I insisted on gerrit, above, is not that I hate GitHub, but that I'd like a certain world of third party developers, skin developers, and other people Jack often works with to take a more central place in the MediaWiki development community, integrate a bit more organically. --Nemo 20:25, 23 March 2014 (UTC)Reply
So far, the only restriction we are imposing to ourselves is not to accept candidates for a second time. Our current selection has a priority on diversity of candidates: "in addition to the usual suspects (gender, origin...) we favor the distribution of bets among known technical contributors, known editors going tech and absolute newcomers, with and without prior free software development experience." If this is not good enough, then let's discuss better alternatives for the next round. It would not be fair to change the current process during the current round.--Qgil (talk) 21:43, 23 March 2014 (UTC)Reply
Alright, then - I missed that document as well; so my apologies all around. Yes, I do think the policy should be changed; I think GSoC is a unique and fantastic resource for discovering and bringing in new developers, and any other usage of it is to some extent a waste (no offense intended to anyone). But, as noted, that's a subject for another day. Sorry again. Yaron Koren (talk) 00:18, 24 March 2014 (UTC)Reply

Ready for 3rd parties?

edit

Hi, I was wondering whether your skin is ready for 3rd party MediaWikis. I would be happy testing it in my pet project (as long as I can convince the Orain admins to install it in their farm). What do you think?--QuimGil (talk) 08:22, 1 September 2014 (UTC)Reply

There aren't any external dependencies or whatnot, and it's been tested against the latest stable release + current alpha, so in that respect it's ready.
However, given that designing and implementing a skin — or, as the case is here, fixing somebody's code to be more in line with our coding standards and whanot — is always a complicated thing, it's probably fair to assume that there are some bugs under certain setups; for example, I haven't tested how well the skin interacts with all the various semantic extensions.
Although a lot of the work was done as a part of Google Summer of Code 2014, I wouldn't call this "ready" as in "development on this has stopped and only occasional maintenance patches will be committed", as I still have great plans for this skin; but as with all grand plans, there are plenty of other factors to take into account. MediaWiki-wise alone, I (more or less) maintain plenty of skins and extensions, and then there are my other online commitments, as well as my offline commitments...
tl,dr: Sure, feel free to install it and report bugs and whatnot on Bugzilla. --Jack Phoenix (Contact) 20:48, 1 September 2014 (UTC)Reply
Thank you Jack Phoenix. Requested.--QuimGil (talk) 21:36, 1 September 2014 (UTC)Reply
Return to "A modern, scalable and attractive skin for MediaWiki" page.