Re: [Wikimedia-l] Endless drama around solutions to non-problems as misdirection

[Gerard Meijssen]

Hoi,
When you talk about respect, it can mean so many things and have different
implications.

When people argue like "the community this and that" I do not respect their
arguments. The community is often flat wrong and there is no mileage, quite
the contrary to respecting the "gravitas" of someone using it to strengthen
an argument. They either agree with a statement and make it their own or
the point is not made; a point that can be argued with that person.

When there is a need for change, a demonstrable need preferably a need
backed by numbers like the need for a discussion system that works on
mobiles that deny these numbers, the need for change. I do not respect the
arguments by people bemoaning the fact that they will lose their beloved
talk pages. The argument is made and, the argument is backed by numbers
that increasingly our readers and editors use mobiles and tablets. Ignoring
this is irresponsible. This is not a zero sum game.

That is not to say that I do not respect the people when they are not
making such an argument.

I pick my battles, I make the points I make personal and I am honest about
them. I make an effort to continuously stick to the point. When people are
unhappy about me strongly attacking what is so precious to them, they
forget that it is not about them. It is about what prevents us to support
all our users.

In all this I do not think that the WMF is shitting gold. I have my
favourite example of a UI issue that is not worthy of consideration because
"technically" it works. [1]
Thanks,
  GerardM

[1] http://ultimategerardm.blogspot.nl/2014/07/mediawiki-media-viewer.html

On 8 September 2014 06:02, Wil Sinclair  wrote:

> The way I see it, there is something each and every one of us can do
> to help with attrition right now with no interference from or
> dependencies on anyone else.
>
> We can treat each other with the respect that we all deserve. Before
> hitting send or Save Page, we can ask ourselves if we've said what we
> wanted to say in the least confrontational manner possible. Have we
> kept in mind that we're addressing real people and not 2 dimensional
> usernames? Have we considered how our points may be taken from a
> different perspective than our own?
>
> I commit to practicing respect to the best of my ability in all of my
> Wikimedia communications, right here and right now, for this entire
> list to see. Gerard, will you join me in this commitment? Will anyone
> else join me in this commitment?
>
> ,Wil
>
> On Sat, Sep 6, 2014 at 7:53 AM, Gerard Meijssen
>  wrote:
> > Hoi,
> > The lack of usability that is inherent in the current tools is enough to
> > drive me away from editing Wikipedia. At to this the atmosphere that is
> all
> > too often just not interested in anything but vested interests and you
> have
> > a cocktail that is powerful enough to have me respond to your challenge.
> > Our environment is long overdue on an update and, this is really hard to
> > do. I welcome the much anticipated editor and media viewer. Sure, it is
> not
> > the finished product yet but it has way more finesse then what we had
> > before.
> >
> > What distracts me most is the constant bickering that suggests that we
> are
> > not moving forward or that fails to appreciate the extend that we need
> > change in order to remain relevant with our content. We find that new
> > editors are mainly from a mobile environment (i include tablets here) and
> > they are NOT attached to the old ways some aim to have us stick to at all
> > costs.
> >
> > We need to change and our aim should be to remain relevant for the next
> > decennia.
> > Thanks,
> >   GerardM
> >
> >
> > On 6 September 2014 10:54, James Salsman  wrote:
> >
> >> Where does the idea that user interface changes to the system which
> >> has already produced the most monumental reference work in the history
> >> of humanity are going to help with its only actual problem, that
> >> people aren't sufficiently inclined to stick around and maintain it?
> >>
> >> If there was any evidence that VE or Media Viewer or Flow will make
> >> the projects more attractive to volunteers, I'm sure we would have
> >> heard it by now. But there isn't. Nor is there any evidence that any
> >> of the several Editor Engagement projects have made a dent in
> >> volunteer attrition rates, despite their success in encouraging tiny
> >> subsets of very new editors to contribute a few minutes more work.
> >>
> >> The present set of dramatic distractions from attention to the
> >> vanishing volunteer corps only highlights that Foundation leadership
> >> has no ability to focus on the only strategic goal they haven't
> >> achieved: retaining volunteers. Because it is so much easier to
> >> pretend that readers need WYSIWYG or a lightbox or can't figure out
> >> how to indent replies; since readership numbers aren't an actual
> >> problem (when mobile users are added to desktop pageviews) this
> >> guarantees the false appearance of success in

Re: [Wikimedia-l] To Flow or not to Flow

[Gerard Meijssen]

Hoi,
You missed the multiple discussion pages in all the "other" languages. They
are certainly as observant, as eloquent and they have different use cases
and issues as well.
Thanks,
 GerardM


On 8 September 2014 06:26, Wil Sinclair  wrote:

> I composed the following as part of a longer message, but I decided
> not to send it unless others were having similar issues since I'm on
> track to exceed my monthly allowance of posts here ;):
>
> "
> There's one thing in this discussion that troubles me greatly.
>
> We've got a treasure trove of information/feedback in this thread from
> some of the people who are most knowledgable about the software and
> the problems it's trying to solve. Are we sure we're capturing all of
> the take-aways somewhere? How about the unresolved concerns? Is
> anything getting lost in transient discussions here or elsewhere?
>
> I set out to answer this myself.
>
> First, I looked for the talk page on Flow. Here it is:
>
> https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow&action=history
> The first things to strike me are that it is very long, very active,
> very unstructured, and archived across 10 pages and counting. Hmmm.
> Same questions as above, applied to exponentially more threads.
>
> Next, I went to bugzilla:
>
> https://bugzilla.wikimedia.org/buglist.cgi?component=Flow&list_id=342315&product=MediaWiki&product=MediaWiki%20extensions&product=Wikimedia
> . Much more structured and captures some requirements in a workflow.
> Not so good for discussing higher-level issues, however. Moreover,
> that doesn't seem to be what the development team is keeping their
> backlog in. Off to trello. . .
>
> I'm an experienced development manager that has been evangelizing
> agile programming of all stripes since 2001, and it took my searching
> the Flow talk page and clicking on a specific task to figure out how
> to list the backlog in trello. I think this is the right link in case
> you're looking for it yourself:
> https://trello.com/b/HD0lBssr/flow-backlog. A lot of these items link
> back to bugzilla and to another Flow discussion page. . .
>
> . . .on the MediaWiki site conducted in Flow itself:
> https://www.mediawiki.org/wiki/Talk:Flow. I think I'll stop here,
> although there are more places where Flow is discussed, and I haven't
> even gotten in to the mainspace pages that are edited by the Wikimedia
> and MediaWiki developers to communicate outwards to the broader
> community.
> "
>
> The summary of the tl;dr version is that it seems like there are
> opportunities to improve the discussion of Flow, starting with
> conducting it in fewer places and adding all takeaways as requirements
> to a workflow we can all track. The next step would be a discussion
> around prioritizing these requirements. Has this been done for Flow
> with full community involvement? If not, I think the WMF should take
> the lead on this one and show the community that it has taken the
> lessons from the recent MV experience and other poorly received
> rollouts to heart.
>
> WMF, I appeal to you directly when I ask you to get us more involved,
> and, moreover, get us more invested in the success of Flow starting
> now by leading a discussion too many on this list and elsewhere have
> said hasn't happened and/or hasn't been heeded.
>
> ,Wil
>
> On Sun, Sep 7, 2014 at 7:28 PM, Craig Franklin
>  wrote:
> > Hi,
> >
> > Is there a page somewhere where I can see a detailed functional
> > specification of this product, showing how it'll work, what
> > functions/features it will include in it's MVP state, and such?  I know
> > about the page on Mediawiki ( https://www.mediawiki.org/wiki/Flow ) that
> > talks about things in generalities and answers some specific questions in
> > the FAQ, but I've not been able to locate any document that tells me
> > exactly what it will *do*.
> >
> > I have to confess that I'm not entirely confident that the rollout of
> Flow
> > will be any smoother than the rollout of Visual Editor or MediaViewer,
> > largely because I'm not entirely confident of what it is that I'm
> supposed
> > to be getting.  I'd be delighted to be corrected on this point if there
> is
> > something out there that I've missed.
> >
> > Cheers,
> > Craig
> >
> > On 6 September 2014 14:49, Erik Moeller  wrote:
> >
> >> Hi all,
> >>
> >> I'm breaking out this discussion about Flow/talk pages (apologies for
> >> repeatedly breaking the megathread, but this is a well-scoped subject
> >> which deserves its own thread).
> >>
> >> Fundamentally, there's one key question to answer for talk pages in
> >> Wikimedia projects: Do we want discussions to occur in document mode,
> >> or in a structured comment mode? All else flows from there (pun
> >> intended).
> >>
> >> == Document mode ==
> >>
> >> There are not many examples of document mode discussion systems beyond
> >> wikis. You sometimes see people use collaborative realtime editors as
> >> such, because people want to talk in the same space wher

Re: [Wikimedia-l] To Flow or not to Flow

[Gerard Meijssen]

Hoi,
There are two ways to look at the talk systems. It served us so far to some
extend. It has been considered in need of replacement for a long time and
consequently we have systems like Liquid Threads that are arguably at least
as good in many use cases and fail in others.

The other way to look at tit is to see it fail on what is becoming
increasingly the platform of our readers and our new editors; the mobile
and the tablet. On those platforms talk pages are a disaster, an utter
failure. This realisation that these types of devices are our future make
it imperative to move away from our talk pages as soon as possible.

We do not have the time to procrastinate and we do not have time for
continued deliberations of how nice it would be if we could do it all over
again. As it is, we have a team of developers working on Flow. They are
committed to consider the many use cases that exist in our community but in
the end, fixing those will increasingly become an exercise in diminishing
returns given the need to support our readers and editors on mobiles and
tablets. The cost is not in the time of the development team, it is not in
functionality we really want it is in supporting the growing percentage of
people that do NOT use computers.

The question to ask is: who do we do it for,
Thanks,
   GerardM


On 8 September 2014 06:13, Risker  wrote:

> On 7 September 2014 23:54, Marc A. Pelletier  wrote:
>
> > On 09/07/2014 01:57 AM, Diego Moya wrote:
> > > a major property of a document-centric architecture that is lost in a
> > > structured one is that it's open-ended, which means that end users can
> > > build new features and flows on top of it, without the need to request
> > the
> > > platform developers to build support for them (sometimes even without
> > > writing new software at all; new workflows can be designed and
> maintained
> > > purely through social convention).
> >
> > And yet, after over a decade of open-ended design through social
> > convention, the end result is...  our current talk pages.  Perhaps
> > another decade or two will be needed before that document-centric
> > architecture gives us a half-decent discussion system?
> >
> > Sorry if that sound snarky, but I have difficulty buying an argument
> > that the current system has the potential to suffice when it has
> > demonstrably already failed.  It does no good to have the hypothetical
> > capacity for a good system if, in practice, it's unusable.
> >
> > -- Marc
> >
> >
> I suppose the question really is, has it failed?  On what basis are we
> saying that our current discussion system is unusable?
>
> Simply put, I'd suggest that the problem isn't the system, it's the
> discussion process itself that has points of failure.  The replacement of
> actual discussion with templates is a point of failure, and that will not
> be improved by a change in the platform if all that happens is we use
> basically the same templates to have the same non-discussions.  Nothing in
> the technology, either document-based or open-ended, will change the nature
> of the discourse itself; rude people will still be rude, erudite people
> will still be erudite, and none of will change the snark on Jimbo Wales's
> talk page. A significant percentage of Wikimedians rarely use talk pages at
> all (and a goodly number of those identify as exopedians), but no evidence
> that the percentage of Wikimedians who eschew social interaction has
> changed significantly, or that those with a low level of contribution to
> discussion space are doing so because they find the *technology*
> unappealing.
>
> Risker/Anne
> ___
> 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,
> 
>
___
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] Feedback with Android on Commons

[Wil Sinclair]

I don't know what you mean by "entering an email", but when you add
something to a workflow like a bug system, it's pretty common that it
expects to be able to send you notifications about status changes,
etc.

I didn't experience any of the issues you mentioned on my Nexus 5
phone and Nexus 7 tablet. No crashes, no overwritten files, and
categories worked quite well with a string match list on search. I'm
new to selfies, so I took a few. On the off chance that anyone cares
what I look like :) here's one of them:
https://commons.wikimedia.org/wiki/File:Wil_Sinclair_Selfie.jpg

On the whole, I thought it was a great app, and I plan on using it for
more than uploading selfies soon. ;)

I did notice that audio files weren't handled correctly in the app
with the waiting wheel spinning endlessly, so I filed this bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70546

While I was playing around with it, I thought it would be cool if I
could record audio for immediate upload like the functionality for
taking and uploading a picture, so I added this bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70547

If you want to add your own issues, here's the place:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=Commons%20App

If it's not obvious enough already, I'm going through my experience
because I believe it's not just the WMF that needs to make an effort
if we expect our software to shine. If you just want to complain in to
the wind, I suppose posting to this list is one way to do it (tho I
think there are better, more specific lists to post to). If you are
serious about getting it fixed, you might have to do a bit more
footwork, but you're much more likely to make a difference and help
the developers help us.

Whenever someone complains about software on this list, I plan to go
to bugzilla and check whether a bug has been filed. If it hasn't, I
won't hesitate to call the complainer on it. Let's do our part, so the
developers can do theirs.

,Wil

On Sun, Sep 7, 2014 at 12:20 PM, Yann Forget  wrote:
> Hi,
>
> The first thing to fix is the reporting: if the user accepts
> reporting, you should really report the issue without asking to enter
> a mail or some information the user does not know. I am fine playing a
> guinea pig if it is useful, but here I can't even report anything.
>
> Regards,
>
> Yann
>
> 2014-09-07 11:15 GMT+05:30 Wil Sinclair :
>> Hi Yann, most of the issues you're describing sound like straight-up bugs.
>>
>> When it comes to Android, it helps to know about issues that affect
>> some models but may not come up on the model/version that the
>> developer is using for testing. I think it's safe to say that the S4
>> is a '''must work''' Android platform. Some of the open bugs already
>> filed might apply; if there are closed bugs that aren't fixed on S4,
>> they may need to be reopened with a comment. And some of the issues
>> you've mentioned don't seem to be captured at all:
>>
>> https://bugzilla.wikimedia.org/buglist.cgi?component=Android&list_id=342313&product=Commons%20App
>>
>> IMO, we should be as diligent as possible when it comes to filing bugs
>> in the bug tracker. There are lots of concerns about the quality of
>> software that have been expressed here. Whether you happen to be
>> technical or not, this is one of the best ways each and every one of
>> us can do our part to build better software for our community.
>>
>> Now that I've preached it, it's off to practice for me. I'm
>> downloading the commons app on both of my Nexus devices now and will
>> file any bugs I see. If anyone would like to join me and Yann, you can
>> install the app on your Android device here:
>>
>> https://play.google.com/store/apps/details?id=org.wikimedia.commons&hl=en
>>
>> ,Wil
>>
>> On Sat, Sep 6, 2014 at 11:54 AM, Yann Forget  wrote:
>>> Hi,
>>>
>>> I am not a mobile user. So for the first time, I used the Mobile App
>>> on a Samsung S4 to upload a few pictures. I am quite disappointed, to
>>> say the least. I stopped counting how many times the application
>>> crashed while uploading just a few pictures. Then in reviewing my
>>> uploads, I can't see the description or the license, the field is
>>> blank. Then I discovered that the Application does not check if the
>>> name already exists, and uploads over the old file without warning.
>>> Luckily I didn't upload over someone else files. Then the categories I
>>> choose were not included, and also no warning there. It is a bit less
>>> bad on a tablet, where I can read the description and the license, but
>>> I can't add any category. I wonder how a software in such a bad
>>> condition gets deployed... Now it is much easier than on the desktop,
>>> and I understand why we get so many useless pictures from mobile
>>> uploads.
>>>
>>> https://commons.wikimedia.org/wiki/Commons_talk:Mobile_app#Feedback_on_Android
>>>
>>> Regards,
>>>
>>> Yann
>
> ___
> Wikimedia-l mailing list, guidelines at: 
> https://

Re: [Wikimedia-l] To Flow or not to Flow

[Risker]

On 8 September 2014 00:46, John Mark Vandenberg  wrote:




> .  e.g. once it is
> beta quality, I am sure Jimmy Wales will want it enabled on his user
> talk page, which would increase exposure to, and acceptance of, Flow.
>
>

...or possibly far less complaining on his page.  :-)

Risker/Anne
___
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] To Flow or not to Flow

[John Mark Vandenberg]

On Mon, Sep 8, 2014 at 1:54 PM, Marc A. Pelletier  wrote:
> On 09/07/2014 01:57 AM, Diego Moya wrote:
>> a major property of a document-centric architecture that is lost in a
>> structured one is that it's open-ended, which means that end users can
>> build new features and flows on top of it, without the need to request the
>> platform developers to build support for them (sometimes even without
>> writing new software at all; new workflows can be designed and maintained
>> purely through social convention).
>
> And yet, after over a decade of open-ended design through social
> convention, the end result is...  our current talk pages.  Perhaps
> another decade or two will be needed before that document-centric
> architecture gives us a half-decent discussion system?

Or maybe it will take a decade to deliver a discussion-centric system
that meets the needs of our community to replace the document-centric
discussion system we currently have.

> Sorry if that sound snarky, but I have difficulty buying an argument
> that the current system has the potential to suffice when it has
> demonstrably already failed.  It does no good to have the hypothetical
> capacity for a good system if, in practice, it's unusable.

While it may not be everybody's dream system, talk pages are quite
usable, as demonstrated by a lot of people using them every single
day.

I am all for the addition of a discussion system, effectively the next
iteration of Liquid Threads, but it worries me to see the *deployment*
objectives are already articulated in annual plans to be complete
replacement of all talk pages in 2015.

This potential problematic deploy could be very easily de-escalated by
a WMF decision that Flow will not be forcibly deployed onto an
unwilling project, and can be deployed per-page.  If it is good
software, the projects will *ask* for it to be deployed, like they did
with LiquidThreads, and users will want to use it on their user talk
even if the wider community isnt ready to migrate.  e.g. once it is
beta quality, I am sure Jimmy Wales will want it enabled on his user
talk page, which would increase exposure to, and acceptance of, Flow.

-- 
John Vandenberg

___
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] Endless drama around solutions to non-problems as misdirection

[Gerard Meijssen]

Hoi,
I hardly ever write a Wikipedia article because there are too many
showstoppers as far as I am concerned. The reasons for me are that the
policies involved are so overly complicated that I first consult a friend
about my plan for an article and its feasibility. The second reason is the
large amount of template hell that I am supposed to overcome that are
neither intuitive nor straight forward. Finally there are the button
warriors; they have their finger ready to destroy. Once they determine that
it is "not good enough" they expect you to do better or else and understand
the overly complicated processes that may save your work. It includes
making sense out of arcane widely distributed lore and templates that exist
in so many guises, mostly undocumented or not readily accessible.

Really I prefer not to write wikitext for all those reasons.

A more intuitive interface that removes all the little empires and makes
for a more reasoned understanding of what is needed in skills and
understanding will help a lot. The point I make about a new interface is
mostly that the current interface does not work on mobiles and tablets.
Given the work that I do (Wikidata) I mostly look at sources. This is our
future.
Thanks,
  Gerard

On 8 September 2014 03:07, David Goodman  wrote:

> Gerald, are you   saying that you personally   find the effort involved in
> editing wikitext or adding  media  disproportionate , or that there are
> people who would like to contribute content who find it excessive, but
> would find it effective with a more intuitive interface?  The first I
> doubt; the second will be true of any interface.
>
> DGG
>
> On Sat, Sep 6, 2014 at 10:53 AM, Gerard Meijssen <
> gerard.meijs...@gmail.com>
> wrote:
>
> > Hoi,
> > The lack of usability that is inherent in the current tools is enough to
> > drive me away from editing Wikipedia. At to this the atmosphere that is
> all
> > too often just not interested in anything but vested interests and you
> have
> > a cocktail that is powerful enough to have me respond to your challenge.
> > Our environment is long overdue on an update and, this is really hard to
> > do. I welcome the much anticipated editor and media viewer. Sure, it is
> not
> > the finished product yet but it has way more finesse then what we had
> > before.
> >
> > What distracts me most is the constant bickering that suggests that we
> are
> > not moving forward or that fails to appreciate the extend that we need
> > change in order to remain relevant with our content. We find that new
> > editors are mainly from a mobile environment (i include tablets here) and
> > they are NOT attached to the old ways some aim to have us stick to at all
> > costs.
> >
> > We need to change and our aim should be to remain relevant for the next
> > decennia.
> > Thanks,
> >   GerardM
> >
> >
> > On 6 September 2014 10:54, James Salsman  wrote:
> >
> > > Where does the idea that user interface changes to the system which
> > > has already produced the most monumental reference work in the history
> > > of humanity are going to help with its only actual problem, that
> > > people aren't sufficiently inclined to stick around and maintain it?
> > >
> > > If there was any evidence that VE or Media Viewer or Flow will make
> > > the projects more attractive to volunteers, I'm sure we would have
> > > heard it by now. But there isn't. Nor is there any evidence that any
> > > of the several Editor Engagement projects have made a dent in
> > > volunteer attrition rates, despite their success in encouraging tiny
> > > subsets of very new editors to contribute a few minutes more work.
> > >
> > > The present set of dramatic distractions from attention to the
> > > vanishing volunteer corps only highlights that Foundation leadership
> > > has no ability to focus on the only strategic goal they haven't
> > > achieved: retaining volunteers. Because it is so much easier to
> > > pretend that readers need WYSIWYG or a lightbox or can't figure out
> > > how to indent replies; since readership numbers aren't an actual
> > > problem (when mobile users are added to desktop pageviews) this
> > > guarantees the false appearance of success in the eyes of everyone who
> > > doesn't see through the transparent cop-out. Where is the evidence
> > > that the status quo user interface from 2005 would not have done just
> > > as well in every measurable aspect of movement success?
> > >
> > > Steven Walling wrote:
> > > >...
> > > > We practically can't and don't take on initiatives that directly
> > > > try to provide more free time or money to editors
> > >
> > > That is absolutely false. Individual Engagement Grants have recently
> > > been proven to be substantially more cost-effective in achieving the
> > > Foundation's stated goals than any other form of grant spending, on a
> > > per-dollar basis. Is there any evidence that any Foundation
> > > engineering effort of the past five years has done as well? I haven't
> >

Re: [Wikimedia-l] To Flow or not to Flow

[Wil Sinclair]

I composed the following as part of a longer message, but I decided
not to send it unless others were having similar issues since I'm on
track to exceed my monthly allowance of posts here ;):

"
There's one thing in this discussion that troubles me greatly.

We've got a treasure trove of information/feedback in this thread from
some of the people who are most knowledgable about the software and
the problems it's trying to solve. Are we sure we're capturing all of
the take-aways somewhere? How about the unresolved concerns? Is
anything getting lost in transient discussions here or elsewhere?

I set out to answer this myself.

First, I looked for the talk page on Flow. Here it is:
https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow&action=history
The first things to strike me are that it is very long, very active,
very unstructured, and archived across 10 pages and counting. Hmmm.
Same questions as above, applied to exponentially more threads.

Next, I went to bugzilla:
https://bugzilla.wikimedia.org/buglist.cgi?component=Flow&list_id=342315&product=MediaWiki&product=MediaWiki%20extensions&product=Wikimedia
. Much more structured and captures some requirements in a workflow.
Not so good for discussing higher-level issues, however. Moreover,
that doesn't seem to be what the development team is keeping their
backlog in. Off to trello. . .

I'm an experienced development manager that has been evangelizing
agile programming of all stripes since 2001, and it took my searching
the Flow talk page and clicking on a specific task to figure out how
to list the backlog in trello. I think this is the right link in case
you're looking for it yourself:
https://trello.com/b/HD0lBssr/flow-backlog. A lot of these items link
back to bugzilla and to another Flow discussion page. . .

. . .on the MediaWiki site conducted in Flow itself:
https://www.mediawiki.org/wiki/Talk:Flow. I think I'll stop here,
although there are more places where Flow is discussed, and I haven't
even gotten in to the mainspace pages that are edited by the Wikimedia
and MediaWiki developers to communicate outwards to the broader
community.
"

The summary of the tl;dr version is that it seems like there are
opportunities to improve the discussion of Flow, starting with
conducting it in fewer places and adding all takeaways as requirements
to a workflow we can all track. The next step would be a discussion
around prioritizing these requirements. Has this been done for Flow
with full community involvement? If not, I think the WMF should take
the lead on this one and show the community that it has taken the
lessons from the recent MV experience and other poorly received
rollouts to heart.

WMF, I appeal to you directly when I ask you to get us more involved,
and, moreover, get us more invested in the success of Flow starting
now by leading a discussion too many on this list and elsewhere have
said hasn't happened and/or hasn't been heeded.

,Wil

On Sun, Sep 7, 2014 at 7:28 PM, Craig Franklin
 wrote:
> Hi,
>
> Is there a page somewhere where I can see a detailed functional
> specification of this product, showing how it'll work, what
> functions/features it will include in it's MVP state, and such?  I know
> about the page on Mediawiki ( https://www.mediawiki.org/wiki/Flow ) that
> talks about things in generalities and answers some specific questions in
> the FAQ, but I've not been able to locate any document that tells me
> exactly what it will *do*.
>
> I have to confess that I'm not entirely confident that the rollout of Flow
> will be any smoother than the rollout of Visual Editor or MediaViewer,
> largely because I'm not entirely confident of what it is that I'm supposed
> to be getting.  I'd be delighted to be corrected on this point if there is
> something out there that I've missed.
>
> Cheers,
> Craig
>
> On 6 September 2014 14:49, Erik Moeller  wrote:
>
>> Hi all,
>>
>> I'm breaking out this discussion about Flow/talk pages (apologies for
>> repeatedly breaking the megathread, but this is a well-scoped subject
>> which deserves its own thread).
>>
>> Fundamentally, there's one key question to answer for talk pages in
>> Wikimedia projects: Do we want discussions to occur in document mode,
>> or in a structured comment mode? All else flows from there (pun
>> intended).
>>
>> == Document mode ==
>>
>> There are not many examples of document mode discussion systems beyond
>> wikis. You sometimes see people use collaborative realtime editors as
>> such, because people want to talk in the same space where they work,
>> but Google Docs provided alternatives (a pretty powerful
>> comments/margin system and built-in chat) early on, for example.
>>
>> The current talk page system is a document mode system. Individual
>> comments have unclear boundaries (a single transaction can result in
>> multiple comments, signed or unsigned; indentation levels are
>> unpredictable and often inconsistent). All the joys and pain points of
>> working on the sam

Re: [Wikimedia-l] To Flow or not to Flow

[Todd Allen]

On Sun, Sep 7, 2014 at 9:54 PM, Marc A. Pelletier  wrote:

> On 09/07/2014 01:57 AM, Diego Moya wrote:
> > a major property of a document-centric architecture that is lost in a
> > structured one is that it's open-ended, which means that end users can
> > build new features and flows on top of it, without the need to request
> the
> > platform developers to build support for them (sometimes even without
> > writing new software at all; new workflows can be designed and maintained
> > purely through social convention).
>
> And yet, after over a decade of open-ended design through social
> convention, the end result is...  our current talk pages.  Perhaps
> another decade or two will be needed before that document-centric
> architecture gives us a half-decent discussion system?
>

I don't see talk pages as not being a half-decent discussion system. They
support a lot more functionality than simple threaded discussion, so
forum-style or social media-style software won't work for them. They
provide a flexible system that allows them to serve the purpose of hosting
discussions as well as a significant number of other functions.


>
> Sorry if that sound snarky, but I have difficulty buying an argument
> that the current system has the potential to suffice when it has
> demonstrably already failed.


You said demonstrably, so I'm going to ask you to demonstrate it. What
basis do you have for saying it's failed?


> It does no good to have the hypothetical
> capacity for a good system if, in practice, it's unusable.
>

Sure, that statement is true, but it's irrelevant here given that a system
used thousands upon thousands of times a day can hardly be called unusable.

Todd
___
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] To Flow or not to Flow

[Risker]

On 7 September 2014 23:54, Marc A. Pelletier  wrote:

> On 09/07/2014 01:57 AM, Diego Moya wrote:
> > a major property of a document-centric architecture that is lost in a
> > structured one is that it's open-ended, which means that end users can
> > build new features and flows on top of it, without the need to request
> the
> > platform developers to build support for them (sometimes even without
> > writing new software at all; new workflows can be designed and maintained
> > purely through social convention).
>
> And yet, after over a decade of open-ended design through social
> convention, the end result is...  our current talk pages.  Perhaps
> another decade or two will be needed before that document-centric
> architecture gives us a half-decent discussion system?
>
> Sorry if that sound snarky, but I have difficulty buying an argument
> that the current system has the potential to suffice when it has
> demonstrably already failed.  It does no good to have the hypothetical
> capacity for a good system if, in practice, it's unusable.
>
> -- Marc
>
>
I suppose the question really is, has it failed?  On what basis are we
saying that our current discussion system is unusable?

Simply put, I'd suggest that the problem isn't the system, it's the
discussion process itself that has points of failure.  The replacement of
actual discussion with templates is a point of failure, and that will not
be improved by a change in the platform if all that happens is we use
basically the same templates to have the same non-discussions.  Nothing in
the technology, either document-based or open-ended, will change the nature
of the discourse itself; rude people will still be rude, erudite people
will still be erudite, and none of will change the snark on Jimbo Wales's
talk page. A significant percentage of Wikimedians rarely use talk pages at
all (and a goodly number of those identify as exopedians), but no evidence
that the percentage of Wikimedians who eschew social interaction has
changed significantly, or that those with a low level of contribution to
discussion space are doing so because they find the *technology*
unappealing.

Risker/Anne
___
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] Endless drama around solutions to non-problems as misdirection

[Wil Sinclair]

The way I see it, there is something each and every one of us can do
to help with attrition right now with no interference from or
dependencies on anyone else.

We can treat each other with the respect that we all deserve. Before
hitting send or Save Page, we can ask ourselves if we've said what we
wanted to say in the least confrontational manner possible. Have we
kept in mind that we're addressing real people and not 2 dimensional
usernames? Have we considered how our points may be taken from a
different perspective than our own?

I commit to practicing respect to the best of my ability in all of my
Wikimedia communications, right here and right now, for this entire
list to see. Gerard, will you join me in this commitment? Will anyone
else join me in this commitment?

,Wil

On Sat, Sep 6, 2014 at 7:53 AM, Gerard Meijssen
 wrote:
> Hoi,
> The lack of usability that is inherent in the current tools is enough to
> drive me away from editing Wikipedia. At to this the atmosphere that is all
> too often just not interested in anything but vested interests and you have
> a cocktail that is powerful enough to have me respond to your challenge.
> Our environment is long overdue on an update and, this is really hard to
> do. I welcome the much anticipated editor and media viewer. Sure, it is not
> the finished product yet but it has way more finesse then what we had
> before.
>
> What distracts me most is the constant bickering that suggests that we are
> not moving forward or that fails to appreciate the extend that we need
> change in order to remain relevant with our content. We find that new
> editors are mainly from a mobile environment (i include tablets here) and
> they are NOT attached to the old ways some aim to have us stick to at all
> costs.
>
> We need to change and our aim should be to remain relevant for the next
> decennia.
> Thanks,
>   GerardM
>
>
> On 6 September 2014 10:54, James Salsman  wrote:
>
>> Where does the idea that user interface changes to the system which
>> has already produced the most monumental reference work in the history
>> of humanity are going to help with its only actual problem, that
>> people aren't sufficiently inclined to stick around and maintain it?
>>
>> If there was any evidence that VE or Media Viewer or Flow will make
>> the projects more attractive to volunteers, I'm sure we would have
>> heard it by now. But there isn't. Nor is there any evidence that any
>> of the several Editor Engagement projects have made a dent in
>> volunteer attrition rates, despite their success in encouraging tiny
>> subsets of very new editors to contribute a few minutes more work.
>>
>> The present set of dramatic distractions from attention to the
>> vanishing volunteer corps only highlights that Foundation leadership
>> has no ability to focus on the only strategic goal they haven't
>> achieved: retaining volunteers. Because it is so much easier to
>> pretend that readers need WYSIWYG or a lightbox or can't figure out
>> how to indent replies; since readership numbers aren't an actual
>> problem (when mobile users are added to desktop pageviews) this
>> guarantees the false appearance of success in the eyes of everyone who
>> doesn't see through the transparent cop-out. Where is the evidence
>> that the status quo user interface from 2005 would not have done just
>> as well in every measurable aspect of movement success?
>>
>> Steven Walling wrote:
>> >...
>> > We practically can't and don't take on initiatives that directly
>> > try to provide more free time or money to editors
>>
>> That is absolutely false. Individual Engagement Grants have recently
>> been proven to be substantially more cost-effective in achieving the
>> Foundation's stated goals than any other form of grant spending, on a
>> per-dollar basis. Is there any evidence that any Foundation
>> engineering effort of the past five years has done as well? I haven't
>> seen any.
>>
>> When the Foundation spends on copyright advocacy, those initiatives
>> directly try to provide more economic empowerment to the small
>> fraction of contributors who stand to benefit from whatever additional
>> government documents or panorama images they hope to free up. But
>> volunteers who want to update information on the side effects of
>> commonly prescribed drugs get nothing.
>>
>> When the Foundation spends on attempts to oppose the Trans Pacific
>> Partnership, those initiatives directly try to provide more free time
>> and money to the small subset of editors threatened by lengthening of
>> copyright terms. But editors who want to help translate introductory
>> material foundational to engineering skills literacy get nothing.
>>
>> Who at the Foundation bears the responsibility for deciding which of
>> initiatives that might benefit the real needs of vanishing volunteers
>> are funded, and why aren't they held accountable for their record
>> since 2007?
>>
>> ___
>> Wikimedia-l

Re: [Wikimedia-l] To Flow or not to Flow

[Marc A. Pelletier]

On 09/07/2014 01:57 AM, Diego Moya wrote:
> a major property of a document-centric architecture that is lost in a
> structured one is that it's open-ended, which means that end users can
> build new features and flows on top of it, without the need to request the
> platform developers to build support for them (sometimes even without
> writing new software at all; new workflows can be designed and maintained
> purely through social convention).

And yet, after over a decade of open-ended design through social
convention, the end result is...  our current talk pages.  Perhaps
another decade or two will be needed before that document-centric
architecture gives us a half-decent discussion system?

Sorry if that sound snarky, but I have difficulty buying an argument
that the current system has the potential to suffice when it has
demonstrably already failed.  It does no good to have the hypothetical
capacity for a good system if, in practice, it's unusable.

-- Marc


___
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] To Flow or not to Flow

[Wil Sinclair]

Let me begin with this: my preferences lie far closer to yours,
Gerard, than Diego's. I believe that we have a document oriented
system that works well for stuff like encyclopedic content. But I
think that we should be conducting our discussions in a discussion
oriented system. That doesn't necessarily mean more structure- after
all, Wikipedia pages are almost always highly structured documents-
but it certainly requires '''different''' structure that might be
enforced by software as opposed to editorial convention.

> The central point  Diego made starts from is that the current broken system
> has a POTENTIAL for unstructured, unaccountable changes by whomever.
>
> You do not build on a fundament that is collapsing as it is. A system that
> is manifestly broken particularly on the one platform where our new users
> are; mobile.

I think Diego has a great point. By relying on software to enforce
structure in our discussions, we will rely more on the developers.
Let's take something that we all have a stake in as an example. In the
beginning, there will be inevitably be bugs as the system is rolled
out, and we will rely on the developers to fix them. Without the
flexibility of our document oriented system, there may be no
workarounds. That is something that may be mitigated with more
flexibility built in to the system.

Diego touches on the need for flexibility within the discussion for
many use cases, and I don't consider any of his requirements mutually
exclusive with a discussion oriented system, as such. He seems to
believe that we haven't held sufficient discussion on critical issues
like the right tradeoff between flexibility for editors and structure
for discussions. This sentiment has been expressed by several
Wikipedians in this forum.

Without broad consensus that this discussion has been held, and the
WMF has turned legitimate and sensible community needs and desires in
to Flow requirements, Flow will not succeed. If Diego's sentiment is
shared by a significant contingent of Wikipedians, we need to back up
and do this right. No biggies. It's far more important to have the
community invested in the success of Flow than to work towards
deadlines. If we're concerned about getting this done soon for use
cases such as those for mobile, we can accelerate the schedule as a
community by helping the WMF. There is no shortage of opportunities to
help at all levels of technical expertise.

> If we are to take arguments seriously, please explain why we should in this
> instance. If dismissing such ideas makes him go away AFTER it has been
> explained why the arguments do not wash.. Well, the best that can be said
> is that it makes the conversation easier, it does not change the quality of
> the arguments at all.

Even if I were to disagree with Diego on certain issues, I won't be
dismissing his ideas. Not because I want to recruit him as some sort
of ally for the next battle. And not because dismissing them will not
make these ideas go away, tho that is a very good reason not to
dismiss them. I won't be dismissing them because Diego is a thoughtful
Wikipedian, and all Wikipedians deserve respect and a chance to be
heard out.

As a post script, I see that Diego wrote a thorough and de-escalating
response. Huge +1 from me on that score. And then he did something
that only the strongest of souls seem to be able to do: he apologized
publicly for something he felt he could have done better. Diego, you
have my deepest respect, and please keep on keeping on in this forum
and elsewhere.

,Wil

___
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] To Flow or not to Flow

[Craig Franklin]

Hi,

Is there a page somewhere where I can see a detailed functional
specification of this product, showing how it'll work, what
functions/features it will include in it's MVP state, and such?  I know
about the page on Mediawiki ( https://www.mediawiki.org/wiki/Flow ) that
talks about things in generalities and answers some specific questions in
the FAQ, but I've not been able to locate any document that tells me
exactly what it will *do*.

I have to confess that I'm not entirely confident that the rollout of Flow
will be any smoother than the rollout of Visual Editor or MediaViewer,
largely because I'm not entirely confident of what it is that I'm supposed
to be getting.  I'd be delighted to be corrected on this point if there is
something out there that I've missed.

Cheers,
Craig

On 6 September 2014 14:49, Erik Moeller  wrote:

> Hi all,
>
> I'm breaking out this discussion about Flow/talk pages (apologies for
> repeatedly breaking the megathread, but this is a well-scoped subject
> which deserves its own thread).
>
> Fundamentally, there's one key question to answer for talk pages in
> Wikimedia projects: Do we want discussions to occur in document mode,
> or in a structured comment mode? All else flows from there (pun
> intended).
>
> == Document mode ==
>
> There are not many examples of document mode discussion systems beyond
> wikis. You sometimes see people use collaborative realtime editors as
> such, because people want to talk in the same space where they work,
> but Google Docs provided alternatives (a pretty powerful
> comments/margin system and built-in chat) early on, for example.
>
> The current talk page system is a document mode system. Individual
> comments have unclear boundaries (a single transaction can result in
> multiple comments, signed or unsigned; indentation levels are
> unpredictable and often inconsistent). All the joys and pain points of
> working on the same document are present (a heavily trafficked talk
> page will see many edit conflicts). You can't easily show comments in
> multiple contexts (cross-wiki, via email, as a notification, etc.)
> because of the boundary problem.
>
> You could try to make a document mode system work better. On the basis
> of wikitext, you can do some very basic things, like the "new section"
> link I added to MediaWiki back in July 2003 [1], when I wrote: "This
> feature could also be the first stage of a more sophisticated
> discussion system, where the next stage would be auto-appending
> signatures and providing a 'Reply to this' link after each comment."
>
> But due to the aforementioned unpredictability, even making a "reply"
> link work consistently (and do the right thing) is non-trivial. You
> can get some of the way there, and the Wikipedia Teahouse actually has
> a gadget, written by Andrew Garrett (more on him below) that does
> precisely that.
>
> https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
>
> Note the "Join this discussion" link. It does give you a pop-up, and
> posts the comment for you in the right place, with indentation (it
> does not auto-sign, but instead tries to teach users the signature
> habit which they'll need to use on other talk pages).
>
> It may be worth doing more research and development on this, to see
> just how far we can get without changing the fundamentals, since a
> wholly new system may still be years out for wide use. However, there
> are inherent limitations due to the lack of a predictable and
> consistent structure.
>
> You could go further down the road of a document mode or hybrid
> system, but IMO not without introducing fully predictable comment
> markers (think Bla ~~~) -- which would
> pollute the wikitext, be fragile (e.g. accidental or deliberate
> corruption of identifiers), and probably be considered unacceptable in
> a system that still supports unlimited wikitext editing for those
> reasons.
>
> == Structured ==
>
> I personally gave up on patchwork on top of talk pages about 10 years
> ago. The advantages of having comments clearly identified as such are
> many:
>
> - Display comments in arbitrary order, arbitrary threading style
> - Search comments across date ranges
> - Search comments by author
> - Track comments as comments, not as diffs
> - Monitor changes at any part of a comment thread
> - Display comments independent of a given document (e.g. email,
> cross-wiki, etc.)
> - Display comment metadata in different formats easily (e.g. timestamps)
> - Update author names after a username change without having to update
> documents
> - Enables third parties to build new UIs (think Wikiwand for comments)
> more easily
> - Ability to tag/categorize individual comments/threads
> - and more.
>
> I identified some of these reasons when I wrote the proposal for
> LiquidThreads in October 2004 [2]. At that point, the Wikimedia
> Foundation had 0 employees, and this was too large an effort to likely
> get traction just from ad hoc volunteering. So after some time, I
> managed

Re: [Wikimedia-l] Endless drama around solutions to non-problems as misdirection

[Steven Walling]

On Sat, Sep 6, 2014 at 1:54 AM, James Salsman  wrote:

> Steven Walling wrote:
> >...
> > We practically can't and don't take on initiatives that directly
> > try to provide more free time or money to editors
>
> That is absolutely false. Individual Engagement Grants have recently
> been proven to be substantially more cost-effective in achieving the
> Foundation's stated goals than any other form of grant spending, on a
> per-dollar basis. Is there any evidence that any Foundation
> engineering effort of the past five years has done as well? I haven't
> seen any.
>

Individual engagement grants are not a monetary reward for contributing
content. They are, just like larger programs internally at WMF or in a
chapter, intended to produce another outcome which has a wider and more
sustainable impact. Suggesting that the success of IEG is evidence we
should/could just pay editors directly in some way is quite the stretch.

Providing cash on a large scale to motivate contributors has diminishing
returns as an alternative strategy to usability improvements, when you
consider that the software platform which enables content creation will
continue to show its age. Even if we lived in a parallel universe where
every editor of Wikipedia was paid for their work, we'd still need to
continually improve the platform they used to make the encyclopedia.

It's interesting you bring up IEG though. If you're not talking about 1:1
alternatives to software improvements, but instead you want us to consider
potentially complementary new ideas to motivate people to edit... go for
it. No one can deny the positive impact of initiatives like The Core
Contest on English Wikipedia (I've been a contestant myself).[1] Piloting a
larger scale set of contests where there are rewards or prizes for winners
might be a pretty cool IEG project that could prove your theory.

1. https://en.wikipedia.org/wiki/Wikipedia:The_Core_Contest
___
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] Endless drama around solutions to non-problems as misdirection

[David Goodman]

Gerald, are you   saying that you personally   find the effort involved in
editing wikitext or adding  media  disproportionate , or that there are
people who would like to contribute content who find it excessive, but
would find it effective with a more intuitive interface?  The first I
doubt; the second will be true of any interface.

DGG

On Sat, Sep 6, 2014 at 10:53 AM, Gerard Meijssen 
wrote:

> Hoi,
> The lack of usability that is inherent in the current tools is enough to
> drive me away from editing Wikipedia. At to this the atmosphere that is all
> too often just not interested in anything but vested interests and you have
> a cocktail that is powerful enough to have me respond to your challenge.
> Our environment is long overdue on an update and, this is really hard to
> do. I welcome the much anticipated editor and media viewer. Sure, it is not
> the finished product yet but it has way more finesse then what we had
> before.
>
> What distracts me most is the constant bickering that suggests that we are
> not moving forward or that fails to appreciate the extend that we need
> change in order to remain relevant with our content. We find that new
> editors are mainly from a mobile environment (i include tablets here) and
> they are NOT attached to the old ways some aim to have us stick to at all
> costs.
>
> We need to change and our aim should be to remain relevant for the next
> decennia.
> Thanks,
>   GerardM
>
>
> On 6 September 2014 10:54, James Salsman  wrote:
>
> > Where does the idea that user interface changes to the system which
> > has already produced the most monumental reference work in the history
> > of humanity are going to help with its only actual problem, that
> > people aren't sufficiently inclined to stick around and maintain it?
> >
> > If there was any evidence that VE or Media Viewer or Flow will make
> > the projects more attractive to volunteers, I'm sure we would have
> > heard it by now. But there isn't. Nor is there any evidence that any
> > of the several Editor Engagement projects have made a dent in
> > volunteer attrition rates, despite their success in encouraging tiny
> > subsets of very new editors to contribute a few minutes more work.
> >
> > The present set of dramatic distractions from attention to the
> > vanishing volunteer corps only highlights that Foundation leadership
> > has no ability to focus on the only strategic goal they haven't
> > achieved: retaining volunteers. Because it is so much easier to
> > pretend that readers need WYSIWYG or a lightbox or can't figure out
> > how to indent replies; since readership numbers aren't an actual
> > problem (when mobile users are added to desktop pageviews) this
> > guarantees the false appearance of success in the eyes of everyone who
> > doesn't see through the transparent cop-out. Where is the evidence
> > that the status quo user interface from 2005 would not have done just
> > as well in every measurable aspect of movement success?
> >
> > Steven Walling wrote:
> > >...
> > > We practically can't and don't take on initiatives that directly
> > > try to provide more free time or money to editors
> >
> > That is absolutely false. Individual Engagement Grants have recently
> > been proven to be substantially more cost-effective in achieving the
> > Foundation's stated goals than any other form of grant spending, on a
> > per-dollar basis. Is there any evidence that any Foundation
> > engineering effort of the past five years has done as well? I haven't
> > seen any.
> >
> > When the Foundation spends on copyright advocacy, those initiatives
> > directly try to provide more economic empowerment to the small
> > fraction of contributors who stand to benefit from whatever additional
> > government documents or panorama images they hope to free up. But
> > volunteers who want to update information on the side effects of
> > commonly prescribed drugs get nothing.
> >
> > When the Foundation spends on attempts to oppose the Trans Pacific
> > Partnership, those initiatives directly try to provide more free time
> > and money to the small subset of editors threatened by lengthening of
> > copyright terms. But editors who want to help translate introductory
> > material foundational to engineering skills literacy get nothing.
> >
> > Who at the Foundation bears the responsibility for deciding which of
> > initiatives that might benefit the real needs of vanishing volunteers
> > are funded, and why aren't they held accountable for their record
> > since 2007?
> >
> > ___
> > 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,
> > 
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wik

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

[Diego Moya]

On 09/06/2014 17:06 PM, Marc A. Pelletier wrote:

>On 09/06/2014 12:34 PM, Isarra Yos wrote:
>> if the designers do not even understand the basic principles behind a
>> wiki, how can what is developed possibly suit our needs?
>
>You're starting from the presumption that, for some unexplained reason,
>collaborative discussion benefits from being a wiki (as opposed to, you
>know, the actual content).

Wikipedia has been built using that platform. I'd say that's a very good
reason to trust that the model is at least capable. :-)



>Very many people, myself included, believe that a wiki page is an
>*atrocious* medium for discussion.

Sure, and I agree there are many way to improve how users are
engaged into discussion and to keep it manageable. But what is
missing from this conversation is the point that Wikipedia talk
space is not *merely* a medium for discussion: there are other vital
roles that may be hindered by a radical focus on conversation:

tl;dr version:  there are times and places that Wikipedia discussion
system needs to be a Microsoft OneNote, and Flow is building us
a Twitter (minus the 140 characters limit).


- The talk space has a strong expectation that it serves as an
archive of all decisions taken in building the articles, i.e. to
show how the sausages are made. The disembodied nature
of Flow topics, which may be shown out of order and distributed
to many boards, makes it hard to recover a sequential view of the
conversations in order as they happened.

- Same thing for keeping user's behavior in check - policy
enforcement often requires that the reviewers can see exactly
what the users saw when they performed some particular
disruptive action, to assess whether it was made in good faith
from incomplete information or a misunderstanding.

- Comment-based discussion is not the only way editors collaborate;
nor discussions are limited to users expressing their particular views
at ordered, pre-defined processes. Some fellow users have already
pointed out how the wiki page works as a shared whiteboard where
semi-structured or free-form content can be worked upon by several
editors, and improved iteratively in an opportunistic way.
Sometimes, that re-shaping of text is made onto the
form of the conversation itself, by re-factoring, splitting, merging
and re-classifying comments from many editors. This would be
hard or impossible to do if the layout of the discussion is fixed
in hardware and comments belong to the poster.

- Wikiprojects develop over time new procedures that better suit
the workflow of their members to achieve their goals. Their
project pages are free-form collages of all the relevant information
they require to do their work, plus discussion processes that may
involve just its members or any other external participant. As
projects cover all the aspects of human knowledge, it would be
difficult to provide a one-size-fits-all interface that may cover all
their needs - the flexibility to compose new layouts and
compilations of content is core to achieve their goals.

- There's a sense now that the community owns the content of all
pages including talk, and can manage it to their liking. That will
disappear if the base model is changed to one based on user-owned
comments. There has not been enough discussion of how that will
affect all the existing projects and guidelines, or whether such change
is acceptable and beneficial to the goal of writing the encyclopedia.


A wiki-like system is very good at achieving those. Some of these
needs have surfaced at previous discussion at Talk:Flow, and some have
been already addressed or influenced the design, but some others are
squarely opposed to the nature of a threaded discussion where the
structure is enforced by the platform. It would be sensible that the
process to gather feedback from the community includes solid answers
to these facets of the tool.

___
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] To Flow or not to Flow

[Diego Moya]

...and having said and sent that previous post, I want to publicly
apologize for the third paragraph counting from the end. That was uncalled
for.
___
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] To Flow or not to Flow

[Diego Moya]

On 7 September 2014 13:33, Gerard Meijssen 
wrote:

> Get real and look what Flow is and how it can be improved. Check out the
> use cases it works for and acknowledge the achievements. THEN and only THEN
> consider the features that are being tested and are still deficient. THEN
> and only THEN point out how we can move forward and make it work better.
> THEN and only THEN can you lament what we may lose what you liked in Talk
> pages.
>

What makes you think that I have not made all that already? I've been
participating and giving feedback from the very day Flow was announced to
en.wiki, I've filed bugs (the last one today, sending some screenshots to
Erik and he said they're helping him to narrow down the problem with Echo),
I've tested all the releases the day they appeared, I've built mock-ups,
I've suggested and fought for improvements like the table of contents, I
have acknowledged and welcomed the improvements to the usability that Flow
will suppose for newcomers, which is a subject that I care deeply for.

But I've also analyzed the overall direction and found that its basic
approach is limited in scope, treating talk pages as a mere conversation
channel when it fulfills many other roles, and dismissing some fundamental
goals of the talk space that are essential to the mission to build an
encyclopedia, like their role in documenting how articles have been written
and making editors accountable to the world; I've found ways at which the
current design may hurt those goals, but so far has been impossible to get
you to listen.

I *am* trying to point out how we can move forward and make it work better.
I'm trying to reach you because I want Flow to succeed, by pointing out
what I believe by heart to be its deepest flaws so that they can be
corrected, and you think I'm attacking the project.



> However, please consider our need. We are moving more and more towards
> mobile readers and editors and talk pages just do not cut it. We need
> something better for these use cases and, we need them urgently.
>

I have considered those needs, and I've never denied that those are
important goals to fulfill, why would you think I thought otherwise, when
I've never sated such thing? Gerard, do you hate me so much that you put in
my mouth words that I haven't said and assume that I hold positions that
are opposite to what I believe? :'-/

On the other hand, I have requested you to consider our needs, and you have
dismissed them with prejudice. How do you think that treatment will make us
editors feel, and how it will affect the attitude of the community towards
the project?

Please assume good faith and try to listen to what people who care deeply
about the project have to say. I believe that the end result of building an
understanding, from the very different starting points that are held by the
debaters, will benefit the project deeply and will allow for a much more
robust tool that any other way to proceed.
___
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] Feedback with Android on Commons

[Yann Forget]

Hi,

The first thing to fix is the reporting: if the user accepts
reporting, you should really report the issue without asking to enter
a mail or some information the user does not know. I am fine playing a
guinea pig if it is useful, but here I can't even report anything.

Regards,

Yann

2014-09-07 11:15 GMT+05:30 Wil Sinclair :
> Hi Yann, most of the issues you're describing sound like straight-up bugs.
>
> When it comes to Android, it helps to know about issues that affect
> some models but may not come up on the model/version that the
> developer is using for testing. I think it's safe to say that the S4
> is a '''must work''' Android platform. Some of the open bugs already
> filed might apply; if there are closed bugs that aren't fixed on S4,
> they may need to be reopened with a comment. And some of the issues
> you've mentioned don't seem to be captured at all:
>
> https://bugzilla.wikimedia.org/buglist.cgi?component=Android&list_id=342313&product=Commons%20App
>
> IMO, we should be as diligent as possible when it comes to filing bugs
> in the bug tracker. There are lots of concerns about the quality of
> software that have been expressed here. Whether you happen to be
> technical or not, this is one of the best ways each and every one of
> us can do our part to build better software for our community.
>
> Now that I've preached it, it's off to practice for me. I'm
> downloading the commons app on both of my Nexus devices now and will
> file any bugs I see. If anyone would like to join me and Yann, you can
> install the app on your Android device here:
>
> https://play.google.com/store/apps/details?id=org.wikimedia.commons&hl=en
>
> ,Wil
>
> On Sat, Sep 6, 2014 at 11:54 AM, Yann Forget  wrote:
>> Hi,
>>
>> I am not a mobile user. So for the first time, I used the Mobile App
>> on a Samsung S4 to upload a few pictures. I am quite disappointed, to
>> say the least. I stopped counting how many times the application
>> crashed while uploading just a few pictures. Then in reviewing my
>> uploads, I can't see the description or the license, the field is
>> blank. Then I discovered that the Application does not check if the
>> name already exists, and uploads over the old file without warning.
>> Luckily I didn't upload over someone else files. Then the categories I
>> choose were not included, and also no warning there. It is a bit less
>> bad on a tablet, where I can read the description and the license, but
>> I can't add any category. I wonder how a software in such a bad
>> condition gets deployed... Now it is much easier than on the desktop,
>> and I understand why we get so many useless pictures from mobile
>> uploads.
>>
>> https://commons.wikimedia.org/wiki/Commons_talk:Mobile_app#Feedback_on_Android
>>
>> Regards,
>>
>> Yann

___
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

[Amir E. Aharoni]

2014-09-07 4:17 GMT+03:00 Risker :
> I think the design of Flow is much like the liqueur-filled chocolates.
> It's missed the point of a discussion space on Wikimedia projects.  All
the
> use cases in the world, no matter how carefully researched and accounted
> for, will help you build a discussion system to effectively replace a
> discussion system if you don't understand that the one overriding,
> incontrovertible feature of the current system is that it is a page that
> acts just like all the other wiki pages, with all the same functions, and
> anyone who can work on one wiki-page can work on any of them.

I see your point, but the fact is that the current system is NOT a page
that acts just like all the other wiki pages.

Talk pages use categories differently.
Article talk pages, for better or worse, don't have interlanguage links.
Talk pages use : for indentation a lot; articles rarely use this piece of
syntax.
Talk pages can use templates the same way as articles, but the actual
templates used on them are different.
Long talk pages are archived; articles aren't.
Talk pages have signatures; articles, for better or worse, don't.
Talk pages rarely have images.

So yes, the wiki syntax is the same, but the practice of its use is
fundamentally different. And voila - the wiki syntax in Flow works much the
same way as elsewhere - links, templates, etc. The plan is to use the same
VisualEditor as for articles in the future. What Flow replaces is the
crutches built to force wiki pages into being discussion forums -
"talkback", indentation, archive templates and bots, the infinite edit
conflicts, etc.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
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] To Flow or not to Flow

[Gerard Meijssen]

Hoi,
It is fine to disagree. What is lacking in your vision is a viable
alternative and, as you acknowledge the current system is no longer viable
we are in need of an alternative now. Your notions are yours and that is
fine. However, we are not a debating club really. My point is very much
that in Flow we have a project that is actively developed. It is based on
the lessons learned with the current talk pages and Liquid Threads. The
process of development includes community consultation and it has a chance
of delivering something viable in the near future.

To be honest, I do not care at all that you have another vision. It lacks
reality, it lacks a way forward. Get real and look what Flow is and how it
can be improved. Check out the use cases it works for and acknowledge the
achievements. THEN and only THEN consider the features that are being
tested and are still deficient. THEN and only THEN point out how we can
move forward and make it work better. THEN and only THEN can you lament
what we may lose what you liked in Talk pages.

We have to move forward and there is no time to start anew. So blame me
because I am harsh about your notions. I do not care for them, they are in
the way. However, please consider our need. We are moving more and more
towards mobile readers and editors and talk pages just do not cut it. We
need something better for these use cases and, we need them urgently.
Thanks,
 GerardM


On 7 September 2014 11:14, Diego Moya  wrote:

> Gerard, with all due respect, your reply is all based on incorrect
> assumptions. I recognize the severe problems that mediawiki conversations
> currently have, and my points about Flow acknowledge that it's incomplete
> software at its early stages and that it can grow into an acceptable tool
> for having discussions, but all that is irrelevant to the conversation
> that's going on at this thread.
>
> Both Erik and I are talking about what we expect a finished, full featured
> software would look like in the end, and we have both dismissed the current
> status of either tool. The idea that I want the new system to be based on
> current existing software is a strawman; that's not what I defend. I want a
> good, modern document-centric software even if it requires building
> something like mediawiki from scratch. This is a high level view of what
> either model can grow into if enough resources are poured into it.
>
> Erik has this vision that building a stable and easy-to-use system
> requires abandoning the open-ended nature of wiki systems, with which I
> disagree, and has committed us to a project with that result in the end, to
> build a very good architecture that will solve the wrong problem. From the
> conversation so far, I believe such view to be based on an incomplete
> understanding of the community needs, and I'm trying to steer the
> conversation to take into account perspectives from the wider community
> rather than the gut feelings of just one man, no matter how much experience
> he has with the project.
>
___
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] To Flow or not to Flow

[Diego Moya]

Gerard, with all due respect, your reply is all based on incorrect
assumptions. I recognize the severe problems that mediawiki conversations
currently have, and my points about Flow acknowledge that it's incomplete
software at its early stages and that it can grow into an acceptable tool
for having discussions, but all that is irrelevant to the conversation
that's going on at this thread.

Both Erik and I are talking about what we expect a finished, full featured
software would look like in the end, and we have both dismissed the current
status of either tool. The idea that I want the new system to be based on
current existing software is a strawman; that's not what I defend. I want a
good, modern document-centric software even if it requires building
something like mediawiki from scratch. This is a high level view of what
either model can grow into if enough resources are poured into it.

Erik has this vision that building a stable and easy-to-use system requires
abandoning the open-ended nature of wiki systems, with which I disagree,
and has committed us to a project with that result in the end, to build a
very good architecture that will solve the wrong problem. From the
conversation so far, I believe such view to be based on an incomplete
understanding of the community needs, and I'm trying to steer the
conversation to take into account perspectives from the wider community
rather than the gut feelings of just one man, no matter how much experience
he has with the project.
___
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] To Flow or not to Flow

[Gerard Meijssen]

Hoi,
The central point  Diego made starts from is that the current broken system
has a POTENTIAL for unstructured, unaccountable changes by whomever.

You do not build on a fundament that is collapsing as it is. A system that
is manifestly broken particularly on the one platform where our new users
are; mobile.

If we are to take arguments seriously, please explain why we should in this
instance. If dismissing such ideas makes him go away AFTER it has been
explained why the arguments do not wash.. Well, the best that can be said
is that it makes the conversation easier, it does not change the quality of
the arguments at all.
Thanks,
  GerardM


On 7 September 2014 09:55, Wil Sinclair  wrote:

> > Your suggestion is to be dismissed with prejudice because it is so
> > obviously wrong in so many ways.. I do not care about a possible
> potential
> > of a broken system at all I may want to think about features that are
> > actively used in this broken system.
> > Thanks,
> >   GerardM
>
> I won't be dismissing it, because Diego makes some very good points
> and articulates the concerns that many in the community have expressed
> well.
>
> Dismissing his ideas won't make them go away. I just hope that
> dismissing them with that prejudice you mentioned doesn't make him go
> away.
>
> ,Wil
>
> ___
> 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,
> 
>
___
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

[Gerard Meijssen]

Hoi,
I like your story and I understand the sentiment. For me the story is about
the kind of functionality that we may or may not need in Flow. The story is
not about retaining what went before.. Mark my words, I cannot wait for the
old talk system to go.

As I understand the current situation, Flow is gaining in functionality and
it is being used in all kinds of settings. As time goes by, it becomes
feature rich and increasingly versatile. I am sure the husband "learned"
from the first time an egg was presented to his wife. I am sure they shared
fond memories of this moment of embarrassment. Life is short and learning
how to improve your ways makes life more pleasant.

The lessons of the egg are for all of us. Do not single out anyone and do
not think any of us is beyond the need of learning from past mistakes.
Thanks,
  GerardM


On 7 September 2014 03:17, Risker  wrote:

> I'm not going to reply in-line here, because I think there's been an
> undoubtedly unintentional missing of the point here.  Instead I will tell a
> story about a friend of mine.
>
> Some years ago, when her children were 3 and 4, their family had a lovely
> traditional Christmas Day, but something felt like it was "missing".  She
> told her husband about a tradition in her own family, where she and her
> siblings had (since they were very young children) always bought their
> mother a Terry's Chocolate Orange for Christmas - no matter what else her
> mom got, that was considered the one "essential" Christmas gift under the
> tree.  Mom would glow with joy when she unwrapped it, and her most
> heartfelt thanks was for this specific present.  Some time later in the
> day, she'd smack it open and everyone would get a piece.  My friend thought
> it would be wonderful to start a similar tradition in her own young family.
>
> Her husband remembered this story in the weeks leading up to the next
> Christmas.  He plotted with the children, now 4 and 5; he researched the
> "best" types of similar treats; and ultimately he "helped" the children
> obtain a chocolate orange made of the finest Swiss chocolate, filled with
> Grand Marnier liqueur, presented in an elegant marquetry box.  Everyone was
> surprised when she burst into tears instead of smiles, and spent the whole
> day snapping at people and generally being a grouch.  Finally her husband
> confronted her and insisted she explain her behaviour.
>
> What happened, of course, was that despite his best efforts, he'd missed
> the real purpose of the chocolate orange.  He thought it was symbolic of
> the esteem in which the matriarch was held. Really, it was about the
> familial sharing of a special treat; the joy that the sharing brought to
> both the recipient and the presenters.  But she couldn't share
> liqueur-filled chocolate with her children, and could barely bring herself
> to smack open the beautifully designed and presented chocolate.  In other
> words, even though the gift looked brilliant on paper, it missed the point.
>
> I think the design of Flow is much like the liqueur-filled chocolates.
> It's missed the point of a discussion space on Wikimedia projects.  All the
> use cases in the world, no matter how carefully researched and accounted
> for, will help you build a discussion system to effectively replace a
> discussion system if you don't understand that the one overriding,
> incontrovertible feature of the current system is that it is a page that
> acts just like all the other wiki pages, with all the same functions, and
> anyone who can work on one wiki-page can work on any of them.  In other
> words, you're building something that is explicitly different from
> wiki-pages - but the expectation of the majority of the people who will use
> these pages is that they work exactly like any other wiki-page.
>
> This is what I mean when I say that you've not really understood how
> wiki-discussion functions, and you've created the "bells and whistles"
> without demonstrating an understanding of what the real, core functions of
> these pages are.  The priority in design should focus on being able to
> produce identical results for basic wiki-editing and page management: we
> move pages, we protect them, we undo and revert edits, we fix typos and
> correct URLS and links in each other's posts, we quote each other and
> copy/paste, we modify each other's words when collaborating on the wording
> of a complex section of an article, we get rid of trolling, we delete and
> sometimes suppress personal attacks, we hat and archive individual
> discussions.  Whether or not a post gets auto-signed is a "frill" compared
> to those basic functions, and it is inevitable that the deprioritization of
> "the basics" will result in people not really caring much about the frills
> (no  matter how well they are executed) and focusing instead on what the
> new "system" doesn't do.  This is the real parallel between Flow and Visual
> Editor - focusing on the "difference" between the new product

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

[Pine W]

I would suggest aiming for a series of base hits. (:  An attempt was made
to hit VE out of the park. We know how well that worked.

I think a lot of the work of capturing suggestions is supposed to be done
by the project manager and the engineering community liaisons. It would be
interesting to have community ideas documented in a single, public,
searchable, well-organized location. The project manager and community
liaison could be the curators.

It might be good for people who are interested in Flow to attend the Flow
IRC office hours, and join in the Flow discussions on the Editor Engagement
email list.

Pine

On Sun, Sep 7, 2014 at 12:38 AM, Wil Sinclair  wrote:

> > Fundamentally, I'd ask people to relax a bit regarding Flow. Nobody's
> > planning to push this one out radically. Today we saw some on-wiki
> > drama because a new test page was turned on. For something like the
> > en.wp Teahouse, I'd want the hosts to be fully on-board before
> > converting it over (and the rest of the community to not oppose it).
> > If that's not doable, we can focus on other use cases first. It's
> > early days and this one's a long haul -- just like VE. But we
> > shouldn't shy away from a problem just because it's hard.
>
> I think this is one of the points some of us here are trying to make.
> We *don't* want Flow to be just like VE. We want it to be a good piece
> of software that is rolled out smoothly.
>
> There are some serious communication problems that I can already see
> having a toll. Fractured discussions, issues/concerns not captured in
> workflows, and many members of the community who feel like they
> haven't been heard out during earlier stages of the project. We have
> an opportunity to not get all wound around the axle like we have been
> with MV, and that opportunity should not be thrown away.
>
> Quite frankly, the WMF could do a lot more to improve communications
> across the community with respect to Flow. Pick one forum and redirect
> discussions- even this one- to it. Right now there are a few
> candidates. Make sure all the takeaways from those discussions are
> captured in workflows; don't let ideas get lost in archives. Choose
> one place to keep your backlog- bugzilla or trello- and stick with it.
> You'll need the community's help to see what works for the different
> roles everyone must play to make software that works well for its
> users. But the community needs your help in organizing the highly
> detailed communications with users that is always required to build
> good software.
>
> It good to hear you say that this is a long haul, because Flow
> obviously has a ways to go. But that doesn't mean it has to be a death
> march to the same reception as VE or MV. Let's all be smarter this
> time. Learning how to communicate better is a great place to start,
> and I hope the feedback I've given here is helpful. Please let me know
> if there is anything you can think of that I- or anyone else in the
> broader community- can do to help you hit this one out of the park.
>
> ,Wil
>
> ___
> 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,
> 
>
___
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] To Flow or not to Flow

[Wil Sinclair]

> Your suggestion is to be dismissed with prejudice because it is so
> obviously wrong in so many ways.. I do not care about a possible potential
> of a broken system at all I may want to think about features that are
> actively used in this broken system.
> Thanks,
>   GerardM

I won't be dismissing it, because Diego makes some very good points
and articulates the concerns that many in the community have expressed
well.

Dismissing his ideas won't make them go away. I just hope that
dismissing them with that prejudice you mentioned doesn't make him go
away.

,Wil

___
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

[Wil Sinclair]

> Fundamentally, I'd ask people to relax a bit regarding Flow. Nobody's
> planning to push this one out radically. Today we saw some on-wiki
> drama because a new test page was turned on. For something like the
> en.wp Teahouse, I'd want the hosts to be fully on-board before
> converting it over (and the rest of the community to not oppose it).
> If that's not doable, we can focus on other use cases first. It's
> early days and this one's a long haul -- just like VE. But we
> shouldn't shy away from a problem just because it's hard.

I think this is one of the points some of us here are trying to make.
We *don't* want Flow to be just like VE. We want it to be a good piece
of software that is rolled out smoothly.

There are some serious communication problems that I can already see
having a toll. Fractured discussions, issues/concerns not captured in
workflows, and many members of the community who feel like they
haven't been heard out during earlier stages of the project. We have
an opportunity to not get all wound around the axle like we have been
with MV, and that opportunity should not be thrown away.

Quite frankly, the WMF could do a lot more to improve communications
across the community with respect to Flow. Pick one forum and redirect
discussions- even this one- to it. Right now there are a few
candidates. Make sure all the takeaways from those discussions are
captured in workflows; don't let ideas get lost in archives. Choose
one place to keep your backlog- bugzilla or trello- and stick with it.
You'll need the community's help to see what works for the different
roles everyone must play to make software that works well for its
users. But the community needs your help in organizing the highly
detailed communications with users that is always required to build
good software.

It good to hear you say that this is a long haul, because Flow
obviously has a ways to go. But that doesn't mean it has to be a death
march to the same reception as VE or MV. Let's all be smarter this
time. Learning how to communicate better is a great place to start,
and I hope the feedback I've given here is helpful. Please let me know
if there is anything you can think of that I- or anyone else in the
broader community- can do to help you hit this one out of the park.

,Wil

___
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,