Dear Wikimedians,
We are excited to have you participate in an important Community Engagement
regarding our strategic approaches. This is a major step to help us
prioritize the work of the Foundation beginning in July 2016 and running
for the next 12 to 24 months thereafter into a strategic plan.
Throughout 2015 the Foundation has been exploring how to prioritize its
work to best support the movement's goals, set forth, but not yet reached,
in the 2010-15 strategic plan.
The strategic approaches presented here are based on our vision, strategy
consultations in 2010 <https://meta.wikimedia.org/wiki/Strategy/2010-2015>
and 2015
<https://meta.wikimedia.org/wiki/2015_Strategy/Community_consultation>,
research on external impacts, and input from staff and a few small
community think groups on key challenges and potential solutions.
Timeline: These are our target dates for this process.
-
January 11: Put up pages for translation (done)
-
January 18: Launch of community consultation on key questions
-
February 15: Close of consultation
-
By February 26: Release synthesis of consultation
-
By March 4: Publish first draft strategy for comment
We appreciate your time and efforts to help guide the Foundation in its
work to support the movement.
Warm regards,
Lila
TL;DR
Can anyone suggest of a better way of publicly logging thanks, hellos
& goodbyes for our public email lists?
BACKGROUND
Wikimedia lists are probably unique in the number of emails over a
year which 'thankspam'. For example there is a pattern set that an
awful lot of chapter representatives send public welcomes and goodbyes
without conveying any new information. Sometimes when my email
notifier shows about ten of these on the same day, I've made the
effort to block that thread, I don't know of a way of specifically
muting the notifications for these types of emails on my mobile phone.
Though everyone could chose to send these privately rather than making
a public statement, I understand the motivation for "us too"s to be
noticed by others who are not the intended 'thanked'. On email lists
something like ensuring thank email subject lines have a formulaic
part of the title would help, so that readers can choose to mute them;
equivalent to marking "minor" or "bot" edits on our projects so they
don't get flagged in recent changes.
This thought stirred by Ad's email, but not against the sentiment he
was aiming for.
PS For those that recall my meta thanks reports, I hope to get this
online again soon once a related phabricator task is resolved.
Fae
On 13 January 2016 at 09:21, Ad Huikeshoven <ad(a)wikimedia.nl> wrote:
...
> I failed to welcome incoming directors to the board of the Wikimedia
> Foundation and I failed to thank outgoing directors of the same board for
> the time and effort they have spent.
>
> - that you are sorry about the harm/damage/waste/confusion your mistake
> caused (being specific would demonstrate understanding);
>
> I'm sorry for this unpolite and rude behavior.
...
--
faewik(a)gmail.com https://commons.wikimedia.org/wiki/User:Fae
Hello everyone,
I am pleased to announce the Steward Elections 2016 [1]. We are now taking
nominations from eligible candidates. Interested candidates can check their
eligibility and procedure to submit the nomination on the guidelines page
[2]. We are open to candidate submissions till January 28, 2016, 23:59
(UTC). Questions to the candidates can be submitted until February 6, 2016,
23:59 (UTC). Guidelines about questioning can also be found on our
guidelines page [2].
As always, the confirmation of existing stewards [3] will take place at the
same time as the election, which begins on February 8, and will finish on
February 27, 2016.
Please remember, the voting has not yet begun and will be not until
February 8, 2016, 00:00 (UTC). We will poke you once again when the voting
starts.
As you all know steward elections are a global event, so we need help from
volunteers to translate necessary pages into languages they speak. For
those who want to help us out with translation, please see our translation
portal [4]. And if you have any queries related to translation or anything
related to the election, you can ask us on the talk page [5]. Alternatively
you are free to poke us in the freenode IRC channel
#wikimedia-stewards-elections.
Please feel free to forward this e-mail to any list if you think it will be
useful.
Regards,
Shanmugam Pachamuthu
(On behalf of the Election Committee.)
[1] https://meta.wikimedia.org/wiki/Stewards/Elections_2016
[2] https://meta.wikimedia.org/wiki/Stewards/Elections_2016/Guidelines
[3] https://meta.wikimedia.org/wiki/Stewards/Confirm/2016
[4]
https://meta.wikimedia.org/wiki/Stewards/Elections_2016/Coordination#Transl…
[5] https://meta.wikimedia.org/wiki/Talk:Stewards/Elections_2016
Hi!
Please see below the reply by Rob from MusicBrainz (forwarding because
he is not on the mailing list):
> On Jan 17, 2016, at 04:51, Mitar <mmitar(a)gmail.com> wrote:
>
> I would suggest that anyone interested in monetizing APIs check how
> MusicBrainz (https://musicbrainz.org/) is doing it.
>
> An open encyclopedia for music metadata. Their data is all open,
> collaboratively made, and APIs are free to use, but big users are
> asked to pay. In this way they are getting money from Google, for
> example. You should contact them and check how they feel about issues
> raised here: Do they feel that they get strings attached for receiving
> money from Google? How do their contributors feel about them getting
> money in this way? How do they achieve that big players pay, but
> community projects, researchers, and others do not? What is the
> process to determine that? In fact, I am CCing Rob from MusicBrainz
> here.
Hello!
I wanted to give you an update on our business model, since we pivoted
on that back in May. If this sounds bad, it isn't -- we're actually
following along the path that Creative Commons has envisioned for
people using their licenses. For over 10 years we used Creative
Commons licenses to determine if people should or should not pay us
for the data they use in their business. That got us to $250k/year and
then we leveled off. (This is akin to an aspiring CC artist releasing
their content as they work to become known).
But then there comes a point when the business/aspiring artist can
stand on its/their own and start making its/their own rules. And this
is where we've arrived now -- today we have a support model where
people who make commercial use of our data are encouraged to support
us. There is no requirement for supporting us, but we're quick to
point out that a company that makes financial gains using our data
really ought to give something back to us in order for us to keep the
lights on and improve what we do.
And, this is working! Have a look at our growing list of supporters:
https://metabrainz.org/supporters
The only major music tech company left that isn't supporting us is
Apple and maybe SoundCloud, but they are on my hit list for this year.
Have a look at the tiers of support we setup:
https://metabrainz.org/supporters/account-type
Note that the tiers have guidelines that are a vague suggestion of
data usage and company size. While people get an idea what "support"
means, it isn't fully clear, so most will sign up as "stealth
start-up", which is great, because it lets us start a conversation
about their data use. In the course of the conversation we can
determine a fair level of support that suits the company's current
needs and ability to pay. Note that we hardly talk about "products" in
this case anymore -- we don't really care how people use our data.
(I've long joked about us operating under a drug dealer business
model, that "the first one is free". But, really, this is exactly what
we're doing. Lots of companies got hooked on our data and now we're
looping around asking for support)
I hope this makes sense -- if not, hit me up for questions!
--
--ruaok Excel is not a database!
Robert Kaye -- rob(a)musicbrainz.org -- http://musicbrainz.org
--
http://mitar.tnode.com/https://twitter.com/mitar_m
Hi everyone,
Splitting the thread off to avoid hijacking it
On Mon, Jan 18, 2016 at 9:50 AM, Mitar <mmitar(a)gmail.com> wrote:
> I think this conversation is diverging from the question of the
> *service* we should offer to others to licensing of the content.
> Licensing does not say anything about the service one should offer for
> the content. Any service, any API, is more or less something one does
> extra on top of the licensing requirements. We could just offer dumps
> of data and this is it. But if we offer more, some specialized
> services, uptime and availability and so on, that does not have much
> with the licensing of the content. That discussion should thus be on
> some other layer. Investigating licensing will not give us much
> insight into the question if we should go into the business of
> offering data services or not.
I think this is a useful way of thinking about the problem. One thing we
discussed quite a bit at the Wikimedia Developer Summit earlier this month
is the distinction between the content format (see "content format" <
https://phabricator.wikimedia.org/T119022>) and the APIs that we use to
access the content (see "content access": <
https://phabricator.wikimedia.org/T119029>).
The two are incredibly easy to conflate, in part because one could argue
that the content format is merely a translatable expression of the
underlying data model. That said, it seems to me that we have to stop
abstracting things *somewhere*, to avoid getting deeply lost in too many
layers of abstraction. If nothing else, we need a "free format" per the
Free Content definition (<http://freedomdefined.org/>).
Mitar, is your layer distinction between "service" and "content" the same
one that I'm trying to draw between "content format" and "content access"?
I have further thoughts on this, but I just want to make sure we're talking
about the same distinction.
Rob
I'm interested to hear some perspectives on the following line of thinking:
Lisa presented some alternative strategies for revenue needs for the
Foundation, including the possibility of charging for premium access to the
services and APIs, expanding major donor and foundation fundraising,
providing specific services for a fee, or limiting the Wikimedia
Foundation's growth. The Board emphasized the importance of keeping free
access to the existing APIs and services, keeping operational growth in
line with the organization's effectiveness, providing room for innovation
in the Foundation's activities, and other potential fundraising strategies.
The Board asked Lila to analyze and develop some of these potential
strategies for further discussion at a Board meeting in 2016.
Source: https://wikimediafoundation.org/wiki/Minutes/2015-11-07
-Pete[[User:Peteforsyth]]
Hello Everyone,
I have proposed a new Wikimedia project on Meta. I hope you guys can take a look and give your views.
https://meta.wikimedia.org/wiki/Wikilore
Regards
Satdeep Gill
