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

2014-08-25 Thread Gerard Meijssen
Hoi,
Given that it is pathetically easy to opt out of the MultimediaViewer, the
amount of vitriol spouted by some is way out of proportion to the problem.
If you do not want it, opt out. But thermonuclear was was threatened,
people were to lose their job over this.

No the excuses are too little and too late. When people think that the
change is not good for them opt out. What was said was a disgrace. It has
never been in doubt that problems would be tackled.

Finally do not expect that much maintenance will be done on what is so
lightly discarded. It is fine for you to stay with your Internet 6.
Improvements and subsequent development is just not for you.
Thanks,
GerardM


On 25 August 2014 05:19, Pine W wiki.p...@gmail.com wrote:

 I have heard very few people say don't ever change the interface. I have
 heard people say don't force an interface change on me that I don't think
 is an improvement.

 VE was a good example. The sentiment of the community wasn't that VE''s
 concept is wrong, it's that the implementation and rollout had major
 deficiencies.

 The MV issue is larger than than the usual editor-focused interface change
 because it impacts readers as well as editors, and there were issues with
 the display of licenses to readers. Personally I feel that the MV issues
 are fixable but the rollout should have been handled differently, and I am
 glad that the community and WMF both want to avoid repeating rollout
 problems again and again.

 Pine


 On Sun, Aug 24, 2014 at 4:48 AM, Gerard Meijssen 
 gerard.meijs...@gmail.com
 wrote:

  Hoi,
  In the metrics meeting, a presentation was given that showed that mobile
  editing is really starting to happen. It is happening to the extend where
  new editors are predominantly mobile editors.
 
  When I asked my question do we need to keep you happy I specifically
  targeted the vitriolic parts of our community. In my experience it it the
  part that is conservative, not willing to listen, not open to change and
  not willing to consider what is important to others.At Wikimania one of
 the
  presenters indicated that he was willing to contribute to Wikidata. This
  was not accepted because someone in the community is really involved in
  this subject and he had to have a say. This was one major person
 probably
  walking away for ever who is hugely important in science and open data.
 The
  user interface for selecting fonts is abysmal because the community
  decided that what was implemented looked cluttered. Only seven percent of
  the world population is dyslexic and they do NOT find Wikipedia easier to
  read as a result.
 
  Really, what is important to some people in the community is not
  necessarily beneficial at all. The lack of conversation the ease of
 making
  demands and not appreciating that our aim is to share in the sum of all
  knowledge means that many retarded points of view abound.
 
  Erik indicated that he is willing to talk and come to a workable
  compromise. However, we do need change and we need it badly. When this is
  not understood, I am sorry to say, those who fail to understand this are
 a
  problem, a problem that is increasingly cancelling out their future
 value.
  Thanks,
  Gerard
 
 
  On 24 August 2014 12:49, Dariusz Jemielniak dar...@alk.edu.pl wrote:
 
   hi,
  
   On Sun, Aug 24, 2014 at 11:07 AM, Gerard Meijssen 
   gerard.meijs...@gmail.com
wrote:
  
   
Now what do we aim to achieve? Keeping you happy or making sure we
  have a
public ???
   
  
   simply put: both. We need readers just as much as we need the free
 labor
  of
   editors/volunteers.
  
   I don't think it makes any sense to have a discussion about the wasted
   millions. First, in software development there is always some
 inevitable
   waste, just because of the nature of this endeavor. Second, many
 projects
   which start with mixed reception are getting better (and I have high
 hope
   that the visual editor is one of them!). Third, for an IT organization
 of
   this caliber and traffic, as well as the budget, there are impressive
   results in many areas (including, but not limited to, mobile website -
 at
   least for viewers, as editing is a different story).
  
   The real problem here, in my view, is creating an organizational
  framework
   that will allow to incorporate the community much more into planning,
  early
   development, alpha and beta testing, and finally implementation of all
  new
   features and tools (in a way which does not rely on IT schedules only,
  but
   also on feedback from the communities). It is up to WMF to create and
   provide such framework, as our community as a whole does not have any
   institutionalized representation or voice (which is part of the issue;
  one
   the one hand it is easy to discard whatever people from the community
  say,
   as they are random individuals, and on the other it must be deeply
   frustrating to never be sure what the community reaction will be). Some
   

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

2014-08-25 Thread Pine W
The issue is not just that individual users may want to opt out, it's
whether it should be activated by default for readers. There is also the
matter of licensing information.

I'm not aware of where thermonuclear was was threatened. There were, and
continues to be, discussion about forking. MV is merely the latest
occurrence of products with major problems being pushed into production and
made default. That needs to be addressed, and the fact that the problems
with MV happened after AFT5 and VE *and* after the creation of the
Engineering Community Liaisons suggests deep, long-term problems with
product development. I believe that Lila said that the Board wants her to
transform WMF and I am glad that there seems to be agreement that Product
will be an early subject of transformation. I have reservations about
forking for reasons that I can explain if necessary. It would be a lot
easier if WMF would transform itself, starting with Product, and Lila
appears to intend to make this happen. I hope that the processes for
Product will be democratic and consensus-based. Grantmaking has already
demonstrated the effectiveness of community-based decision making with FDC
and IEGCom, and I hope to see a similar model emerge for Product. If it
doesn't, there is enough anger in the community, especially on DEWP, that a
fork is possible. The community is smart enough collectively to figure out
a way to make a fork happen, and some of us have been discussing the
mechanics of how this would work. We could do it, but reforming WMF is
preferable. I hope that Lila can and will do this. Internal transofmration
is preferable to replacing WMF.

Pine
___
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] Next steps regarding WMF-community disputes about deployments

2014-08-25 Thread svetlana
On Mon, 25 Aug 2014, at 13:19, Pine W wrote:
 I have heard very few people say don't ever change the interface. I have
 heard people say don't force an interface change on me that I don't think
 is an improvement.
 
 VE was a good example. The sentiment of the community wasn't that VE''s
 concept is wrong, it's that the implementation and rollout had major
 deficiencies.
 
 The MV issue is larger than than the usual editor-focused interface change
 because it impacts readers as well as editors, and there were issues with
 the display of licenses to readers. Personally I feel that the MV issues
 are fixable but the rollout should have been handled differently, and I am
 glad that the community and WMF both want to avoid repeating rollout
 problems again and again.
 
 Pine


This instance is not new; 
https://meta.wikimedia.org/wiki/Limits_to_configuration_changes is a historical 
list of similar pattern in the relationship.

They already told you that they are doing this to not lose readers, so that 
fundraising keeps working. Tops you can do is, like the WMF folks remarked 
earlier, is have community work on what it needs from the bottom up 
grassroots etc.

A first step here, I believe, is have the Teams track bugs in the open; from my 
own experience, the Flow and Multimedia folks track bugs somewhere else where I 
can't even view or comment (and even if I could, it being different from 
Bugzilla would make things harder). I'm not sure what about migration to 
Phabricator, but I think it's an operations style of thing (I'm yet to figure 
out how to get involved, but it'd make it easier for anyone to work on the new 
features - they are really documented on-wiki (thankfully they only internalise 
only bug tracking atm), although so far only in English mostly).

svetlana

___
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

[Wikimedia-l] Tracking bugs in the open (was Re: Next steps regarding WMF-community disputes...)

2014-08-25 Thread Quim Gil
Hi,

On Monday, August 25, 2014, svetlana svetl...@fastmail.com.au wrote:


 A first step here, I believe, is have the Teams track bugs in the open;
 from my own experience, the Flow and Multimedia folks track bugs somewhere
 else where I can't even view or comment (and even if I could, it being
 different from Bugzilla would make things harder).


All WMF Engineering teams track bugs in the open (unless they are
security/privacy related, for obvious reasons), although the use of
multiple tools doesn't help indeed. This is why we decided to move to
Phabricator.


 I'm not sure what about migration to Phabricator, but I think it's an
 operations style of thing (I'm yet to figure out how to get involved, but
 it'd make it easier for anyone to work on the new features - they are
 really documented on-wiki (thankfully they only internalise only bug
 tracking atm), although so far only in English mostly).


I'm not sure I understand, but in any case
https://www.mediawiki.org/wiki/Phabricator#Get_involved


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
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] Wrong attribution in PDF output of Wikipedia atricles

2014-08-25 Thread Jeevan Jose
I tried to make the PDF of
https://en.wikipedia.org/wiki/De_Havilland_Canada_DHC-6_Twin_Otter

It credits File:WinAir De Havilland Canada DHC-6-300 Twin Otter
Breidenstein.jpg  Source:
https://en.wikipedia.org/w/index.php?title=File:WinAir_De_Havilland_Canada_DHC-6-300_Twin_Otter_Breidenstein.jpg
 License: unknown  Contributors: Timo Breidenstein

License is still unknown

Regards,
Jee


On Mon, Aug 25, 2014 at 1:00 AM, Russavia russavia.wikipe...@gmail.com
wrote:

 Mike et al

 On Mon, Aug 25, 2014 at 3:05 AM, Michael Peel em...@mikepeel.net wrote:

  I've swapped it for a CC-licensed file that does allow for commercial
  reuse. Problem solved?
 

 GFDL is a free licence. You can licence under the free GFDL licence and
 also licence it under an -NC licence. So long as one licence is free on
 Commons, you can have other combinations.

 But the problem isn't solved.

 I have numerous aviation photographers and friends who have licenced their
 works under GFDL -- many of which are irreplaceable, or are the best
 illustration of the subject. Examples being:

 http://commons.wikimedia.org/wiki/File:Abramovich_Chukotka.jpg

 http://commons.wikimedia.org/wiki/File:Singapore_Airlines_Airbus_A380_woah%21.jpg

 http://commons.wikimedia.org/wiki/File:Singapore_Airlines_Airbus_A380_Wallner.jpg

 http://commons.wikimedia.org/wiki/File:Myanmar_Air_Force_Shaanxi_Y-8_MRD.jpg
 http://commons.wikimedia.org/wiki/File:PLAAF_Xian_HY-6_Li_Pang.jpg

 http://commons.wikimedia.org/wiki/File:WinAir_De_Havilland_Canada_DHC-6-300_Twin_Otter_Breidenstein.jpg

 and the list goes on.

 If there is an issue with how the PDFs are presenting the licencing
 information, this is still very much an issue, and if it isn't working as
 it should at this moment, the PDF feature should be switched off.

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

___
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] Next steps regarding WMF-community disputes about deployments

2014-08-25 Thread Gilles Dubuc

 from my own experience, the Flow and Multimedia folks track bugs somewhere
 else where I can't even view or comment


Bugs and tasks are public for the Multimedia team. If you mean bugs in
the bastardized sense of the term which is things filed in bugzilla, then
yes, the Multimedia team doesn't usually file building/refactoring tasks in
bugzilla, we use mingle instead, which is public and can be commented on by
everyone: http://ur1.ca/i1x3g We regularly link to our mingle cards on our
mailing list updates, it's never been a secret area. I find that the
mailing list is a better place for discussion, though, and we summarize in
regular threads what tasks we're working on or planning to work on. In
practice that's what's always happened anyway, people interested in what
we're up to will reply to the detailed mailing list updates rather than
comment on Mingle. Probably because Mingle's comment support is terrible.

As for actual bugs (defects) on products the Multimedia team is responsible
for, they are currently tracked on bugzilla like everything else. It can
happen ocassionally that we fix a bug and forget to file it in bugzilla,
but generally speaking a bug/defect tracked in Mingle has a bugzilla
counterpart. The existing disconnect and the fact that we sometimes forget
to file a counterpart is one of the reasons we want to have a unified tool
to do all the things people currently use bugzilla, mingle and trello for.

Our team will be one of the first to migrate to phabricator when the
migration starts, because it will allow us to treat tasks, workload and
defects in a single place. It will also give a much clearer view of what's
going on to casual observers. The only reason why our team uses Mingle
instead of Bugzilla for building tasks and triage is that Bugzilla offers
no workload management and is often a poor fit for things that aren't
defects. We're definitely not using Mingle to get things out of view (since
it's public and regularly linked to), it's just that in the status quo
Bugzilla alone didn't offer what we needed. I'm sure other teams use Trello
and other tools for similar reasons. This is all coming from needs not
covered by Bugzilla and we know very well how much that sucks in various
ways, including the introduction of signup hurdles for people who want to
interact with us, and the lack of discoverability, despite linking to
Mingle every time we can. We certainly hope that the move to phabricator
will make help people see and comment on what we're doing. Feeling like
we're the only ones active on a particular tool is unhealthy for our
projects, that's definitely not what we're looking for with phabricator, on
the contrary.


On Mon, Aug 25, 2014 at 6:19 AM, svetlana svetl...@fastmail.com.au wrote:

 On Mon, 25 Aug 2014, at 13:19, Pine W wrote:
  I have heard very few people say don't ever change the interface. I
 have
  heard people say don't force an interface change on me that I don't
 think
  is an improvement.
 
  VE was a good example. The sentiment of the community wasn't that VE''s
  concept is wrong, it's that the implementation and rollout had major
  deficiencies.
 
  The MV issue is larger than than the usual editor-focused interface
 change
  because it impacts readers as well as editors, and there were issues with
  the display of licenses to readers. Personally I feel that the MV issues
  are fixable but the rollout should have been handled differently, and I
 am
  glad that the community and WMF both want to avoid repeating rollout
  problems again and again.
 
  Pine


 This instance is not new;
 https://meta.wikimedia.org/wiki/Limits_to_configuration_changes is a
 historical list of similar pattern in the relationship.

 They already told you that they are doing this to not lose readers, so
 that fundraising keeps working. Tops you can do is, like the WMF folks
 remarked earlier, is have community work on what it needs from the bottom
 up grassroots etc.

 A first step here, I believe, is have the Teams track bugs in the open;
 from my own experience, the Flow and Multimedia folks track bugs somewhere
 else where I can't even view or comment (and even if I could, it being
 different from Bugzilla would make things harder). I'm not sure what about
 migration to Phabricator, but I think it's an operations style of thing
 (I'm yet to figure out how to get involved, but it'd make it easier for
 anyone to work on the new features - they are really documented on-wiki
 (thankfully they only internalise only bug tracking atm), although so far
 only in English mostly).

 svetlana

 ___
 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

___
Wikimedia-l mailing list, 

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-25 Thread Delirium

On 8/25/14, 3:06 AM, MZMcBride wrote:

As a metric, pageviews are probably not very meaningful. One way we can
observe whether we're fulfilling our mission is to see how ubiquitous
our content has become. An even better metric might be the quality of the
articles we have. Anecdotal evidence suggests that higher article quality
is not really tied to the readership rate, though perhaps article size is.


Yes, I'd ideally like some better measure of how much people get out of 
articles. Some types of analytics do track page view duration, although 
that can be considered intrusive.


I've done a little spot-checking within specific areas (e.g. 
archaeological sites) of our view counts, and they are largely dominated 
by spikes around transient news events: something is in the news and 
5,000 or 50,000 people load an article that normally gets 50 or 100 hits 
a day. Providing that kind of quick background knowledge to people 
googling for an item they saw on the news is a valuable service, to be 
sure. But I'm not sure it's *as* big a proportion of the value Wikipedia 
provides as the raw pageload numbers would say.


-Mark


___
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] editor retention initiatives

2014-08-25 Thread Tanweer Morshed
Thanks James for addressing such a crucial issue. It is a vital matter but
being discussed far less than other topics, in offline or offline programs,
activities. Among measures fore retaining editors, there were some banners
that appeared on top of articles viewed by new editors or readers. I've
heard that this worked somewhat but didn't continue. In Bangladesh, we're
(Wikipedians/Wikimedians) particularly discussing and talking on how to how
to retain more editors. Many people are becoming new editors but most of
them leave after some days and become inactive. The Task recommendations
seems quite interesting, but I was unaware of it. What about its
implementation? was it ever tested on any Wikipedia and if so, how
successful was it?


On Mon, Aug 25, 2014 at 8:35 AM, Steven Walling steven.wall...@gmail.com
wrote:

 On Sat, Aug 23, 2014 at 6:55 PM, James Salsman jsals...@gmail.com wrote:

  Is there a list somewhere of all currently active Foundation
  initiatives for attracting and retaining active editors?  I am only
  aware of the one project, Task Recommendations, to try to encourage
  editors who have made a few edits to make more, described starting at
   https://www.youtube.com/watch?v=2JbZ1uWoKEgt=60m20s
 

 Task recommendations is one nascent initiative that my team is working
 on.[1] We're still in the very early prototyping and testing stages. (BTW,
 the whole video segment starts two minutes earlier at about the 58:00
 mark.)

 Task recommendations is far from the only thing we're doing to attract and
 retain active editors. Pretty much the entirety of the features development
 roadmap for desktop and mobile is focused on this problem. VisualEditor,
 Flow, mobile web and apps work, and more all address this problem from
 different angles. You can keep up with what the Foundation is doing by
 checking out the monthly engineering reports.[2]


  Is there any evidence at all that anyone in the Foundation is
  interested in any kind of change which would make non-editors more
  inclined to edit, or empower editors with social factors which might
  provide more time, economic power, or other means to enable them to
  edit more?
 

 We practically can't and don't take on initiatives that directly try to
 provide more free time or money to editors. We can, however, help people do
 more with the free time they have, and ask new people to become
 contributors. Both of those are things we're tackling. A central goal of
 improving the usability of the core editing experience across devices is to
 save people time and energy. My team's also trying other things to attract
 new community members, such as actually inviting people to sign up.[3]

 1. https://www.mediawiki.org/wiki/Task_recommendations
 2. https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/latest
 3.

 https://www.mediawiki.org/wiki/Anonymous_editor_acquisition#Invite_users_to_sign_up
 ___
 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




-- 
Regards -
Tanweer Morshed
___
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] editor retention initiatives

2014-08-25 Thread Ilario Valdelli
Wikimedia ch is doing a big investment in supporting communities.

There are three community liaisons (a third hired recently) to support the
three national languages which are also within the biggest linguistic
communities.

Anyway there is not a unique solution to be adapted easily in user
retention and recruiting because the world is varioius as it is the life.

Regards
Il 24/ago/2014 03:56 James Salsman jsals...@gmail.com ha scritto:

 Is there a list somewhere of all currently active Foundation
 initiatives for attracting and retaining active editors?  I am only
 aware of the one project, Task Recommendations, to try to encourage
 editors who have made a few edits to make more, described starting at
  https://www.youtube.com/watch?v=2JbZ1uWoKEgt=60m20s

 I am not worried about pageviews at all, given that the trend is as
 constant as it has ever been when mobile users are added in to the
 total. Sadly, the greater number of mobile users appears to be harming
 active editor numbers beyond their already dismal trend, so it would
 be nice to have an idea of exactly how much effort the Foundation is
 applying to its only strategic goal which it is not achieved, and has
 not ever achieved. I am amazed that so much more effort continues to
 be applied to the other goals, all of which have always been met
 through to the present. What does this state of affairs say about the
 Foundation leadership's ability to prioritize?

 Is there any evidence at all that anyone in the Foundation is
 interested in any kind of change which would make non-editors more
 inclined to edit, or empower editors with social factors which might
 provide more time, economic power, or other means to enable them to
 edit more?

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

[Wikimedia-l] Add a link to contributors or authors to Wikipedia's byline

2014-08-25 Thread James Heilman
Started a proposal here about it
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Adding_a_link_to_.22authors.22_in_Wikipedia.27s_by-line

And have created a mockup of what it would look like here
https://en.wikipedia.org/wiki/Heart_failure

Wondering peoples opinions.

-- 
James Heilman
MD, CCFP-EM, Wikipedian

The Wikipedia Open Textbook of Medicine
www.opentextbookofmedicine.com
___
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] Add a link to contributors or authors to Wikipedia's byline

2014-08-25 Thread MZMcBride
James Heilman wrote:
And have created a mockup of what it would look like here
https://en.wikipedia.org/wiki/Heart_failure

This isn't really a mock-up... it's probably best to use
test.wikipedia.org or another dedicated test wiki for tests.

Wondering peoples opinions.

The mobile team somewhat recently added a similar strapline to the mobile
site. You've seen https://en.m.wikipedia.org/wiki/Heart_failure? It
currently changes colors based on the last time the page was modified and
it includes the username of the most recent editor.

I think the current mobile implementation is bad because it sends
misleading or inaccurate messages to users:

* articles are intentionally unsigned and without an owner, so putting a
  single username at the top of an article isn't really appropriate;

* the color cues (green if the page was recently edited, grey if the page
  hasn't been recently edited) give the impression that recent page
  activity is more important than making quality edits; and

* the last edited time may or may not be the last time the page was
  truly edited (consider page protection, vandalism followed by a
  reversion, etc.).

I think we're prominently sending the wrong messages to users on the
mobile site and I'm not really interested in doing the same on desktop. A
simple authors link, as you've proposed, might be more palatable. Though
I don't imagine linking to tools.wmflabs.org from every article would be
feasible due to server load, unless appropriately planned for. And we
probably don't want users bouncing to another domain in any case. We
already have https://en.wikipedia.org/wiki/Heart_failure?action=info
linked from the sidebar. Bolstering the content of this info page and
making the link to it more prominent would probably be better uses of time.

MZMcBride



___
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

[Wikimedia-l] Add a link to contributors or authors to Wikipedia's byline

2014-08-25 Thread James Heilman
Yes I agree that mobile is a little much. I am just proposing a simple
linked word (either author or contributors) in the by-line. It is important
to have this information in the by-line rather than to the left as this is
where people expect to find the authors / contributors.

Not attached to were it links to as long as that page contains a clear list
of the authors. Maybe we could add some of Xs tool info to a Wikipedia
based page?

-- 
James Heilman
MD, CCFP-EM, Wikipedian

The Wikipedia Open Textbook of Medicine
www.opentextbookofmedicine.com
___
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