There's a great opportunity before us. If licensing and copyright are
complex, the Commons community should be the best at explaining these
concepts simply.
One of my favorite examples in this area is what 500px does to explain
their terms, privacy policy, and Creative Commons. If they can do this, so
can we.
https://500px.com/terms
Yours,
Chris Koerner
clkoerner.com
Hi,
I would like to ask, if the ease of media handling (images, photographs on
Wikimedia Commons) is a priority for Wikimedia Foundation? If not, could it
be a priority? Recently we have seen a big step done for editors =
VisualEditor. Contributors have no longer study "wikicode" to be able to
contribute. That removes one of the technological barriers and it looks its
a priority for WMF.
While part of contributing to Wikipedia is still contributing by images. I
am from Wikimedia Czech republic. We run many projects based on media
harvest or organizing *low barrier media harvest activities* to bring new
users to Wikipedia.
As our newbies are not technologically skilled and not native English
speakers, there is a big technology block to contribute to Wikipedia with
ease:
1) there is no app for mobile phones and tablets for image upload
2) newbies are lost, when they click on "Upload image" and they are
transferred from Wikipedia to Wikimedia Commons
3) Wikimedia Commons is in English - foreign language for our participants
4) biggest language barrier are categories, which are in English only, we
need to insert name of the category in our mother tongue
5) Wikimedia Commons environment is still pretty "techy"
6) Insert metadata, takes a long time:
e.g.: you have an image of a cathedral in Des Moines, IW. 3 or 4 times you
have to insert same information: a) to file name (*Des Moines,
cathedral.jpg*), b) to file description (*en:** Cathedral in Des Moines,
Iowa, USA*/*es:* *La catedral de XY en Des Moines, Iowa, EEUU*) and c) to
the category (*category:Des Moines* or *Churches in Des Moines*,
*category:Cathedrals
in Iowa*).
Its 2015, there are many social projects around us. You can handle images
much easier on these projects than on mother of all social projects -
Wikipedia. Big step was done with using images allready present in Commons.
Could we do something for those, who contributes with their media to
Wikipedia? Could we do it in one or two years?
Thank you very much for your concern!
Regards,
Juandev
Dear Wikimedia friends and partners,
We have just published our FDC progress report for the first half of
2015. It’s a quite lengthy document, so I would like to highlight some
shared learning for the Free Knowledge movement that we present in
this report.
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikim…
We have published several learning patterns and material, for example
on participation in post-conference surveys, crowd-funding campaign,
recording audio samples, relationships with donors, and sharing
information with the movement:
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikim…
The grant report for the Wikimedia Conference 2015 includes a lot of
lessons learnt that can also be applied to other movement events:
https://meta.wikimedia.org/wiki/Grants:PEG/WM_DE/Wikimedia_Conference_2015/…https://meta.wikimedia.org/wiki/Wikimedia_Conference_2015/Feedback_evaluati…
The committee that was tasked with the transition of our Executive
Director reported on their process and provides advice for similar
processes in other organisations, no matter if big or small:
https://meta.wikimedia.org/wiki/Wikimedia_Deutschland/Transition_Team/Execu…
Our annual compass 2016 provides WMDE with vision and direction for
the upcoming planning process and lists new volunteers, software
development and public policy as the three priorities for our work in
2016:
https://meta.wikimedia.org/wiki/Wikimedia_Deutschland/PP16/Kompass/en
If you have questions or feedback, please do not hesitate to reach out
to us. You can either engage via the respective talk pages or directly
with the contact persons involved. If you are not sure whom to best
reach out to, get in touch with me and I will connect you.
Nicole
--
Nicole Ebber
Vorstandsreferentin Internationale Beziehungen
Adviser to the ED, International Relations
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0 | http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.
V. Eingetragen im Vereinsregister des Amtsgerichts
Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig
anerkannt durch das Finanzamt für Körperschaften I Berlin,
Steuernummer 27/681/51985.
If Harald Bischoff has defrauded Commons reusers by requiring stricter
attribution than the community requires, does the Foundation have standing
in Germany to require him to return the money to his victims in proportion
to the extent that their attribution was improper?
On 16 June 2015 at 02:53, Derk-Jan Hartman <d.j.hartman+wmf_ml(a)gmail.com>
wrote:
>
https://lists.wikimedia.org/pipermail/foundation-l/2010-December/063225.html
>
> I just found back this post by David Gerard from 2010 and was struck by
how
> dead-on the discussion and analysis was and how far we have actually come
> with VE 5 years later, even though we still did not pass the finish line
just
> yet.
Yes, I agree. I think there's a lot of interesting areas we can consider
for VisualEditor as a technology, and more importantly "editing" as an
area; thank you for raising this. :-)
> Also interesting is some of the follow up to it, which points out that the
> usability of Templates is also a real problem in itself, not easily
solvable
> with WYSIWYG, but probably just as important.
>
> I think VE is really close now to being usable in production, but I think
> that we are FAR from done on this front. Like was stated, templates are a
> real problem. A UI problem, and one that VE doesn't really solve. Citoid
> sort of does, but just for one small subset of templates.
Agreed. There are several layers of answer to this question, precisely as
you say based on what levels of vision we're trying to achieve. Here is
mine (TL;DR: lots to do):
Mostly this comes down to what templates (and now of course, Lua) are used
for. My mental categories are:
1. Standardised "workflow" notices – "this needs a reference", "this
article is poorly written", "this list needs expanding", "this file should
be expanded", "please delete this page", "this page is protected", "this
suggested edit needs reviewing", "please don't edit this discussion because
it's archived", "I am warning you not to be disruptive in your editing or
you will be in trouble", "this user is blocked", etc.
2. Standardised visual formatting of content – citations (templated
references), infoboxen, stub notices, succession boxes, media licensing
data, Wiktionary's etymology templates, Wikisource' and so on.
3. Standardised conversion or expansion of content – unit conversion, date
conversion, links to sister project pages on the same title, annotation
markup (e.g. setting lang="fr" around some content, or marking it up with
hCard data; adding an HTML anchor to the page; etc.).
4. Standardised fetching of content – we frequently pull images from
Commons (and people don't even think of it as fetching content); beyond
that it's not yet hugely common, though some infoboxes for example pull
data from Wikidata.
5. Un"standardised" sharing of identical content blocks (the original
intent for templates) – most often used as "navboxes", and sadly sometimes
also used to hide complex wikitext e.g. for infoboxes or graphs from the
"regular" users who might break it, which speaks to how much VisualEditor
is needed.
Of course, to make things 'easier' a lot of templates do multiple versions
of these, and/or are parameterised to do almost the same thing but slightly
differently based on some of the inputs (e.g. a species infobox which adds
a 'fix me' category, sets a different background colour if the status is
'endangered', pulls three of its values from Wikidata, and converts range
from hectares to square kilometres). There's also meta-templates for other
templates like notices, but I'll ignore those for now. :-)
My broad attitude is that the need for the first four of these categories
can be replaced by real software support; the need for the fifth is not
something I foresee a better solution for than community-shared templates,
though I'm willing to be proven wrong.
I understand that everything I mentioned in group one (workflow stuff) is
potentially in scope for the work that the
excellent
Collaboration team are
considering
as part of Flow (hence the name). No doubt it
could
also cover a number of areas of work of which I cannot yet conceive; this
is how templates themselves have grown from their original intent into the
sprawling, complicated and confusing morass that they are today. This
workflow stuff is
deeply hard to get right, however, and I've seen how badly doing workflows
in systems can destroy the communities, so I imagine this will move slowly.
For many of the use cases in groups two and three (visual and
machine-readable formatting/re-formatting), I think that broad swathes of
our content uses
of templates
would be
better
supported through use-specific systems at three levels:
* structured – storing information in a proper, machine-readable manner,
with a single way of both storing and representing the same information for
all instances on that wiki, but differing between wikis;
* standardised – the above, with the harmonisation of the structure and use
of that content type across all Wikimedia wikis; and
* centralised – the above, with all the content stored on one central
'wiki' (or whatever) rather than local versions of the content.
For example, references are currently semi-structured on many wikis using
citation templates; storing this in structured data is a clearly useful
step, and it's probable that setting a single standard for all our wikis to
say what meta-data about a reference is worthwhile, but I am not completely
sold on the idea of having this data stored on a single new "Wikicite" or
whatever project.
For another example, infoboxes are currently subject to significant
editorial discretion on the per-page level, and with sub-wiki variance on
themes (e.g. a standard for infoboxes about military battles might exclude
information that infoboxes about political uprisings would consider vital,
and vice versa), let alone when comparing between wikis. Though I think
there is likely to be a lot of value in sharing the structure to represent
the layout of what should be shown
, this would be something of a departure for the level of freedom our
different pages' editors have compared to the wikiprojects or wiki
communities that would define them.
As a final example, factual data makes total sense to be centralised,
rather than just standardised – which is good, because this already
underway doing that with Wikidata. :-) Note that "data" potentially goes so
far as the scope of Wiktionary, Wikiquote and possibly even Wikisource,
though each of these are worth very serious conversations and planning. The
fetching and display of the data might well need software support and
configuration on a per-wiki or per-language basis. For example, for Chinese
language readers it might make sense to represent distances in 里
automatically converted from metres; for American English readers, show the
dates the 'wrong' way around (;-)); for some readers, the ordering of the
cases for nouns might be varied based on what they'd expect (so accusative,
genitive, dative and then ablative for some readers but accusative, dative
and then genitive for others); for some language Wikipedias, it might be
felt important to highlight someone's political affiliation in a different
way in an infobox based on what the community decide is the 'right' manner
to explain things to their users. No doubt dozens of other specialisations
can be dreamt up.
For items in group four, we probably can fold these uses into the automatic
uses discussed above in many cases, and for others we already have the
means to embed them using wikitext directly for media (as is now old-hat)
and data (as the Wikidata team have and continue to develop access tools).
I'm not sure there's much to do here, except note that as VisualEditor
becomes more widespread we may find that we need to use templates less to
hide the intricacies of wikitext from errant users, because everyone except
the die-hard might be avoiding needing to look directly at the wikitext.
We'll see.
> I think it is important to remember that VE is a framework. The piece that
> will open up other possibilities, but that we will need to still do a lot
of
> work to find what those possibilities are, how they can make page and
> article authoring more usable etc...
>
> The post starts with a quote of Fred Bauder:
> | "There has to be a vision though"
>
> So I'm asking: What is the vision for this next step ?
> - What ideas do people have with regard to usability and templates.
> - What examples of good editors can we find that also deal with templates/
> objects etc.
> - What are our unique challenges ?
> - What kind of research and development would be needed to deliver this ?
>
> I would love it if we could end up with a discussion and summary as we had
> back then. A guide for us towards solving this next problem within another
> 5 years. We and the WMF can probably not start on this tomorrow, but we
can
> start thinking about it.
There are a number of changes we can make that seem obvious, but I worry
that are anti-patterns which would embed current thinking at a cost of
making progress harder, or less appealing in the short term.
For instance, we could add an extra "insert clean-up template" button in
the VisualEditor toolbar with five or six specialist (per-wiki) tools to
insert {{cn}} or {{wikify}} or whatever. See
https://phabricator.wikimedia.org/T55590 for some discussion of this.
Making this configurable, scalable and yet sane is a lot of work, and
immediately appealing – but I fear it would be solving the wrong thing, and
doing so in a way that distracts us from the end-goal.
Another superficially attractive, and oft-discussed, piece of work is
"global templates". I worry that these would very much try to expand the
symptom rather than solving the problem, making simplicity of understand
how things work and the flexibility to change them ever further out of
reach for all but a few of our editing communities.
The overall vision might even be right, but it's only worthwhile if we turn
it into reality. Certainly, I don't have a magic bullet. It's going to take
a huge amount of careful thought and discussion on each of the three dozen
or so proposals I implied above, and it's a worthy challenge, I think.
Thoughts?
J.
--
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester