Wikimedia-l June 2010

wikimedia-l@lists.wikimedia.org

151 participants
114 discussions

[Foundation-l] Top posting
by Gerard Meijssen 14 Jun '10

14 Jun '10

Hoi, An important thread has been derailed by an off topic comment. For your information, and for the somanyth time, top posting comes easy when you use a modern tool like GMAIL. It automatically hides whatever came before. This whole notion has no relevance to me as a consequence. I get hundreds of mails and the notion that one should be answered differently then others is not easy to consider. I answer to the content to a mail and that is not related to who will receive it. Given that for people who use software that is not as helpful as mine, the experience rates as a nuisance as I appreciate it. It is similar to the use of words or acronyms that are likely not to be understood. For me KTHX is one such, the top rated result makes it a radio station and it took me some time to find that it is likely to mean "Ok, thanks". The point is not that such words or acronyms should not be used, it is just to indicate that nuisances come in many forms and are a fact of life. Thanks, GerardM

7 8

[Foundation-l] Link in the Downloads section
by Wilfredo Rodriguez 14 Jun '10

14 Jun '10

Sincerely wikimedia team. I have a simple question. I would like to make a proposal to add an application (link) wikipedia offline here: http://dumps.wikimedia.org/dvd.html Who should I contact? The project that I want to add is called Kiwix and is free: http://www.kiwix.org Thank you very much in advance and please forgive me if this is not the right place -- Lcdo. Wilfredo Rafael Rodríguez Hernández -------------------------------------------------------- msn,googletalk = wilfredor(a)gmail.com cv = http://www.wilfredor.co.cc blog = http://wilfredor.blogspot.com fotos = http://picasaweb.google.com/wilfredor/

2 2

Re: [Foundation-l] Creating articles in small wikipedias based on user requirement
by AGK 14 Jun '10

14 Jun '10

On 14 Jun 2010, at 09:05, Michael Peel <email(a)mikepeel.net> wrote: > Is it just me, then, that finds it easier and quicker to read top > post replies than to search through large amounts of text to find > the response? Inline posting makes sense if you're replying to an > email that makes its point in the space of a few lines, but > otherwise it seems easier to me to top-post and to leave the > previous email below for context. That is all true. But I wouldn't dignify the "top-posting perverts" comment with a reply, if I were you. AGK

1 0

Re: [Foundation-l] foundation-l Digest, Vol 75, Issue 64
by Joan Goma 14 Jun '10

14 Jun '10

This is would be very interesting but usefulness will be a bit limited because people use Google to search instead of Wikipedia. Probably we will get a list of read links clicked by readers they don’t know there is not an article yet. A complementary approach could be having a list of most viewed articles in large wikipedias from IPs of geographic areas where the small language is spoken. This could tell us what those people is searching for when Google sends them to large wikipedias. > Date: Fri, 11 Jun 2010 17:26:17 -0700 > From: Mark Williamson <node.ue(a)gmail.com> > Subject: Re: [Foundation-l] Creating articles in small wikipedias > based on user requirement > To: Wikimedia Foundation Mailing List > <foundation-l(a)lists.wikimedia.org> > Message-ID: > <AANLkTilX08PAxlTdKy9YpeiXlzsDHhBupqahgS73q9GK(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > +1. This would be a SUPER useful tool for all Wikis. > -m. > > On Fri, Jun 11, 2010 at 3:54 AM, Shiju Alex <shijualexonline(a)gmail.com> > wrote: > > Recently I had a discussion with one of my fellow Malayalam wikipedian ( > > http://ml.wikipedia.org) about the creation of new articles in small > > wikipedias like ours. He is one the few users who is keen on creating new > > articles *based on the requirement of our readers*. (Of course we have > many > > people who only reads our wiki) > > > > During discussion he raised this interesting point: > > > > Some feature is required in the MediaWiki software that enable us to see > a > > list of keywords used most frequently by the users to search for > non-exist > > articles. If we get such a list then some users like him can concentrate > on > > creating articles using that key words. > > > > Of course, I know that this feature may not be helpful for big wikis like > > English. But for small wikis (especially small non-Latin language wikis), > > this will be of great help. It is almost like* creating wiki articles > based > > on user requirement*. > > > > > > I would like to know your opinion regarding the same. > > > > > > Shiju > > _______________________________________________ > > foundation-l mailing list > > foundation-l(a)lists.wikimedia.org > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l > > >

1 0

[Foundation-l] Are Wikimedia websites a proper venue for an artistic contest ?
by Teofilo 12 Jun '10

12 Jun '10

Let's have a look at the mission of Wikimedia : "The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally." (1) Is there any room in this mission for an artistic contest ? Is there any room in this mission for promoting little known young or older artists seeking recognition ? And should the recognition of the artistic skills of some contributors be done at the expense of the contributors who contribute with other skills, while their artistic skills are those of a beginner ? Wikimedia Commons Picture of the Day (2) is an artistic contest. Why on earth is it allowed on a Wikimeda website and given a prominent space on the main page of one of the main websites ? Should it not be abolished ? If that artistic contest remained doing its business on its dedicated pages without interfering with the rest of the project, there would not be too much need to think too much about it. But I am afraid that the artistic virus is slowly contaminating other parts of the project. I discovered this morning "poor composition" as an argument for deleting a picture (from someone else, not me). It means that the "picture of the day" people are slowly highjacking Wikimedia Commons to turn it into a beauty contest. None of the pictures I take with my small 29.95€ made in China camera can compete with pictures that could be taken with a professional camera. If the destiny of my pictures on Wikimedia Commons is deletion because of their poor artistic qualities, I ought to be told right now so that I don't waste my time taking them and uploading them. But if Wikimedia is about education rather than about art, does it matter if the school's architecture or the textbook is ugly, while the teacher teaches valuable skills and information to the pupils ? I think there is some space for beauty and art within Wikimedia projects, but that space is very thin. Beauty fits the mission statement only as a pedagogic tool, as a part of the "effectively" adverb of the mission statement, thinking that it is easier to have the pupils feel comfortable at school if their school's building and their textbooks are somewhat attractive. But I don't see how beauty or art could be a top level priority. Why don't we ever read on Wikimedia Commons' main page "look at this picture: it is quite awkward, poorly lit, but it is the first picture we've ever had to illustrate Wikipedia article "<name of page>". We are grateful to the contributor who sent it. AND we will never delete it even if no longer used in any Wikipedia article when better pictures are sent by professional photographers later. (1) http://wikimediafoundation.org/wiki/Mission_statement (2) http://commons.wikimedia.org/wiki/Picture_of_the_day

6 7

Re: [Foundation-l] [Commons-l] Fwd: Are Wikimedia websites a proper venue for an artistic contest ?
by Casey Brown 12 Jun '10

12 Jun '10

On Sat, Jun 12, 2010 at 11:51 AM, geni <geniice(a)gmail.com> wrote: > see: > > http://commons.wikimedia.org/wiki/Commons:Valued_images Oops, *this* is what I meant when I was talking about Quality Images. :-) -- Casey Brown Cbrown1023

1 0

[Foundation-l] Community, collaboration, and cognitive biases
by Erik Moeller 11 Jun '10

11 Jun '10

Hello all, the massive thread regarding the default sidebar language link expansion state has surfaced a number of fundamental and significant questions regarding the working relationship between the Wikimedia Foundation and the larger Wikimedia volunteer community. This message represents my snapshot-in-time thinking about these questions, and I hope others will join this thread to meaningfully advance this IMO very important conversation. Tl;dr version: I believe that the transparency of Wikimedia's engineering processes, and the general quality of these processes, has significantly improved over the last year. At the same time, I agree with those who are observing a widening gap between staff and volunteer contributions, and I think we need to work together to close this gap in full awareness of the cognitive biases present in all of us. 1) Increase in quality and transparency of our engineering processes: I'm very grateful for the hard work accomplished by the User Experience Team to-date. When we started the usability project, we had never run a discrete engineering effort of comparable scale before, and indeed, most of our larger-scale engineering projects tended to be drowned by day-to-day emergencies and bug fixes. The team consists primarily of people who didn't have a long prior history in Wikimedia projects, nor with each other: they had to grow as a team, understand our enormously complex community, while also delivering results. I want to use this opportunity to explicitly thank Brion, who played a key role in the orientation of the team. The UX team has implemented a number of important practices: * very frequent sharing of detailed work product, including mock-ups, specs, and research results such as user test videos. * systematic QA using an external QA firm, browser compatibility matrix, etc.; beginnings of automated testing * qualitative remote and in-person user testing to assess real-world experience with the site * moving towards data-driven decision-making using tools such as click-tracking, systematic assessment of feedback data, various statistics, etc. * public and frequent blog updates both in the regular and in the technical blog, use of the sitenotice to announce deployments * public sandboxes demonstrating all bleeding edge improvements early * various community-oriented discussion pages and documentation on usability.wikimedia.org informing and supporting design and localization * largest systematic feedback collection about any software deployment in the history of Wikimedia projects Many of these were "firsts" for the Wikimedia Foundation, and they all were firsts on this scale. Some of these practices have clearly contributed to letting the community participate _more_ in the overall initiative: the larger-scale outreach, the sharing of research findings (which led to some community-driven improvements), the carefully prepared public testbeds, etc. Some, on the other hand, have arguably widened the staff and volunteer gap, both between staff developers and volunteer developers, and between staff and larger volunteer community. I don't think Wikimedia's development processes are anywhere near those of proprietary web companies, but it's absolutely true that they're also not highly comparable to 100% volunteer-driven open source projects anymore. I think there are some parallels with both the strengths and weaknesses of open source projects with reasonably well-funded organizations behind them, both for-profit and non-profit. I also want to be clear that there's no doubt in my mind that our ability to execute projects of this _type_ and at this _scale_ is unprecedented, and a historic achievement for the Wikimedia movement. MonoBook was implemented in 2004, and the basics of the user interface and user experience of Wikipedia have changed very little between then and pre-Vector. The reasons for that are varied. Fundamentally, I believe that online volunteer mass collaboration works best when incrementalism and self-selection can, over a long period of time, add to an overall product that's useful at any given time -- such as Wikipedia or Wikimedia Commons. We've seen this work less well where we need to collaborate in a short period of time to achieve a result of predictably high quality (Wikinews), or where we're working over long periods of time on a result with (perceived or actual) limited usefulness until it is complete (Wikibooks). I'm not saying this is inherent in volunteer mass collaboration, or that these challenges are insurmountable, just that a) tools and practices of volunteer collaboration tend to support self-selected long-term incrementalism better than, shall we say, strategic megaprojects, b) we're not necessarily even using all the tools and practices yet that other volunteer projects successfully employ to tackle strategic challenges. 2) Widening gap between staff and volunteer contributions: As the Wikimedia Foundation began to professionalize, it initially moved its focus away from some of the early experiments in volunteer mobilization (such as the 2006 Wikimedia Foundation committees), and moved instead towards employing and tasking WMF staff for each critical work area. Much of 2008 was spent for this new team to get its feet on the ground and get oriented in the world of Wikimedia, to the detriment of developing new structures for volunteer engagement. The strategic planning process launched in 2009 was, from the beginning, conceptualized to mobilize the Wikimedia community in collecting ideas and planning its own future, and has achieved unprecedented volunteer participation in doing so. We're now shifting towards using the StrategyWiki to help volunteers in efforts to self-organize around particular issues, whether the WMF is giving attention to them or not -- we'll be posting more about that soon, and I'm pretty excited about it. At the same time, when tackling large scale strategic projects like the usability initiative or the bookshelf, I do believe we haven't yet succeeded at forming the most productive collaborative relationship possible with the larger volunteer community. I should note that we haven't even fully succeeded at closing the gap between staff and contractors based in San Francisco, and those who are not -- we have a long way to go. The staff/volunteer gap is evident when looking at the commit history of the UsabilityInitiative codebase, for example, which is very much dominated by WMF staff and contractors. (The notable exception, as for all our code, is localization -- again a great example for self-selected incrementalism.) It's also evident in the recent conflict between a staff and a volunteer developer regarding the language link issue, and in our overall conversation about that same issue. 3) Closing the gap and overcoming cognitive biases: I do think it's possible and necessary to close that gap. I think doing so has to _start_ with discussion, but ultimately to me this isn't so much about conversation, but about actual real-world collaboration with practical results -- we want to get stuff done together, and we're all working towards the same vision. To do so, I think we have to be wary of our respective cognitive biases and operate with the highest possible degree of self-awareness. I find the framework of cognitive bias personally very helpful when I assess my own actions, and the list on Wikipedia ( http://en.wikipedia.org/wiki/List_of_cognitive_biases ) is a good starting point. I believe we've seen some examples of biases listed there in both WMF staff and volunteer actions, such as: * belief that the group you're a member of is diverse, whereas other groups are not ("the staff does/is X", "the community doesn't have the expertise to do Y") ; * preferential treatment of people perceived to be members of the same group, and the associated us vs. them dynamic; * irrational escalation (tendency to defend an investment based on cumulative prior commitment) and the bandwagon effect (tendency to join the belief of others). These and other biases contribute to unhealthy spirals of escalation. There's a big picture of clear alignment of values and interests: we've all committed ourselves to a very important mission, and we have seen time and again that we can work together immensely successfully in doing so. Fundamentally, I think it's the group division that's the most important to overcome -- inside the Wikimedia movement, but also towards readers and "outsiders." WMF absolutely has been both part of the problem, and part of efforts to solve it. I entirely agree that we need to steer clear of unhealthy power dynamics. Wikipedia editing is not a tyranny of the majority or the minority, and nor is our engineering and design process -- ideally, the best arguments, the best code and the best edits should prevail. I'm glad that the BOLD, revert, discuss cycle -- http://en.wikipedia.org/wiki/Wikipedia:BOLD,_revert,_discuss_cycle -- was invoked in prior threads, which I think is a generally sensible framework through which we get stuff done. It's not the only framework, but it's one that we (should) stick to wherever reasonably possible. To the extent that there is an irrational status quo bias, I think the best way to overcome it is for us to engage the largest possible number of people in bringing about and advocating on behalf of positive changes. With all this in mind, here are just a few concrete ideas for closing the gap: 1) Embedding teams funded by WMF into larger, publicly visible workgroups which include volunteers and which meet regularly e.g. via IRC; 1 a) Outreach to grow and strengthen those workgroups with the best skills present in the Wikimedia volunteer community; 2) Publication of mini-projects which we identify and which can be tackled by self-organized volunteers, with mentoring by experienced WMF staff and volunteers (happening a bit via GSoC, but not as much outside of it yet); 3) Making development roadmaps fully transparent and open to discussion, and sharing justifications for all key priorities; 4) Further iteration of tools and processes for rapid volunteer-driven bug reporting, cross-browser testing, and submission of simple patches; 5) Stimulating larger scale contests focusing on specific areas of interest; 6) More topic-focused meetings and sprints like the multimedia usability meeting in Paris. 7) Further experimentation with tools like IdeaTorrent for large-scale brainstorming and ranking purposes (we have a prototype running at http://prototype.wikimedia.org/en-idea/ideatorrent/ ). The Wikimedia Foundation regards these as crucial questions, and we've had many conversations about them, both internally and publicly. I hope these conversations will continue to broaden. I personally intend to work especially on 3) in the list above, and want to help establish 1) as a normal practice in key WMF program activities. Howie has started a general brainstorming page here, where I've reposted the above: http://usability.wikimedia.org/wiki/Product_Development_Process_Ideas I hope you'll join me in adding to that list, and that we continue to hold each other to the idea of building true and genuinely open forms of collaboration, which is one of the most important cornerstones of the Wikimedia movement. All best, Erik -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

18 29

[Foundation-l] Vector improves the visibility of interwikis, reader said
by Federico Leva (Nemo) 11 Jun '10

11 Jun '10

«You're marvellous. I've particularly appreciated the languages menu and I think that in the future it will be even more important (Indian, Chinese etc.).» Funny feedback from a reader here: http://it.wikipedia.org/w/index.php?title=Progetto:Coordinamento/Usabilit%C… Apparently he has discovered interwikis thanks to Vector (maybe because of less clutter in the sidebar?)... Nemo

2 1

[Foundation-l] Fwd: change of registered TMs in Persian wikipedia
by Ryan Lomonaco 11 Jun '10

11 Jun '10

Forwarded on behalf of a non-list-member. The question pertains to translation of trademarks within articles; to my knowledge, there's nothing wrong with us doing so, and I think this is done in many Wikipedias. But I'll defer to the list on this question. ---------- Forwarded message ---------- From: Amir sarabadani <ladsgroup(a)gmail.com> Date: Tue, Jun 8, 2010 at 3:58 PM Subject: change of registered TMs in Persian wikipedia To: foundation-l-owner(a)lists.wikimedia.org Hello, I'm one of Persian wikipedia users.for making pages same name of trademarks (e.g. films ,games.etc.) we have several choices: 1-we use same name and same alphabetical with trademark(e.g. Google-->Google) 2-we same name but Persian Script(e.g. Call of duty-->کال آو دیوتی/KAL AV DIUTI/) 3-we translate it(Prince of Persian-->شاهزاده ایرانی /SHAHZADE IRANI means Prince of Persia) Users of Persian wikipedia (with consequence) use third way usually but I think change of trademarks is crime and maybe create legal problem for the Foundation Please tell us what we do or maybe i think wrong please tell me. Thanks and best wishes -- Amir

5 4

[Foundation-l] Collapsed galleries for particularly explicit images
by Andreas Kolbe 11 Jun '10

11 Jun '10

There is currently a discussion at the en:WP content noticeboard whether we could or should 1. Use collapsed galleries for particularly graphic sexual images (requiring the reader to click "Show" to see the content) 2. Display them openly, as has been normal practice so far 3. Dispense with images and just add a link to a relevant Commons category. I've come across examples of collapsed images in other language versions of Wikipedia recently, and it seems to me that is an option we could pursue in en:WP as well, in cases where the content is particularly graphic. If you have views on this, please contribute to the discussion.[1] On a related point, I've seen people argue recently that we shouldn't be applying a double standard of explicitness to sexually explicit images and images of explicit violence, such as those displayed in the en:WP article on the My Lai massacre.[2] The gist of the argument is that it reflects badly on us if we are fine with images of explicit violence but somehow cannot stand the sight of explicit images of sexuality, which is after all a normal and essential part of human existence. I see some merit in that argument, as far as it goes, but it seems to me it misses a key difference in the social functions of images of sexuality vs. those of images of violence. Images of violence like the ones in the My Lai article document human suffering. Such images have historically been shown to be key factors in mobilising public opinion and political action to reduce or end such suffering. There is a genuine, vital public interest at stake. Sexually explicit images on the other hand, like those included in our en:WP articles on cock and ball torture[3] or hogtie bondage[4], illustrate practices that individuals engage in of their own free will, in their private leisure time. So while both types of images are explicit (and I wouldn't completely rule out collapsing a particularly gruesome war image), I think the two cases, and the purposes explicitness serves in each case, have far more to set them apart than they have in common. Andreas [1] http://en.wikipedia.org/wiki/Wikipedia:Content_noticeboard#Cock_and_ball_to… [2] http://en.wikipedia.org/wiki/My_Lai_Massacre [3] http://en.wikipedia.org/wiki/Cock_and_ball_torture_(sexual_practice) [4] http://en.wikipedia.org/wiki/Hogtie_bondage

3 3

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Wikimedia-l June 2010