Hi Amir, Were these changes discussed in advance with Wikimedia communities on mailing lists, village pumps, etc? I am thinking particularly of template designers and maintainers, who may have coordinated their work with the previous color scheme. It seems to me that Wikimedians should be given plenty of notice that color changes like these are proposed, and should be given ample opportunity to comment on them before they are rolled out, but this is the first that I recall hearing of these changes. I would go so far as to say that there should be an RfC before making changes like this to community wikis. Also, it seems to me that there should be a period of a few weeks between the commitment to make a change like this and the implementation of a change so that Wikimedians whose work is affected have an opportunity to prepare for changes. I'm not going to push for a rollback of this change unless I hear a lot of community voices saying that this particular set of changes is a problem, but I would hope that changes like this would be communicated and discussed widely in the future and that an RfC would be undertaken before making these kinds of changes to community wikis. Pine On Thu, Dec 8, 2016 at 4:45 PM, Amir Ladsgroup <ladsgroup(a)gmail.com> wrote: border your is have on _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Totally agree. It's not a question of how small/large such a change is, it's a question of collaboration and mutual respect. Which was lacking, yet again :(

Some communities will miss these changes completely just because they had already overridden the old values in Common.css, most likely for historical reasons. A heads-up would have allowed them to decide on whether to go with the upstream changes or stick with the current layout.

<https://xkcd.com/1770/> seems pretty timely!

While I appreciate the attempt to be funny, I am not amused in this case. Surprise UI changes could, for example, result in thousands of dollars' worth of instructional videos becoming instantly out of sync with the real-world user experience. Also, users who may have spent considerable time perfecting their templates may be surprised to find that they need to make changes to keep the templates in sync with other changes to the UI. The problem isn't so much that the UI was changed, as that it was changed without notice and consultation. This isn't funny.

Pine, please chill for once. On Fri, Dec 9, 2016 at 5:40 PM Legoktm &lt;legoktm.wikipedia(a)gmail.com&gt; wrote: case. UI. changed _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hey, If a community dislikes a change they can instantly override it using mediawiki:common.css. In that case, no one would forces them to change it back. But these changes are too small to notice and even smaller to dislike. For example no one is trying to change blue to red, But we changed a certain shade of blue to another shade that you are more familiar with and seen in other places. That's why for small changes we never got negative feedback. We are doing this to give users better experience by using familiar colors. It's really hard to see any objections overall. Best On Fri, Dec 9, 2016 at 10:03 AM Pine W &lt;wiki.pine(a)gmail.com&gt; wrote: be but far of discussed history keep changed strengthen Echo _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

It returns permission error to me

On 10 December 2016 at 19:07, Gergo Tisza wrote: Is there any reason this is being discussed on a File compared to a task?

Is there any reason security has been changed on this file?

For reference, these are the changes being discussed: https://phabricator.wikimedia.org/F5022813 1) Significantly larger changes than this are happening all the time (the OOUI-ification of old forms, for example), without anyone noticing,

it's pretty clear people are reacting to the announcement here and not the actual change.

There is nothing wrong with not paying attention to something well outside your work area, and people should not be excluded from a discussion topic just because they are new (or casual) to it, but please consider how it creates an unhealthy community dynamic when people are criticized for announcing changes which would otherwise go unnoticed.

Regarding a heads-up, would it have helped to have these changes listed in https://meta.wikimedia.org/wiki/Tech/News/2016/49 ?

I just want you to stop there On Sat, Dec 10, 2016 at 2:07 PM Strainu &lt;strainu10(a)gmail.com&gt; wrote: > That's one way to put it. I would rather say that we reacted to yet > another slip-up in communication from the Foundation. Why is it so > hard for you guys to push the information to wikis? > > Why is this related to WMF?

Do you really want to compare this to something like MediaViewer rollout?

On Sat, Dec 10, 2016 at 3:19 PM Strainu &lt;strainu10(a)gmail.com&gt; wrote: For 3 reasons: 1. While MW is open source, what gets deployed on the WMF servers is the legal and moral responsability of the Foundation. They have responsibility but it's limited. 2. The WMF has an 8-person "Community Liaisons" team that is dedicated to "inform the communities during the whole process of development of said software, and facilitate its adoption." [1] For me, that means that they should be the ones that make sure that changes that impact million of pages don't get left out, even if the developer forgets to notify anyone. It's not correct. community liaisons can't check every patch to see if it's going to impact users (and most patches have effect on users, even indirect). They built a protocol and told developers to inform them when they think the change is going to impact users *significantly*.

3. The average wikipedian does not seem to make the difference between volunteer developers and employees of the WMF (this is a personal opinion and I might be wrong). It's horrifyingly wrong. Lots of stuff is being done by either volunteers or staff in their volunteer capacity. You need to correct this view. not to blame WMF, right?

Best _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

2016-12-12 10:21 GMT+02:00 Quim Gil &lt;qgil(a)wikimedia.org&gt;rg>: (draft Guideline/Milestone_communication Thank you for the pragmatic approach Quim. I launched 2 discussions there, referring to changes that require action from the communities [1] and changes affecting large number of pages [2]. Hopefully we can find a middle ground on at least some of the subjects. Strainu [1] https://www.mediawiki.org/wiki/Topic:Th1vs3h97d96ajaf [2] https://www.mediawiki.org/wiki/Topic:Th1wc4pu1qplo4k8 _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I have delayed responding to this thread until I felt that I could do with some degree of calmness. I view UI changes that affect millions of pages as a big deal. I realize that from a developer's perspective it may seem trivial to change a color setting. Let me try to illustrate a different perspective that might help to explain how seemingly small changes, when implemented at large scale, can have significant effects. I am going to ask for the collective patience of the people in this thread as I explain a perspective that appears to be different from a number of theirs. Marketers spend significant amounts of time and money designing their sales pitches to the public. One of the many elements considered in these communications is the use of color. WMF Fundraising appears to be very aware of this, as Fundraising tries different color variations in their banners and in-line marketing. I believe that in either the 2012 or 2013 fundraising campaign, I heard Sue say that Fundraising had found that year that displaying the banner message with a green background resulted in a significant increase in revenue for that year's fundraising campaign. Marketers make use of color on a regular basis in their research and communications to the public, and as WMF Fundraising seems to have experienced, these changes can lead to important changes in consumer (or donor) behavior. My guess is that the folks in WMF who work on user retention and usability studies also are mindful of small changes that could be made to the UI that could lead to important changes in user behavior. So, I believe that small UI changes that will be applied to millions of pages are not trivial matters, even if the changes are easy for a technical staffer or volunteer to implement. With that as my starting point, let me proceed further into describing four difficulties that surprise UI changes present, particularly when done on large scales. In the examples below I am speaking about UI changes in general, not only the particular case of color changes. (Perhaps splitting this more general discussion into a separate thread would be appropriate, and if someone wants to do that I think that would be OK.) * As described above, there may be important changes in reader or user behavior. (I realize that WMF lacks Google's financial and human resources for extensive testing, but this still should be kept in mind when considering UI changes. As mentioned above, WMF Fundraising seems to be aware of this, and I imagine that WMF staff in other departments are as well.) * Documentation may need to change in a large number of places, many of which are maintained with volunteer labor, and until those changes are made users may receive incorrect information that leads to adverse effects. * As I mentioned previously, designers and maintainers of templates may need to update them to sync with the changes to the UI, and I imagine that these people would appreciate advance notice instead of being surprised with a change. * Those of us who are trying to future-proof our work to the extent possible are put in a difficult position. In my case, WMF is paying me grant funds to develop instructional videos about Wikimedia. I think that everyone involved in the project understands that changes will happen and that the videos will need to be updated at some point in the future; the way we are designing the project is intended to make it relatively easy to make changes and do translation work. However, we are trying to design the videos such that they are very well aligned with the state of the UI that Wikimedia users will encounter when the videos are launched and for at least the next several months thereafter. If we spend thousands of dollars producing video and then there is a surprise UI change that makes all of our work out of date, perhaps even before the videos are fully published, this puts us in a difficult (and potentially expensive) situation that would have been avoided if we had known about the upcoming changes. Importantly, a significant UI change that is covered only in a single segment of the video, such as a change to a particular workflow, might be easier and less costly to illustrate in the videos than a small change that makes many or all segments of the video series out of sync with the current real-world user experience. In the latter case, we'd be faced with the decision to either accept that many or all of the videos no longer reflect the user experience or potentially spend thousands of dollars to do rework. I anticipate that eventually all of the videos will be reworked, and yes someday there may be a UI change (or a collection of changes) that impacts all of the videos significantly enough that a decision is made to update all of the videos, but I'd like us to at least have all of the videos be in sync with the user experience at the time that the videos are launched and presented to to the communities and affiliates for use in education, GLAM, online help, and other initiatives and workflows. I hope that this helps to explain my perspective. Pine _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hi Peachy, As an example of a potential high-impact color change that would result in a need to change documentation, I recall a proposal to change all red links to a different color. I don't recall the user's reasoning for the proposed change, but that is one situation where I believe that color alone signifies important information to the end user. I understand that in the example that came up in this thread we're talking about UI color harmonization rather than a move that would be as obvious a color change to users as changing red links to (for example) green links. Does that answer your question? I was thinking about UI changes in general, particularly across millions of pages, rather than about a specific scenario of color being used intentionally to convey a certain kind of information to the user. Pine On Wed, Dec 14, 2016 at 1:12 AM, K. Peachey &lt;p858snake(a)gmail.com&gt; wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l