Re: [Wikimedia-l] Status update about editing software, June 2016

2016-06-28 Thread Henning Schlottmann
On 25.06.2016 17:15, James Forrester wrote:
> On 23 June 2016 at 17:01, Pine W  wrote:
> 
>> 1. Is Flow feature development still frozen? If and when would Flow feature
>> development resume?
>>
> 
> ​Yes, principal development is frozen. Like with all production software,
> urgent bugs and maintenance are still worked on, and we might add some
> minor features.​

Thanks for the confirmation. I would prefer you would scrap the whole
project, but at least you are not doing anymore damage this way.

> 2. Will VE be enabled on talk pages?
>>
> 
> ​No. This comes up quite often. VE is designed to edit content. Talk pages
> aren't content. 

Talk pages *are* content. Among other things. That's you basic mistake
regarding Flow. On talk pages we need to copy content in order to
discuss it, work on drafts and experiment with all elements of content,
such as templates.

Naked discussion is only the most primitive use of talk pages.

So I would expect you to enable VE for use on talk pages. And I would
expect you to make that an priority over almost every other software
projects you have. That is because VE now is almost decent in articles
and is not that far from being useful.

Ciao Henning



___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Outcomes from the Consultation on Wikimedia movement conferences/Wikimania

2016-02-16 Thread Henning Schlottmann
On 09.02.2016 16:40, Gerard Meijssen wrote:

> When you cap Wikimania, who is not to come?

Employees of the WMF and the chapters, other than WMF's community
engagement team and maybe - just maybe - selected speakers as speakers,
not as general participants.

Wikimania is not for and about employees, they should not be welcome.

Check out the speakers of the last few years: Employees have hijacked
this volunteer event.

Make Wikimania a volunteer conference again. Let volunteers share
experiences and ideas, not listen to employees telling them what to do
and how to do it.

Ciao Henning





___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Community Wishlist Survey: Top 10 wishes!

2015-12-29 Thread Henning Schlottmann
On 29.12.2015 03:40, Pete Forsyth wrote:

> This is not an "either/or" situation. At least in the past, when I have
> manually added Wayback Machine links (or seen them added by bots), they do
> not *replace* dead links, they merely complement them. The English
> Wikipedia templates include two separate parameters for "url" and
> "archiveurl".

That's true only for a) external links that use templates and b) it
assumes that people will be motivated to check for alternatives to
archive links despite their immediate need for information seems to be
satisfied by the archive link.

Maybe I'm not typical in this, but I prefer a dead link over a link to
the archive that was set by a bot without checking for a live link anytime.

Ciao Henning


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Community Wishlist Survey: Top 10 wishes!

2015-12-28 Thread Henning Schlottmann
On 16.12.2015 21:12, Danny Horn wrote:

> #1. Migrate dead links to the Wayback Machine  (111 support votes)

I really hope, you don't follow that wish, as it is detrimental to the
quality of Wikipedia.

Switching dead links to the archive is a move to a dead end, instead of
looking for

a) the new correct URL, as many links were just moved.
b) alternative sources for the same fact.

Ciao Henning



___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Quality issues

2015-12-15 Thread Henning Schlottmann
On 08.12.2015 00:52, Craig Franklin wrote:
> In a database, we are limited to
> saying that Jerusalem either is or is not the capital of Israel.

We are not. Wikidata is a repositum of statements. It can contain both a
statement that Jerusalem is the caital of Israel and another statement
that it is not. In a serious project both would exist and both had other
statements linked to them, stating who thinks so.

Ciao Henning


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-08-23 Thread Henning Schlottmann
On 22.08.2014 09:22, Erik Moeller wrote:
 
 - The MediaViewer rollout was very smooth until the deployments to
 German Wikipedia, English Wikipedia and Wikimedia Commons. There could
 be many reasons for that -- but it's a fact nonetheless. I do see
 little evidence that users in other communities are especially unhappy
 about the feature (leaving aside the politics of it now). I would be
 very curious what reason people do attribute that difference to,
 however (understanding that Commons is very different from the
 Wikipedia use case).

This may or may not correlate with a deep commitment to a) the licenses,
b) quality.

 - The criticism isn't just about that -- it's about a large number of
 mostly individually small issues. Generally, the idea that we
 effectively munge some of the metadata by displaying a
 machine-readable subset below the fold is viewed very negatively,
 because 1) it doesn't reflect all the available information, 2) it
 makes it harder for users to discover the File: page, and potentially
 edit it.

If it does not reflect the license information it is broken.

The license is paramount. We can not accept any kind of software that
hands out reuse information that does not display the photographer's
name and the license (with link to the license text).

We do not want a default setting, that does not show extensive
descriptions, map legends, image annotations and the like. All that is
content we created for the readers. You must not block our readers from
this content.

MV is broken. It is not ready to be deployed. Not by far. Take it back
and fix it.

In theory I can see a working MV. I can even imagine a working Visual
Editor, but am very skeptical about it. I can not imagine Flow to work,
ever. This one needs to be abandoned now.

Eric, your department has an abysmal record. You have wasted millions on
software that started with the wrong framework and is not working after
years and years of development. Please think about yourself, not about
the communities if you want to understand about the conflicts at hand.

Henning


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

2014-08-14 Thread Henning Schlottmann
On 12.08.2014 21:41, Magnus Manske wrote:
 On Tue, Aug 12, 2014 at 5:33 PM, Henning Schlottmann h.schlottm...@gmx.net
 wrote:

 This is serious. WMF really needs to appreciate the expertise of the
 author community and accept their experience a important and valid. If
 authors tell the WMF and particularly the devs, that a particular
 function is necessary, then the devs really, really need to think.

 
 I do agree with this. Visual Editor (which works much better these days)
 and MediaViewer are not aimed at the experienced editor. They aim to make
 the reader more comfortable, and try to ease the first steps into editing.
 Winning new editors has been deemed a priority, somewhat at the expense of
 WMF-made support for the power user. This is a judgement call the
 Foundation has to make.

I do not undersign that dichotomy between readers and authors. And I
certainly do not accept any claim, that the MWF know all about what
readers need to become authors, while the authors are ignorant about
that. The results of the millions of dollars, the WMF put into their
understanding of readers interest are less than sterling in this regard.

 A formal RfD must not be taken lightly, overruling it by creating a
 whole new user class, and crippling the elected admins is inpermissible.
 WMF has broken trust again and this time in a unprecedented way.

 
 As Erik pointed out, WMF had made it quite clear that they reserve the
 right to overrule the community in that specific matter, before the
 Meinungsbild was done. WMF then acted as announced, and refused to be
 hacked out of their own servers. An unfortunate escalation on both sides,
 but since they never promised to accept the Meinungsbild (quite the
 opposite!), it was not a breach of trust.

Frankly: I don't care the least, what Eric says. Of course the
Meinungsbild (RfD) at deWP was a vote of noconfidence after the previous
events at enWP. But the reaction by WMF was unprecedented and it was a
mistake. A serious one. It damaged the relation between the Community
and the WMF, it killed Jan's job and it made Rachel's job very difficult
if not untenable. To describe Eric's action I am tempted to use a
metaphor that includes black uniforms and heavy boots. But that would
not be appropriately written by a German to a German.

 Until this event, I thought the dev process to be broken, not just the
 communication around devs. But now I believe the conflict runs deeper.

 
 It points out an issue we (community and WMF) should discuss, in a more
 general sense. What should the decision process be for technical changes?
 When does the Foundation get precendence, and when should the community
 have the last word? What weight should small-scale votes of editors have?
 Should random polls be done, and included in such votes? Etc.
 
 The MediaViewer affair itself gets blown out of proportion IMO.

I agree that this is not just about the MediaViewer but about a general
pattern of behavior perceived by the community. The WMF's decision
making regarding software and skin development is broken. Its targets
are flawed, it is not properly communicated with the community, the
actual development processes result in incredibly crappy software that
gets rolled out non the less in pre-alpha states.

Do I have to list all the broken projects? Liquid feedback, article
feedback tool, image filter, visual editor, flow, the new thumb layout.

How do you explain that to donors by the way?

All of them show that the devs and the management level do not
understand the features of the existing solutions, particularly the well
established tools and sometimes work arounds, authors created over the
years to deal with the very basic MediaWiki. But understanding the
actual use of MediaWiki is paramount to improving it.

Ciao Henning


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

2014-08-12 Thread Henning Schlottmann
On 12.08.2014 16:57, Magnus Manske wrote:
 German Wikipedia had 1.1 billion page views in June [1]. ~300 votes (~2/3
 against MediaViewer) do not represent the readers, IMHO.

Claiming to speak for a perceived silent majority will not help you much
in this discussion.

There is a common pattern in the conflicts between WMF and several
communities over software developments during the last few years. As I
wrote two weeks ago to Rachel:

| Decision making seems to be focused on reader experience, including
| winning readers to become authors, but existing authors and their
| experience (in both meanings of the word) is ignored. Even by people |
like Eric, who once was a prolific author himself

| Authors see themselves as the single most important group in the
|Wikimedia universe. Without their content, there would be nothing: No
| readers, no fundraising banners, no donations, no employees, no
| foundation. On the other hand, WMF seems to see the readers (and
| donors) as their main target audience. Of course WMF knows, that all
| the projects need content and authors, but in my opinion most of them
| fail in appreciating the existing authors and focus too much on
| winning readers to become authors, by simplifying the entry.

This is serious. WMF really needs to appreciate the expertise of the
author community and accept their experience a important and valid. If
authors tell the WMF and particularly the devs, that a particular
function is necessary, then the devs really, really need to think.

If the community tells the devs, that a particular idea is a bad one, a
feature is too buggy to be rolled out (as default) or is unsuitable for
a project at all, this warrants more than just a cursory thought.

A formal RfD must not be taken lightly, overruling it by creating a
whole new user class, and crippling the elected admins is inpermissible.
WMF has broken trust again and this time in a unprecedented way.

Until this event, I thought the dev process to be broken, not just the
communication around devs. But now I believe the conflict runs deeper.

Henning
User: H-stt (admin on deWP and Commons)




___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe