Hi,
I received an unsolicited email stating that "In collaboration with the
global Wikimedia community, we are working with the Wikimedia Foundation to
help movement organizations understand how they have an impact" and asking
me to fill out a survey. However there are no references about which
program or which collaboratio are they talking about.
I have looked for "tccgrp" on meta and there is no information about it,
nor on the wmf page. The only reference I could find is a mention to TCC
Group in the guest list:
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Report,_April_2014
Should I consider this request legit?
Cheers,
Micru
Re: Erik Möller's remark: "In general, though, let's talk. The overarching
principle we're not
going to budge on is that this process is really not acceptable:
1) The UI changes
2) A subset of users is upset and organizes a poll/vote
3) The poll/vote closes with a request to undo said UI Change and a
request is filed
4) WMF offers compromise or says no
5) A local hack is used to undo said UI change
That's no way to develop software, and that's no way to work together...."
=========
I could spend 10,000 words on this. I'll try to keep it (comparatively)
short.
The reason this dysfunctional situation develops, Erik, is because there
are no steps A, B, C, D, E, F, and G preceding #1 on the list.
As things currently stand, this is the way the software development process
at WMF seems to me to work:
* Engineers collecting paychecks obviously need something to do.
* Someone comes up with a bright idea that sounds good on paper.
* Engineers decide to make that idea a reality and start work.
* Inadequately tested software, sometimes of dubious utility, is
unilaterally imposed on volunteers.
* If new software is problematic enough, volunteers revolt by any means
necessary.
* WMF forces changes down throat of volunteers by any means necessary.
This is truly "no way to develop software" and "no way to work together."
-----
Here is the way the process SHOULD begin:
* WMF staffers, plural, identify by user names/IP addresses the 10,000 or
so very active volunteers across all projects and database them.
* WMF staffers further divide this group into coherent "types": content
writers, gnome-type copy editors, structural adapters (template people, bot
operators, etc.), quality control workers (NPP, AfD), vandal fighters,
behavioral administrators (ArbCom, Ani, the various Admin pages), and drone
bees who do nothing but Facebook-style drama mongering. Multiple categories
may apply to single individuals and this list is not necessarily exhaustive.
* Once identified, WMF staffers frequently and regularly poll very active
users in each category about WHAT THEY NEED. Different surveys for
different volunteer types.
* Software development starts ONLY when a real need is identified.
* Software should be introduced on En-WP, De-WP, or Commons ONLY when it is
Alpha-grade, debugged and ready to roll. (Test things on the smaller Wikis
first).
-----
Moreover, there should be some polling mechanism to summarize and analyze
what the 500 million or whatever readers worldwide feel that they like and
feel they are missing. "User experience" changes with primary impact on
readers rather than volunteers (such as MediaViewer) should be made with
them in mind first and foremost; editing and structural tools should be
made to actually assist the active volunteers, not created on a whim.
Sometimes the needs of the Readers and the needs of the Volunteers are
different, let us frankly say. In no case should WMF assume the views and
criticism of the latter are insignificant or wrong simply because
500,000,000 > 10,000.
Remember this because according to the same logic: 10,000 > 240.
-----
We all agree that we need a bigger pool of very active volunteers. Most
readers are never going to be very active volunteers, nor do we want them
to be, since we need specialized skill sets. Most people using the editing
software are only going to make one or a very few changes a year and they
are never going to even "see" the backstage world of Wikipedia. That is
normal and fine.
We do need expert contributors on esoteric topics and we need solid
contributors from the developing world and we need to replenish the people
doing copy editing and quality control work.
We don't need tools that nobody asked for and nobody wants shoved down our
throats just because engineers needed something to do.
240 Paid Staff + 10,000 Serious Volunteers + 500,000,000 Readers and
occasional minor contributors
Three groups with differing needs.
Tim Davenport /// "Carrite" on WP /// "Randy from Boise" on WPO
Corvallis, OR
Hi,
On Mon, 18 Aug 2014, at 10:12, Risker wrote:
> Well, hold on here.
>
>
> On 17 August 2014 19:55, Pete Forsyth <peteforsyth(a)gmail.com> wrote:
>
> > I think it is also a problem to look at this in terms of "bugs." I don't
> > think you can retrofit good design into something that has a variety of
> > substantial problems, by merely "squashing bugs." You might say that is the
> > wiki way, but it is widely known that some tasks are better suited than
> > others to ad hoc collaborative processes.
> >
>
>
> Given the current use of bugzilla, which doesn't limit itself to bugs but
> also feature requests and enhancements over the base functionality, calling
> everything reported using bugzilla a "bug" is incorrect and inappropriate.
>
>
> >
> > In this case, we have a broad range of issues:
> > * does it let the reader know they can help improve the page or upload
> > another photo
> >
>
> The Commons/File pages don't do that, why would you expect this software to
> do it?
It does. There is an Edit button at the top, and an Upload button at the left.
>
>
> > * does it reflect copyright holders' licenses accurately and effectively
> >
>
> Agree this is important. Do you have any evidence that it is any less
> accurate than the Commons/File pages?
>
>
> > * does it adequately respect the privacy of the subjects of photos
> >
>
> The mere fact of the image being used on an article anywhere on a Wikimedia
> project suggests that this problem is in the actual usage, not in the
> software being used to display more information and detail in the image.
> If you believe that this is a serious issue, then it should be addressed
> where 100% of readers can see it, not in a subpage viewed only by the
> limited number of readers who click on the image. It's not a Media Viewer
> problem, it's an image usage problem.
Showing description is important for privacy of subject of photo in some cases. I.e. if I kill a cat for a movie and someone takes a picture, I should be able to tell readers that I'm doing this for a movie. The long description usually does so, if needed. Otherwise the readers might perceive that doing this is my usual activity.
This is probably not the original issue in mind of the first folk who mentioned privacy two paragraphs up there, but that's the first thing I can think of.
Another thing is slideshows. "The Big Pictures" website lets people browse pictures with long descriptions. We have galleries, and MV's left/right arrows. Why not make something in the middle, with both a long description/caption, and these left/right arrows?
>
>
> > * does it reflect a "look and feel" that we feel OK about and is consistent
> > with the rest of the software
> > etc. etc.
> >
>
> What problems are you seeing here? Spell it out, rather than making vague
> suggestions that there is an issue.
MV is inconsistent, because other pages (history, talk) still force a page reload, for instance, and returning from them back to an article isn't as easy as one 'X' button.
>
>
>
> >
> > Fixing one "bug" may well lead to other bugs, or negatively impact those
> > already reported. What is needed, I believe, is a well-facilitated process
> > to identify the problems and the best solutions. This is not easy to do and
> > takes time. But I think the WMF has (not for lack of trying) managed to do
> > a very bad job of that with this software product, and with many software
> > products in the last few years. That does not mean it is impossible to do
> > it that way, only that those specific efforts were insufficient.
> >
>
>
> Why is this a Media Viewer issue? This is a problem for all types of
> software on all types of platforms, and is a challenge even for IT
> departments hundreds of times the size of the WMF. I cannot think of any
> software I have used in the last 20 years that has not had "bugs" or
> unsatisfactory UI elements or seems to miss a functionality I'd like to
> have. It is unreasonable to hold a comparatively very small organization
> to a standard that can't even be met by IT giants.
>
> Risker/Anne
No comment on this one.
svetlana
Are we there yet? This subject has been so done to death, that the corpse
of the dead horse that has been flogged is going to rise as a zombie and
eat out your brains. There is next to no original thought coming through
just verbiage, and it is time that people subjecting the whole list to the
continued indigence.
There is an RFC, there is a process being followed, I invite those who wish
to now comment to use those vehicles and be considerate to those who have
had enough of the subject matter.
in light of the recent conversation about superprotect
and about what community could or should do to get things done
specifically i am worried about guidelines on rfcs
it is completely and utterly wrong to get feedback about software on a small page 99.99% of users dont know about
and i find a lot of rfcs are written poorly and are a waste of time
please try to participate in draft of a help thing - not policy! - on rfc guidelines here;
https://meta.wikimedia.org/wiki/Talk:Requests_for_comment#Suggested_guideli…
the bit is pasted from mainspace onto talk page,
and you should give it your good axe
--
svetlana
Lets all welcome the new overlord Erik.
Add a new protection level called "superprotect"
Assigned to nobody by default. Requested by Erik Möller for the purposes
of protecting pages such that sysop permissions are not sufficient to
edit them.
Change-Id: Idfa211257dbacc7623d42393257de1525ff01e9e
<https://gerrit.wikimedia.org/r/#q,Idfa211257dbacc7623d42393257de1525ff01e9e…>
https://gerrit.wikimedia.org/r/#/c/153302/
Someone clearly can't take criticism of their projects well.
Dear Wikimedians,
We have put out a statement on the CIS-A2K's FDC proposal discussion
here [1]. As you will note the statement reflects on some of the
critical points of feedback that we received and outlines the steps that
we have taken and plan to take.
On behalf of everyone at CIS, we thank the Wikimedians, WMIN EC, FDC
Staff, FDC Members and the WMF Board who actively engaged with our FDC
proposal. We have learnt some useful lessons because of the FDC
discussions and assure you that we will continue to improve upon our
programmatic efficiency, efficacy, accountability and transparency.
Apologies, that this mail is coming at least a couple of weeks late.
Best,
Vishnu [[User:Visdaviva]]
Program Director (A2K)
CIS, India
[1] http://bit.ly/1m0fQn0
On Fri, 15 Aug 2014, at 00:52, Niklas Laxström wrote:
> Translate extension has supported for a long time having any language
> as the source language. There just has not been an interface in
> MediaWiki to set the source language of a page.
>
> The good news is that Kunal Grover, a GSoC student has created
> Special:PageLanguage to do just that. [1] I expect it will be
> available quite soon.
> [...]
>
> [1] https://www.mediawiki.org/wiki/User:Kunalgrover05/Progress_Report
On Fri, 15 Aug 2014, at 01:50, Philippe Verdy wrote:
> This is good development, but I don't see why we need a special page to
> define what is metadata of the page itself.
> [...]
Yes, I have same question.
On Fri, 15 Aug 2014, at 01:50, Philippe Verdy wrote:
> May be it will be accessible
> from the VisualEditor; like we edit categories, but such metadata is a
> general need for lots of other applications. The general need would be to
> be able to associate metadata with a symbolic type to any page: just a few
> metadata is currently handled in MediaWiki: categories, default
> sortkeys, interwiki links, plus a few other flags inserted by using magic
> words (like __NOINDEX__).
>
> There are also external metadata stored in Wikidata for some wiki projects.
> More are needed (e.g. for different typing sort keys).
> Any way I expect to see soon a reliable way to detect the page language
> including for translated pages; but more importantly for sources of
> translations without having to assume they are in English, or create thme
> in another language and creating a pseudo-translation to the original
> language by copying keys, then modifying the English source again but
> keeping the original text.
> At least, when we mark a new page for translation, we should immediately
> have an option asking in which language is the source; if it's not specifid
> by the new experimental Special:PageLanguage page (which is not necessarily
> needed).
>
> And once a source page has been marked for translation, the Translate tool
> should have a simple API to query its language or the language used in the
> generated translations, And ideally, we should be able to swithc from one
> source language to another (for example some projects start in English, but
> are later managed in German or Chinese, or a local Chapter initially
> creates documents in its own local language such as French, Hindi or
> Spanish, and will not use English as the reference (this is important for
> pages reporting local projects mostly done in other languages, outside
> countries or regions with a majority of native English-speakers, i.e: most
> countries of the world, including Europe (and even North America where
> French and Spanish are very present too ; Spanish and Chinese are also
> growing fast in US, and here there are aslo local communities that would
> like to promote their own local projects in their native non-English tongue
> : do you remember that US does not have any "official" language ?).
Kunal Grover, could you please fill in about that?
svetlana
Hi all,
Some of you have asked the Board and its individual members for feedback. Some of us are already in conversation with you or are planning to answer on different pages. This is our general common statement:
The Board supports the decision to protect the Media Viewer roll out. Our platform powers a top-5 website. We need operational protocols that are consistent with this position. This includes making improvements, rather than a tendency towards reverting to the status quo.
At the Board meeting before Wikimania, Lila laid out her strategy to put in place best practices for product development. We will communicate sooner, we will prioritize smarter, we will test more, and we will achieve better outcomes. Her vision is to involve the community at each step of product development, including more structured feedback stages and reviews. We endorse this vision.
We realize that there is concern about the superprotect user right and how it affects power balance and influence on content and administration. We recognize the concern that we need to explain and introduce our measures better. However, stability of the platform is necessary as we seek to improve our sites, and, for that reason, we support the creation of this tool. We also understand that with more robust rollout plans and better staged community feedback - as Lila envisions - the tool should rarely be used.
We urge you to focus on specific improvements you'd like to see in the Media Viewer and the roll-out process. Lila intends to incorporate that feedback as she plans to improve Media Viewer and the process for future product roll outs.
The Wikimedia Foundation needs to be in a position to make software and configuration changes for which it is responsible. We expect restrictions of MediaWiki code-level editing to be a temporary step to enable us to move forward with improvements. As we say, Media Viewer should be improved; our procedures to date have not yet met the high standards we want to set for ourselves. Lila wants to address both now, and we need to give her the space to do so. She has our full support and confidence as she tackles this tough challenge.
On behalf of the Wikimedia Board of Trustees
Jan-Bart de Vreede
Chair
Board of Trustees
Wikimedia Foundation