Re: [Wikimedia-l] Any perspective from Wikimedia Movement about the copyright refined

[Raymond Leonard]

I think that the gist of the article, "UK Intellectual Property Office:
what is in the Public Domain must stay in the Public Domain" is similar to
the principle that Commons operates on, as noted in this wording:

"Exception: Faithful reproductions of two-dimensional works of art, such as
paintings, which are in the public domain are an exception to this rule. In
July 2008, following a statement clarifying WMF policy, Commons voted to
the effect that all such photographs are accepted as public domain
regardless of country of origin, and tagged with a warning. For details,
see Commons:Policy on photographs of old pictures."
Source: Commons:Licensing#Interaction of US and non-US copyright law
https://commons.wikimedia.org/wiki/Commons:Licensing#Interaction_of_US_and_non-US_copyright_law

See also: Commons:When to use the PD-Art tag (Redirected from
Commons:Policy on photographs of old pictures)
https://commons.wikimedia.org/wiki/Commons:When_to_use_the_PD-Art_tag

Yours,
Peaceray

On Tue, Dec 15, 2015 at 4:41 AM, Liang-chih Shang Kuan <
shangkua...@gmail.com> wrote:

> Please refer to this link,
> http://www.communia-association.org/2015/12/04/1761/ .
>
> Sounds like a more restricted condition for copyright holder. I am
> wondering is there any feedback from WMF or the UK chapter?
>
>
> Liang
> ___
> 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] [Wmfall] Community Wishlist Survey: Top 10 wishes!

[Pharos]

Looks wonderful, this is a model to build upon in future.

Thanks,
Pharos

On Wed, Dec 16, 2015 at 3:18 PM, Wes Moran  wrote:

> Great work and a nice process.
>
> On Wed, Dec 16, 2015 at 3:12 PM, Danny Horn  wrote:
>
> > Hi everyone,
> >
> > I'm happy to announce that the Community Tech team's Community Wishlist
> > Survey has concluded, and we're able to announce the top 10 wishes!
> >
> > 634 people participated in the survey, where they proposed, discussed and
> > voted on 107 ideas. There was a two-week period in November to submit and
> > endorse proposals, followed by two weeks of voting. The top 10 proposals
> > with the most support votes now become the Community Tech team's backlog
> of
> > projects to evaluate and address.
> >
> > And here's the top 10:
> >
> > #1. Migrate dead links to the Wayback Machine  (111 support votes)
> > #2. Improved diff compare screen  (104)
> > #3. Central global repository for templates, gadgets and Lua modules
> (87)
> > #4. Cross-wiki watchlist  (84)
> > #4. Numerical sorting in categories  (84)
> > #6. Allow categories in Commons in all languages  (78)
> > #7. Pageview Stats tool  (70)
> > #8. Global cross-wiki user talk page  (66)
> > #9. Improve the "copy and paste detection" bot  (63)
> > #10. Add a user watchlist  (62)
> >
> > You can see the whole list here, with links to all the proposals and
> > Phabricator tickets:
> > https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
> >
> > So what happens now?
> >
> > Over the next couple weeks, Community Tech will do a preliminary
> > assessment on the top 10, and start figuring out what's involved. We need
> > to have a clear definition of the problem and proposed solution, and
> begin
> > to understand the technical, design and community challenges for each
> one.
> >
> > Some wishes in the top 10 seem relatively straightforward, and we'll be
> > able to dig in and start working on them in the new year. Some wishes are
> > going to need a lot of investigation and discussion with other
> developers,
> > product teams, designers and community members. There may be some that
> are
> > just too big or too hard to do at all.
> >
> > Our analysis will look at the following factors:
> >
> > * SUPPORT: Overall support for the proposal, including the discussions on
> > the survey page. This will take the neutral and oppose votes into
> account.
> > Some of these ideas also have a rich history of discussions on-wiki and
> in
> > bug tickets. For some wishes, we'll need more community discussion to
> help
> > define the problem and agree on proposed solutions.
> >
> > * FEASIBILITY: How much work is involved, including existing blockers and
> > dependencies.
> >
> > * IMPACT: Evaluating how many projects and contributors will benefit,
> > whether it's a long-lasting solution or a temporary fix, and the
> > improvement in contributors' overall productivity and happiness.
> >
> > * RISK: Potential drawbacks, conflicts with other developers' work, and
> > negative effects on any group of contributors.
> >
> > Our plan for 2016 is to complete as many of the top 10 wishes as we can.
> > For the wishes in the top 10 that we can't complete, we're responsible
> for
> > investigating them fully and reporting back on the analysis.
> >
> > So there's going to be a series of checkpoints through the year, where
> > we'll present the current status of the top 10 wishes. The first will be
> at
> > the Wikimedia Developer Summit in the first week of January. We're
> planning
> > to talk about the preliminary assessment there, and then share it more
> > widely.
> >
> > If you're eager to follow the whole process as we go along, we'll be
> > documenting and keeping notes in two places:
> >
> > On Meta: 2015 Community Wishlist Survey/Top 10:
> > https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Top_10
> >
> > On Phabricator: Community Wishlist Survey board:
> > https://phabricator.wikimedia.org/tag/community-wishlist-survey/
> >
> > Finally: What about the other 97 proposals?
> >
> > There were a lot of good and important proposals that didn't happen to
> get
> > quite as many support votes, and I'm sure everybody has at least one that
> > they were rooting for. Again, the whole list is here:
> >
> > https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
> >
> > We're going to talk with the other Wikimedia product teams, to see if
> they
> > can take on some of the ideas the the community has expressed interest
> in.
> > We're also going to work with the Developer Relations team to see if some
> > of these could be taken on by volunteer developers.
> >
> > It's also possible that Community Tech could take on a small-scale,
> > well-defined proposal below the top 10, if it doesn't interfere with our
> > commitments to the top 10 wishes.
> >
> > So there's lots of work to be done, and hooray, we have a whole year to
> do
> > it. If this process turns out 

Re: [Wikimedia-l] [Wmfall] Community Wishlist Survey: Top 10 wishes!

[Wes Moran]

Great work and a nice process.

On Wed, Dec 16, 2015 at 3:12 PM, Danny Horn  wrote:

> Hi everyone,
>
> I'm happy to announce that the Community Tech team's Community Wishlist
> Survey has concluded, and we're able to announce the top 10 wishes!
>
> 634 people participated in the survey, where they proposed, discussed and
> voted on 107 ideas. There was a two-week period in November to submit and
> endorse proposals, followed by two weeks of voting. The top 10 proposals
> with the most support votes now become the Community Tech team's backlog of
> projects to evaluate and address.
>
> And here's the top 10:
>
> #1. Migrate dead links to the Wayback Machine  (111 support votes)
> #2. Improved diff compare screen  (104)
> #3. Central global repository for templates, gadgets and Lua modules  (87)
> #4. Cross-wiki watchlist  (84)
> #4. Numerical sorting in categories  (84)
> #6. Allow categories in Commons in all languages  (78)
> #7. Pageview Stats tool  (70)
> #8. Global cross-wiki user talk page  (66)
> #9. Improve the "copy and paste detection" bot  (63)
> #10. Add a user watchlist  (62)
>
> You can see the whole list here, with links to all the proposals and
> Phabricator tickets:
> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
>
> So what happens now?
>
> Over the next couple weeks, Community Tech will do a preliminary
> assessment on the top 10, and start figuring out what's involved. We need
> to have a clear definition of the problem and proposed solution, and begin
> to understand the technical, design and community challenges for each one.
>
> Some wishes in the top 10 seem relatively straightforward, and we'll be
> able to dig in and start working on them in the new year. Some wishes are
> going to need a lot of investigation and discussion with other developers,
> product teams, designers and community members. There may be some that are
> just too big or too hard to do at all.
>
> Our analysis will look at the following factors:
>
> * SUPPORT: Overall support for the proposal, including the discussions on
> the survey page. This will take the neutral and oppose votes into account.
> Some of these ideas also have a rich history of discussions on-wiki and in
> bug tickets. For some wishes, we'll need more community discussion to help
> define the problem and agree on proposed solutions.
>
> * FEASIBILITY: How much work is involved, including existing blockers and
> dependencies.
>
> * IMPACT: Evaluating how many projects and contributors will benefit,
> whether it's a long-lasting solution or a temporary fix, and the
> improvement in contributors' overall productivity and happiness.
>
> * RISK: Potential drawbacks, conflicts with other developers' work, and
> negative effects on any group of contributors.
>
> Our plan for 2016 is to complete as many of the top 10 wishes as we can.
> For the wishes in the top 10 that we can't complete, we're responsible for
> investigating them fully and reporting back on the analysis.
>
> So there's going to be a series of checkpoints through the year, where
> we'll present the current status of the top 10 wishes. The first will be at
> the Wikimedia Developer Summit in the first week of January. We're planning
> to talk about the preliminary assessment there, and then share it more
> widely.
>
> If you're eager to follow the whole process as we go along, we'll be
> documenting and keeping notes in two places:
>
> On Meta: 2015 Community Wishlist Survey/Top 10:
> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Top_10
>
> On Phabricator: Community Wishlist Survey board:
> https://phabricator.wikimedia.org/tag/community-wishlist-survey/
>
> Finally: What about the other 97 proposals?
>
> There were a lot of good and important proposals that didn't happen to get
> quite as many support votes, and I'm sure everybody has at least one that
> they were rooting for. Again, the whole list is here:
>
> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
>
> We're going to talk with the other Wikimedia product teams, to see if they
> can take on some of the ideas the the community has expressed interest in.
> We're also going to work with the Developer Relations team to see if some
> of these could be taken on by volunteer developers.
>
> It's also possible that Community Tech could take on a small-scale,
> well-defined proposal below the top 10, if it doesn't interfere with our
> commitments to the top 10 wishes.
>
> So there's lots of work to be done, and hooray, we have a whole year to do
> it. If this process turns out to be a success, then we plan to do another
> survey at the end of 2016, to give more people a chance to participate, and
> bring more great ideas.
>
> For everybody who proposed, endorsed, discussed, debated and voted in the
> survey, as well as everyone who said nice things to us recently: thank you
> very much for coming out and supporting live feature development. We're
> 

Re: [Wikimedia-l] [Wmfall] Community Wishlist Survey: Top 10 wishes!

[Anna Stillwell]

Amaze balls.
/a

On Wed, Dec 16, 2015 at 12:12 PM, Danny Horn  wrote:

> Hi everyone,
>
> I'm happy to announce that the Community Tech team's Community Wishlist
> Survey has concluded, and we're able to announce the top 10 wishes!
>
> 634 people participated in the survey, where they proposed, discussed and
> voted on 107 ideas. There was a two-week period in November to submit and
> endorse proposals, followed by two weeks of voting. The top 10 proposals
> with the most support votes now become the Community Tech team's backlog of
> projects to evaluate and address.
>
> And here's the top 10:
>
> #1. Migrate dead links to the Wayback Machine  (111 support votes)
> #2. Improved diff compare screen  (104)
> #3. Central global repository for templates, gadgets and Lua modules  (87)
> #4. Cross-wiki watchlist  (84)
> #4. Numerical sorting in categories  (84)
> #6. Allow categories in Commons in all languages  (78)
> #7. Pageview Stats tool  (70)
> #8. Global cross-wiki user talk page  (66)
> #9. Improve the "copy and paste detection" bot  (63)
> #10. Add a user watchlist  (62)
>
> You can see the whole list here, with links to all the proposals and
> Phabricator tickets:
> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
>
> So what happens now?
>
> Over the next couple weeks, Community Tech will do a preliminary
> assessment on the top 10, and start figuring out what's involved. We need
> to have a clear definition of the problem and proposed solution, and begin
> to understand the technical, design and community challenges for each one.
>
> Some wishes in the top 10 seem relatively straightforward, and we'll be
> able to dig in and start working on them in the new year. Some wishes are
> going to need a lot of investigation and discussion with other developers,
> product teams, designers and community members. There may be some that are
> just too big or too hard to do at all.
>
> Our analysis will look at the following factors:
>
> * SUPPORT: Overall support for the proposal, including the discussions on
> the survey page. This will take the neutral and oppose votes into account.
> Some of these ideas also have a rich history of discussions on-wiki and in
> bug tickets. For some wishes, we'll need more community discussion to help
> define the problem and agree on proposed solutions.
>
> * FEASIBILITY: How much work is involved, including existing blockers and
> dependencies.
>
> * IMPACT: Evaluating how many projects and contributors will benefit,
> whether it's a long-lasting solution or a temporary fix, and the
> improvement in contributors' overall productivity and happiness.
>
> * RISK: Potential drawbacks, conflicts with other developers' work, and
> negative effects on any group of contributors.
>
> Our plan for 2016 is to complete as many of the top 10 wishes as we can.
> For the wishes in the top 10 that we can't complete, we're responsible for
> investigating them fully and reporting back on the analysis.
>
> So there's going to be a series of checkpoints through the year, where
> we'll present the current status of the top 10 wishes. The first will be at
> the Wikimedia Developer Summit in the first week of January. We're planning
> to talk about the preliminary assessment there, and then share it more
> widely.
>
> If you're eager to follow the whole process as we go along, we'll be
> documenting and keeping notes in two places:
>
> On Meta: 2015 Community Wishlist Survey/Top 10:
> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Top_10
>
> On Phabricator: Community Wishlist Survey board:
> https://phabricator.wikimedia.org/tag/community-wishlist-survey/
>
> Finally: What about the other 97 proposals?
>
> There were a lot of good and important proposals that didn't happen to get
> quite as many support votes, and I'm sure everybody has at least one that
> they were rooting for. Again, the whole list is here:
>
> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
>
> We're going to talk with the other Wikimedia product teams, to see if they
> can take on some of the ideas the the community has expressed interest in.
> We're also going to work with the Developer Relations team to see if some
> of these could be taken on by volunteer developers.
>
> It's also possible that Community Tech could take on a small-scale,
> well-defined proposal below the top 10, if it doesn't interfere with our
> commitments to the top 10 wishes.
>
> So there's lots of work to be done, and hooray, we have a whole year to do
> it. If this process turns out to be a success, then we plan to do another
> survey at the end of 2016, to give more people a chance to participate, and
> bring more great ideas.
>
> For everybody who proposed, endorsed, discussed, debated and voted in the
> survey, as well as everyone who said nice things to us recently: thank you
> very much for coming out and supporting live feature development. We're
> excited about 

[Wikimedia-l] Community Wishlist Survey: Top 10 wishes!

[Danny Horn]

Hi everyone,

I'm happy to announce that the Community Tech team's Community Wishlist
Survey has concluded, and we're able to announce the top 10 wishes!

634 people participated in the survey, where they proposed, discussed and
voted on 107 ideas. There was a two-week period in November to submit and
endorse proposals, followed by two weeks of voting. The top 10 proposals
with the most support votes now become the Community Tech team's backlog of
projects to evaluate and address.

And here's the top 10:

#1. Migrate dead links to the Wayback Machine  (111 support votes)
#2. Improved diff compare screen  (104)
#3. Central global repository for templates, gadgets and Lua modules  (87)
#4. Cross-wiki watchlist  (84)
#4. Numerical sorting in categories  (84)
#6. Allow categories in Commons in all languages  (78)
#7. Pageview Stats tool  (70)
#8. Global cross-wiki user talk page  (66)
#9. Improve the "copy and paste detection" bot  (63)
#10. Add a user watchlist  (62)

You can see the whole list here, with links to all the proposals and
Phabricator tickets:
https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results

So what happens now?

Over the next couple weeks, Community Tech will do a preliminary assessment
on the top 10, and start figuring out what's involved. We need to have a
clear definition of the problem and proposed solution, and begin to
understand the technical, design and community challenges for each one.

Some wishes in the top 10 seem relatively straightforward, and we'll be
able to dig in and start working on them in the new year. Some wishes are
going to need a lot of investigation and discussion with other developers,
product teams, designers and community members. There may be some that are
just too big or too hard to do at all.

Our analysis will look at the following factors:

* SUPPORT: Overall support for the proposal, including the discussions on
the survey page. This will take the neutral and oppose votes into account.
Some of these ideas also have a rich history of discussions on-wiki and in
bug tickets. For some wishes, we'll need more community discussion to help
define the problem and agree on proposed solutions.

* FEASIBILITY: How much work is involved, including existing blockers and
dependencies.

* IMPACT: Evaluating how many projects and contributors will benefit,
whether it's a long-lasting solution or a temporary fix, and the
improvement in contributors' overall productivity and happiness.

* RISK: Potential drawbacks, conflicts with other developers' work, and
negative effects on any group of contributors.

Our plan for 2016 is to complete as many of the top 10 wishes as we can.
For the wishes in the top 10 that we can't complete, we're responsible for
investigating them fully and reporting back on the analysis.

So there's going to be a series of checkpoints through the year, where
we'll present the current status of the top 10 wishes. The first will be at
the Wikimedia Developer Summit in the first week of January. We're planning
to talk about the preliminary assessment there, and then share it more
widely.

If you're eager to follow the whole process as we go along, we'll be
documenting and keeping notes in two places:

On Meta: 2015 Community Wishlist Survey/Top 10:
https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Top_10

On Phabricator: Community Wishlist Survey board:
https://phabricator.wikimedia.org/tag/community-wishlist-survey/

Finally: What about the other 97 proposals?

There were a lot of good and important proposals that didn't happen to get
quite as many support votes, and I'm sure everybody has at least one that
they were rooting for. Again, the whole list is here:

https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results

We're going to talk with the other Wikimedia product teams, to see if they
can take on some of the ideas the the community has expressed interest in.
We're also going to work with the Developer Relations team to see if some
of these could be taken on by volunteer developers.

It's also possible that Community Tech could take on a small-scale,
well-defined proposal below the top 10, if it doesn't interfere with our
commitments to the top 10 wishes.

So there's lots of work to be done, and hooray, we have a whole year to do
it. If this process turns out to be a success, then we plan to do another
survey at the end of 2016, to give more people a chance to participate, and
bring more great ideas.

For everybody who proposed, endorsed, discussed, debated and voted in the
survey, as well as everyone who said nice things to us recently: thank you
very much for coming out and supporting live feature development. We're
excited about the work ahead of us.

We'd also like to thank Wikimedia Deutschland's Technischer Communitybedarf
team -- they came up with this whole survey process, and they've been
working successfully on lots of community wishes since their first survey
in 2013.

You can watch this 

Re: [Wikimedia-l] [Wmfall] Community Wishlist Survey: Top 10 wishes!

[Pine W]

Thank you Danny & Company!

Pine

On Wed, Dec 16, 2015 at 12:22 PM, Toby Negrin  wrote:

> No one asked for 10 more wishes? :)
>
> Thanks Danny and the Community Tech team. This is a great model for working
> with our Communities.
>
> -Toby
>
> On Wed, Dec 16, 2015 at 12:18 PM, Nirzar Pangarkar <
> npangar...@wikimedia.org
> > wrote:
>
> > It's really cool to see community wish list coming together!
> >
> > > We're going to talk with the other Wikimedia product teams, to see if
> > they can take on some of the ideas the the community has expressed
> interest
> > in.
> >
> > +1
> >
> > On Thu, Dec 17, 2015 at 1:42 AM, Danny Horn  wrote:
> >
> >> Hi everyone,
> >>
> >> I'm happy to announce that the Community Tech team's Community Wishlist
> >> Survey has concluded, and we're able to announce the top 10 wishes!
> >>
> >> 634 people participated in the survey, where they proposed, discussed
> and
> >> voted on 107 ideas. There was a two-week period in November to submit
> and
> >> endorse proposals, followed by two weeks of voting. The top 10 proposals
> >> with the most support votes now become the Community Tech team's
> backlog of
> >> projects to evaluate and address.
> >>
> >> And here's the top 10:
> >>
> >> #1. Migrate dead links to the Wayback Machine  (111 support votes)
> >> #2. Improved diff compare screen  (104)
> >> #3. Central global repository for templates, gadgets and Lua modules
> (87)
> >> #4. Cross-wiki watchlist  (84)
> >> #4. Numerical sorting in categories  (84)
> >> #6. Allow categories in Commons in all languages  (78)
> >> #7. Pageview Stats tool  (70)
> >> #8. Global cross-wiki user talk page  (66)
> >> #9. Improve the "copy and paste detection" bot  (63)
> >> #10. Add a user watchlist  (62)
> >>
> >> You can see the whole list here, with links to all the proposals and
> >> Phabricator tickets:
> >> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
> >>
> >> So what happens now?
> >>
> >> Over the next couple weeks, Community Tech will do a preliminary
> >> assessment on the top 10, and start figuring out what's involved. We
> need
> >> to have a clear definition of the problem and proposed solution, and
> begin
> >> to understand the technical, design and community challenges for each
> one.
> >>
> >> Some wishes in the top 10 seem relatively straightforward, and we'll be
> >> able to dig in and start working on them in the new year. Some wishes
> are
> >> going to need a lot of investigation and discussion with other
> developers,
> >> product teams, designers and community members. There may be some that
> are
> >> just too big or too hard to do at all.
> >>
> >> Our analysis will look at the following factors:
> >>
> >> * SUPPORT: Overall support for the proposal, including the discussions
> on
> >> the survey page. This will take the neutral and oppose votes into
> account.
> >> Some of these ideas also have a rich history of discussions on-wiki and
> in
> >> bug tickets. For some wishes, we'll need more community discussion to
> help
> >> define the problem and agree on proposed solutions.
> >>
> >> * FEASIBILITY: How much work is involved, including existing blockers
> and
> >> dependencies.
> >>
> >> * IMPACT: Evaluating how many projects and contributors will benefit,
> >> whether it's a long-lasting solution or a temporary fix, and the
> >> improvement in contributors' overall productivity and happiness.
> >>
> >> * RISK: Potential drawbacks, conflicts with other developers' work, and
> >> negative effects on any group of contributors.
> >>
> >> Our plan for 2016 is to complete as many of the top 10 wishes as we can.
> >> For the wishes in the top 10 that we can't complete, we're responsible
> for
> >> investigating them fully and reporting back on the analysis.
> >>
> >> So there's going to be a series of checkpoints through the year, where
> >> we'll present the current status of the top 10 wishes. The first will
> be at
> >> the Wikimedia Developer Summit in the first week of January. We're
> planning
> >> to talk about the preliminary assessment there, and then share it more
> >> widely.
> >>
> >> If you're eager to follow the whole process as we go along, we'll be
> >> documenting and keeping notes in two places:
> >>
> >> On Meta: 2015 Community Wishlist Survey/Top 10:
> >> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Top_10
> >>
> >> On Phabricator: Community Wishlist Survey board:
> >> https://phabricator.wikimedia.org/tag/community-wishlist-survey/
> >>
> >> Finally: What about the other 97 proposals?
> >>
> >> There were a lot of good and important proposals that didn't happen to
> >> get quite as many support votes, and I'm sure everybody has at least one
> >> that they were rooting for. Again, the whole list is here:
> >>
> >> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
> >>
> >> We're going to talk with the other Wikimedia product teams, to see if
> 

Re: [Wikimedia-l] [Wmfall] Community Wishlist Survey: Top 10 wishes!

[Yuri Astrakhan]

>
> #3. Central global repository for templates, gadgets and Lua modules  (87)
>

I would love to participate in this - I feel it would bring different
language communities much closer together.  And great for Graphs & Maps.


> #7. Pageview Stats tool  (70)
>

We could even do it on-wiki like here
 - it shows
how to draw a graph from pageviews API, and this graph extension
 can add
HTML controls to it.

Awesome list, thanks for getting more community involvement!
___
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] [Wmfall] Community Wishlist Survey: Top 10 wishes!

[Risker]

Thanks, Danny - this looks like a pretty good list.

Every one of the top-10 proposals is worthwhile all by itself, and a couple
of them have the potential to have multi-project effects; I'm not
suggesting that they be set aside.  However, I'd like to suggest that at
the next selection process, a slot be specifically reserved for a project
on one of the less populous projects.  The system of selecting the most
popular options almost guarantees that something to improve (for example)
Wikisource or Wiktionary will be an also-ran, simply because there aren't
enough members of those specialized communities to out-vote the really
popular things from Wikipedia. This can lead to the circular effect of
small projects having a hard time expanding their community because of
technical weaknesses which don't get fixed because there isn't a big enough
community to vote to get them to the top of the community tech wishlist...

Nonetheless, this is a great first attempt at actively involving
communities in determining priorities for this specific WMF team. I hope
that the WMF staff involved have also felt the process was worthwhile, and
I'll really be looking forward to the viability assessments.

Risker/Anne

On 16 December 2015 at 15:22, Toby Negrin  wrote:

> No one asked for 10 more wishes? :)
>
> Thanks Danny and the Community Tech team. This is a great model for working
> with our Communities.
>
> -Toby
>
> On Wed, Dec 16, 2015 at 12:18 PM, Nirzar Pangarkar <
> npangar...@wikimedia.org
> > wrote:
>
> > It's really cool to see community wish list coming together!
> >
> > > We're going to talk with the other Wikimedia product teams, to see if
> > they can take on some of the ideas the the community has expressed
> interest
> > in.
> >
> > +1
> >
> > On Thu, Dec 17, 2015 at 1:42 AM, Danny Horn  wrote:
> >
> >> Hi everyone,
> >>
> >> I'm happy to announce that the Community Tech team's Community Wishlist
> >> Survey has concluded, and we're able to announce the top 10 wishes!
> >>
> >> 634 people participated in the survey, where they proposed, discussed
> and
> >> voted on 107 ideas. There was a two-week period in November to submit
> and
> >> endorse proposals, followed by two weeks of voting. The top 10 proposals
> >> with the most support votes now become the Community Tech team's
> backlog of
> >> projects to evaluate and address.
> >>
> >> And here's the top 10:
> >>
> >> #1. Migrate dead links to the Wayback Machine  (111 support votes)
> >> #2. Improved diff compare screen  (104)
> >> #3. Central global repository for templates, gadgets and Lua modules
> (87)
> >> #4. Cross-wiki watchlist  (84)
> >> #4. Numerical sorting in categories  (84)
> >> #6. Allow categories in Commons in all languages  (78)
> >> #7. Pageview Stats tool  (70)
> >> #8. Global cross-wiki user talk page  (66)
> >> #9. Improve the "copy and paste detection" bot  (63)
> >> #10. Add a user watchlist  (62)
> >>
> >> You can see the whole list here, with links to all the proposals and
> >> Phabricator tickets:
> >> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
> >>
> >> So what happens now?
> >>
> >> Over the next couple weeks, Community Tech will do a preliminary
> >> assessment on the top 10, and start figuring out what's involved. We
> need
> >> to have a clear definition of the problem and proposed solution, and
> begin
> >> to understand the technical, design and community challenges for each
> one.
> >>
> >> Some wishes in the top 10 seem relatively straightforward, and we'll be
> >> able to dig in and start working on them in the new year. Some wishes
> are
> >> going to need a lot of investigation and discussion with other
> developers,
> >> product teams, designers and community members. There may be some that
> are
> >> just too big or too hard to do at all.
> >>
> >> Our analysis will look at the following factors:
> >>
> >> * SUPPORT: Overall support for the proposal, including the discussions
> on
> >> the survey page. This will take the neutral and oppose votes into
> account.
> >> Some of these ideas also have a rich history of discussions on-wiki and
> in
> >> bug tickets. For some wishes, we'll need more community discussion to
> help
> >> define the problem and agree on proposed solutions.
> >>
> >> * FEASIBILITY: How much work is involved, including existing blockers
> and
> >> dependencies.
> >>
> >> * IMPACT: Evaluating how many projects and contributors will benefit,
> >> whether it's a long-lasting solution or a temporary fix, and the
> >> improvement in contributors' overall productivity and happiness.
> >>
> >> * RISK: Potential drawbacks, conflicts with other developers' work, and
> >> negative effects on any group of contributors.
> >>
> >> Our plan for 2016 is to complete as many of the top 10 wishes as we can.
> >> For the wishes in the top 10 that we can't complete, we're responsible
> for
> >> investigating them fully and reporting back on the 

Re: [Wikimedia-l] [Wmfall] Community Wishlist Survey: Top 10 wishes!

[Danny Horn]

Yeah, we've been thinking about the best way to support the smaller
projects. For this first survey, we wanted to see what happened when we
just open the voting as wide as we can, and encourage people from smaller
projects to participate and spread the word.

The Wikisource community did a tremendous job in showing up and giving
support to the Wikisource proposals. The top wishes in that category got 41
and 39 votes, which is really impressive considering the relative size of
the projects.

The discussion on using Google's OCR in Indic language Wikisource is
especially interesting -- a lively debate about finding the right solution
to what is clearly a deeply-felt need from a community that's working
really hard to add their languages' knowledge to the movement. I hope that
having that debate here is a step towards a larger discussion about how we
can support Wikisource projects.



On Wed, Dec 16, 2015 at 12:39 PM, Risker  wrote:

> Thanks, Danny - this looks like a pretty good list.
>
> Every one of the top-10 proposals is worthwhile all by itself, and a couple
> of them have the potential to have multi-project effects; I'm not
> suggesting that they be set aside.  However, I'd like to suggest that at
> the next selection process, a slot be specifically reserved for a project
> on one of the less populous projects.  The system of selecting the most
> popular options almost guarantees that something to improve (for example)
> Wikisource or Wiktionary will be an also-ran, simply because there aren't
> enough members of those specialized communities to out-vote the really
> popular things from Wikipedia. This can lead to the circular effect of
> small projects having a hard time expanding their community because of
> technical weaknesses which don't get fixed because there isn't a big enough
> community to vote to get them to the top of the community tech wishlist...
>
> Nonetheless, this is a great first attempt at actively involving
> communities in determining priorities for this specific WMF team. I hope
> that the WMF staff involved have also felt the process was worthwhile, and
> I'll really be looking forward to the viability assessments.
>
> Risker/Anne
>
> On 16 December 2015 at 15:22, Toby Negrin  wrote:
>
> > No one asked for 10 more wishes? :)
> >
> > Thanks Danny and the Community Tech team. This is a great model for
> working
> > with our Communities.
> >
> > -Toby
> >
> > On Wed, Dec 16, 2015 at 12:18 PM, Nirzar Pangarkar <
> > npangar...@wikimedia.org
> > > wrote:
> >
> > > It's really cool to see community wish list coming together!
> > >
> > > > We're going to talk with the other Wikimedia product teams, to see if
> > > they can take on some of the ideas the the community has expressed
> > interest
> > > in.
> > >
> > > +1
> > >
> > > On Thu, Dec 17, 2015 at 1:42 AM, Danny Horn 
> wrote:
> > >
> > >> Hi everyone,
> > >>
> > >> I'm happy to announce that the Community Tech team's Community
> Wishlist
> > >> Survey has concluded, and we're able to announce the top 10 wishes!
> > >>
> > >> 634 people participated in the survey, where they proposed, discussed
> > and
> > >> voted on 107 ideas. There was a two-week period in November to submit
> > and
> > >> endorse proposals, followed by two weeks of voting. The top 10
> proposals
> > >> with the most support votes now become the Community Tech team's
> > backlog of
> > >> projects to evaluate and address.
> > >>
> > >> And here's the top 10:
> > >>
> > >> #1. Migrate dead links to the Wayback Machine  (111 support votes)
> > >> #2. Improved diff compare screen  (104)
> > >> #3. Central global repository for templates, gadgets and Lua modules
> > (87)
> > >> #4. Cross-wiki watchlist  (84)
> > >> #4. Numerical sorting in categories  (84)
> > >> #6. Allow categories in Commons in all languages  (78)
> > >> #7. Pageview Stats tool  (70)
> > >> #8. Global cross-wiki user talk page  (66)
> > >> #9. Improve the "copy and paste detection" bot  (63)
> > >> #10. Add a user watchlist  (62)
> > >>
> > >> You can see the whole list here, with links to all the proposals and
> > >> Phabricator tickets:
> > >>
> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
> > >>
> > >> So what happens now?
> > >>
> > >> Over the next couple weeks, Community Tech will do a preliminary
> > >> assessment on the top 10, and start figuring out what's involved. We
> > need
> > >> to have a clear definition of the problem and proposed solution, and
> > begin
> > >> to understand the technical, design and community challenges for each
> > one.
> > >>
> > >> Some wishes in the top 10 seem relatively straightforward, and we'll
> be
> > >> able to dig in and start working on them in the new year. Some wishes
> > are
> > >> going to need a lot of investigation and discussion with other
> > developers,
> > >> product teams, designers and community members. There may be some that
> > are
> > >> 

[Wikimedia-l] WMCON16 out of office announcement

[Daniela Gentner]

Dear Wikimedians,

In view of the upcoming holidays, we would like to inform you that the
Wikimedia Conference 2016 organizing team will be out of the office
from December 23, 2015 until January 11, 2016.

If you need assistance or have any questions, we recommend you to
contact us until December 21, 2015. Otherwise we will respond to your
emails as soon as possible upon our return.

We will do our best to send the documents which are needed for the
visa application process to everyone who registers until Thursday,
December 17, 2015 11:59 p.m. (Central European Time). Should you
register after this deadline, we will prepare and send the documents
to you as soon as possible after our return in January (~January 15,
2016).

If your affiliation is eligible to attend the conference and you have
been selected to be your affiliate’s delegate, then please be kindly
reminded to register until Friday, January 15, 2016. Please be aware
that only registered participants are allowed to attend the Wikimedia
Conference. You can register via the following link:

https://meta.wikimedia.org/wiki/Wikimedia_Conference_2016/Registration#Registration_link


All the best,

Wenke & Daniela


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!
http://spenden.wikimedia.de/

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.

___
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] Fundraising banner (again)

[Anna Stillwell]

+1

On Tue, Dec 15, 2015 at 7:31 PM, Pine W  wrote:

> I like the new mini banner: "Find what you're looking for? Keep Wikipedia
> thriving." (:
>
> 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,
> 
>



-- 
Anna Stillwell
Major Gifts Officer
Wikimedia Foundation
415.806.1536
*www.wikimediafoundation.org *
___
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] Community Wishlist Survey: Top 10 wishes!

[Richard Ames]

This thread (subject) looks like it could bring lots of different thoughts,
ideas, suggestions, etc.

Please (Please, Please) --- if your message is mainly on a new topic /
thought / etc; Send a new message, with a new subject line.

Thank you, Richard.
___
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] [Wmfall] Community Wishlist Survey: Top 10 wishes!

[James Heilman]

Great to see this :-) The community tech team is an amazing initiative. And
agree all items listed have the potential to have significant impact.

-- 
James Heilman
MD, CCFP-EM, Wikipedian

The Wikipedia Open Textbook of Medicine
www.opentextbookofmedicine.com

As of July 2015 I am a board member of the Wikimedia Foundation
My emails; however, do not represent the official position of the WMF
___
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] Community Wishlist Survey: Top 10 wishes!

[Bodhisattwa Mandal]

Danny,

First of all, thanks for your comments on Wikisource community wishlist
survey. Though we are a small global community, we did our best to get our
basic problems noticed.

To my opinion, the current system of Community wishlist survey is not good
enough to solve the problems of Wikimedia sister projects like Wikisource.
As very few volunteers work on Wikisource globally, it is very difficult to
compete with Wikipedia or Commons proposals because obviously Wikisource
proposals will not get as much votes as they do.

The concept of top 10 wishes is great! But in addition, if there is a
provision to include at least top 2 wishes of each of the sister projects,
then personally I can say that it can be an effective measure to uplift
these projects. Andrea already said in the previous mail that, Wikisource
software support is totally provided by volunteers alone right from the
beginning and not WMF and that's a real issue for us.

Regards,
Bodhisattwa

On 17 Dec 2015 03:32, "Richard Ames"  wrote:
>
> This thread (subject) looks like it could bring lots of different
thoughts,
> ideas, suggestions, etc.
>
> Please (Please, Please) --- if your message is mainly on a new topic /
> thought / etc; Send a new message, with a new subject line.
>
> Thank you, Richard.
> ___
> 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] Community Wishlist Survey: Top 10 wishes!

[Lane Rasberry]

Wow!

I have strong opinions about everything on this list and apparently so do
many other people.

It was fun to participate in the proposal process.

If any of these proposals are not feasible to develop then I would enjoy
reading a short explanation explaining why from the perspective of a
developer to a layman audience.

The entire list seems like magic to me - it is so many things that I want.

yours,


On Wed, Dec 16, 2015 at 8:24 PM, Sam Klein  wrote:

> Thanks to all for organizing the survey and for sharing!
>
> A lot of these should help people stay in touch on smaller wikis and
> sibling projects where they are less active (and currently less likely to
> see pings and messages), so while I also want to see wikisource take over
> the world, these seem like great choices.
>
> It's wonderful to see a cross-organization collaboration topping the list.
>
> Slow migration back to a single unified namespace:
> #3. Central global repository for templates, gadgets and Lua
> #4. Cross-wiki watchlist
> #8. Cross-wiki user talkpage
>
> And a mentor-friendly feature I've wanted for a long time:
> #10. Add a user watchlist
>
> SJ
>
>
> On Wed, Dec 16, 2015 at 3:12 PM, Danny Horn  wrote:
>
> > Hi everyone,
> >
> > I'm happy to announce that the Community Tech team's Community Wishlist
> > Survey has concluded, and we're able to announce the top 10 wishes!
> >
> > 634 people participated in the survey, where they proposed, discussed and
> > voted on 107 ideas. There was a two-week period in November to submit and
> > endorse proposals, followed by two weeks of voting. The top 10 proposals
> > with the most support votes now become the Community Tech team's backlog
> of
> > projects to evaluate and address.
> >
> > And here's the top 10:
> >
> > #1. Migrate dead links to the Wayback Machine  (111 support votes)
> > #2. Improved diff compare screen  (104)
> > #3. Central global repository for templates, gadgets and Lua modules
> (87)
> > #4. Cross-wiki watchlist  (84)
> > #4. Numerical sorting in categories  (84)
> > #6. Allow categories in Commons in all languages  (78)
> > #7. Pageview Stats tool  (70)
> > #8. Global cross-wiki user talk page  (66)
> > #9. Improve the "copy and paste detection" bot  (63)
> > #10. Add a user watchlist  (62)
> >
> > You can see the whole list here, with links to all the proposals and
> > Phabricator tickets:
> > https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
> >
> > So what happens now?
> >
> > Over the next couple weeks, Community Tech will do a preliminary
> assessment
> > on the top 10, and start figuring out what's involved. We need to have a
> > clear definition of the problem and proposed solution, and begin to
> > understand the technical, design and community challenges for each one.
> >
> > Some wishes in the top 10 seem relatively straightforward, and we'll be
> > able to dig in and start working on them in the new year. Some wishes are
> > going to need a lot of investigation and discussion with other
> developers,
> > product teams, designers and community members. There may be some that
> are
> > just too big or too hard to do at all.
> >
> > Our analysis will look at the following factors:
> >
> > * SUPPORT: Overall support for the proposal, including the discussions on
> > the survey page. This will take the neutral and oppose votes into
> account.
> > Some of these ideas also have a rich history of discussions on-wiki and
> in
> > bug tickets. For some wishes, we'll need more community discussion to
> help
> > define the problem and agree on proposed solutions.
> >
> > * FEASIBILITY: How much work is involved, including existing blockers and
> > dependencies.
> >
> > * IMPACT: Evaluating how many projects and contributors will benefit,
> > whether it's a long-lasting solution or a temporary fix, and the
> > improvement in contributors' overall productivity and happiness.
> >
> > * RISK: Potential drawbacks, conflicts with other developers' work, and
> > negative effects on any group of contributors.
> >
> > Our plan for 2016 is to complete as many of the top 10 wishes as we can.
> > For the wishes in the top 10 that we can't complete, we're responsible
> for
> > investigating them fully and reporting back on the analysis.
> >
> > So there's going to be a series of checkpoints through the year, where
> > we'll present the current status of the top 10 wishes. The first will be
> at
> > the Wikimedia Developer Summit in the first week of January. We're
> planning
> > to talk about the preliminary assessment there, and then share it more
> > widely.
> >
> > If you're eager to follow the whole process as we go along, we'll be
> > documenting and keeping notes in two places:
> >
> > On Meta: 2015 Community Wishlist Survey/Top 10:
> > https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Top_10
> >
> > On Phabricator: Community Wishlist Survey board:
> > 

[Wikimedia-l] Wikisource technical issues (was Community Wishlist Survey: Top 10 wishes!)

[Andrea Zanni]

(splitting as per Richard request)

> Question for the Wikisource folks: would Project Grants be a way to get
> resources for you? If you can design a project and find people with the
> right skills, that avenue might be beneficial for you. I have a software
> developer in mind who would probably like to work with you if resources
are
> available and a project has the support of the community and WMF.
>
> Pine

Hi Pine. My personal answer to your question is: no. Because we've already
tried that, and we did barely scratch the surface of the issues.
I'm on mobile and cannot provide you details and references, but in the
past years we used both IEG and Google Summer of Code for funding
developers, and we had few successinaddressing main issues. Also, tools
that worked and were helpful are now abandoned.
What wikisource lacks is development to core software, not only external,
cool tools, which are fine but in the end don't really solve problems.

I can elaborate further and bore you with details but, ina nutshell, we
just need  commitment from people who can bring theirlines ofcode into
production. As Wikisource is formally a Wikimedia project, and provides its
tiny contribution to the mission and also to fundraising, I would expect a
commitment of this sort coming from WMF.

Aubrey




> ___
> 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] Community Wishlist Survey: Top 10 wishes!

[Sam Klein]

Thanks to all for organizing the survey and for sharing!

A lot of these should help people stay in touch on smaller wikis and
sibling projects where they are less active (and currently less likely to
see pings and messages), so while I also want to see wikisource take over
the world, these seem like great choices.

It's wonderful to see a cross-organization collaboration topping the list.

Slow migration back to a single unified namespace:
#3. Central global repository for templates, gadgets and Lua
#4. Cross-wiki watchlist
#8. Cross-wiki user talkpage

And a mentor-friendly feature I've wanted for a long time:
#10. Add a user watchlist

SJ


On Wed, Dec 16, 2015 at 3:12 PM, Danny Horn  wrote:

> Hi everyone,
>
> I'm happy to announce that the Community Tech team's Community Wishlist
> Survey has concluded, and we're able to announce the top 10 wishes!
>
> 634 people participated in the survey, where they proposed, discussed and
> voted on 107 ideas. There was a two-week period in November to submit and
> endorse proposals, followed by two weeks of voting. The top 10 proposals
> with the most support votes now become the Community Tech team's backlog of
> projects to evaluate and address.
>
> And here's the top 10:
>
> #1. Migrate dead links to the Wayback Machine  (111 support votes)
> #2. Improved diff compare screen  (104)
> #3. Central global repository for templates, gadgets and Lua modules  (87)
> #4. Cross-wiki watchlist  (84)
> #4. Numerical sorting in categories  (84)
> #6. Allow categories in Commons in all languages  (78)
> #7. Pageview Stats tool  (70)
> #8. Global cross-wiki user talk page  (66)
> #9. Improve the "copy and paste detection" bot  (63)
> #10. Add a user watchlist  (62)
>
> You can see the whole list here, with links to all the proposals and
> Phabricator tickets:
> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
>
> So what happens now?
>
> Over the next couple weeks, Community Tech will do a preliminary assessment
> on the top 10, and start figuring out what's involved. We need to have a
> clear definition of the problem and proposed solution, and begin to
> understand the technical, design and community challenges for each one.
>
> Some wishes in the top 10 seem relatively straightforward, and we'll be
> able to dig in and start working on them in the new year. Some wishes are
> going to need a lot of investigation and discussion with other developers,
> product teams, designers and community members. There may be some that are
> just too big or too hard to do at all.
>
> Our analysis will look at the following factors:
>
> * SUPPORT: Overall support for the proposal, including the discussions on
> the survey page. This will take the neutral and oppose votes into account.
> Some of these ideas also have a rich history of discussions on-wiki and in
> bug tickets. For some wishes, we'll need more community discussion to help
> define the problem and agree on proposed solutions.
>
> * FEASIBILITY: How much work is involved, including existing blockers and
> dependencies.
>
> * IMPACT: Evaluating how many projects and contributors will benefit,
> whether it's a long-lasting solution or a temporary fix, and the
> improvement in contributors' overall productivity and happiness.
>
> * RISK: Potential drawbacks, conflicts with other developers' work, and
> negative effects on any group of contributors.
>
> Our plan for 2016 is to complete as many of the top 10 wishes as we can.
> For the wishes in the top 10 that we can't complete, we're responsible for
> investigating them fully and reporting back on the analysis.
>
> So there's going to be a series of checkpoints through the year, where
> we'll present the current status of the top 10 wishes. The first will be at
> the Wikimedia Developer Summit in the first week of January. We're planning
> to talk about the preliminary assessment there, and then share it more
> widely.
>
> If you're eager to follow the whole process as we go along, we'll be
> documenting and keeping notes in two places:
>
> On Meta: 2015 Community Wishlist Survey/Top 10:
> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Top_10
>
> On Phabricator: Community Wishlist Survey board:
> https://phabricator.wikimedia.org/tag/community-wishlist-survey/
>
> Finally: What about the other 97 proposals?
>
> There were a lot of good and important proposals that didn't happen to get
> quite as many support votes, and I'm sure everybody has at least one that
> they were rooting for. Again, the whole list is here:
>
> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
>
> We're going to talk with the other Wikimedia product teams, to see if they
> can take on some of the ideas the the community has expressed interest in.
> We're also going to work with the Developer Relations team to see if some
> of these could be taken on by volunteer developers.
>
> It's also possible that Community Tech could take 

Re: [Wikimedia-l] Community Wishlist Survey: Top 10 wishes!

[Pine W]

Question for the Wikisource folks: would Project Grants be a way to get
resources for you? If you can design a project and find people with the
right skills, that avenue might be beneficial for you. I have a software
developer in mind who would probably like to work with you if resources are
available and a project has the support of the community and 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, 

Re: [Wikimedia-l] Quality issues

[Jane Darnell]

OK I see now what you mean, and that is an interesting point. I think in
this context you need to see the objections to the "Bonnie and Clyde"
problem. Now that we have exploded the concepts of Wikipedia into items,
our interlinking (which is what Wikidata was built for) is a bit less
tightly knit than it was. Some would argue that it's a good thing because
we have fewer unresolvable interwiki links and others would argue it's a
bad thing because they have less opportunity to redirect readers to
material on other projects. Most recently this has come up in the
discussions around structured data for commons, but early adopters noticed
it immediately in the interlanguage links. The only way forward (or
backward, depending on your point of view) is to explode the Wikipedias in
a similar way. So for example I like to work on 17th-century paintings and
sometimes they are interesting because of their subjects, and sometimes
they are interesting because of their provenance, but rarely both, so
Wikipedia articles generally deal with both. On Wikidata we will often have
items for both (the portrait and the portrayed; or a landscape and the
objects depicted in that landscape) and the interwikis link accordingly,
which means some interwikis disappear because one language Wikipedia
article is talking about the person while another language Wikipedia
article is talking about the painting, and so forth. I guess for Wikisource
it's similar with "Wikisource editions of biographies of people" vs. items
about actual people.


On Wed, Dec 16, 2015 at 12:12 PM, Andrea Zanni 
wrote:

> On Sun, Dec 13, 2015 at 9:35 PM, Jane Darnell  wrote:
>
> > Andrea,
> > I totally agree on the mission/vision thing, but am not sure what you
> mean
> > exactly by scale - do you mean that Wikidata shouldn't try to be so
> > granular that it has a statement to cover each factoid in any Wikipedia
> > article, or do you mean we need to talk about what constitutes notability
> > in order not to grow Wikidata exponentially to the point the servers
> crash?
> > Jane
> >
> >
> Hi Jane, I explained myself poorly (sometime English is too difficult :-)
>
> What I mean is that the scale of the error *could* be of another scale,
> another order of magnitude.
> The propagation of the error is multiplied, it's not just a single error on
> a wikipage: it's an error propagated in many wikipages, and then Google,
> etc.
> A single point of failure.
>
> Of course, the opposite is also true: it's a single point of openness,
> correction, information.
> I was just wondering if this different scale is a factor in making
> Wikipedia and Wikidata different enough to accept/reject Andreas arguments.
>
> Andrea
>
>
>
> > On Sun, Dec 13, 2015 at 7:10 PM, Andrea Zanni 
> > wrote:
> >
> > > I really feel we are drowning in a glass of water.
> > > The issue of "data quality" or "reliability" that Andreas raises is
> well
> > > known:
> > > what I don't understand if the "scale" of it is much bigger on Wikidata
> > > than Wikipedia,
> > > and if this different scale makes it much more important. The scale of
> > the
> > > issue is maybe something worth discussing, and not the issue itself? Is
> > the
> > > fact that Wikidata is centralised different from statements on
> > Wikipedia? I
> > > don't know, but to me this is a more neutral and interesting question.
> > >
> > > I often say that the Wikimedia world made quality an "heisemberghian"
> > > feature: you always have to check if it's there.
> > > The point is: it's been always like this.
> > > We always had to check for quality, even when we used Britannica or
> > > authority controls or whatever "reliable" sources we wanted. Wikipedia,
> > and
> > > now Wikidata, is made for everyone to contribute, it's open and honest
> in
> > > being open, vulnerable, prone to errors. But we are transparent, we say
> > > that in advance,  we can claim any statement to the smallest detail. Of
> > > course it's difficult, but we can do it. Wikidata, as Lydia said, can
> > > actually have conflicting statements in every item: we "just" have to
> put
> > > them there, as we did to Wikipedia.
> > >
> > > If Google uses our data and they are wrong, that's bad for them. If
> they
> > > correct the errors and do not give us the corrections, that's bad for
> us
> > > and not ethical from them. The point is: there is no license (for what
> I
> > > know) that can force them to contribute to Wikidata. That is, IMHO, the
> > > problem with "over-the-top" actors: they can harness collective
> > intelligent
> > > and "not give back." Even with CC-BY-SA, they could store (as they are
> > > probably already doing) all the data in their knowledge vault, which is
> > > secret as it is an incredible asset for them.
> > >
> > > I'd be happy to insert a new clause of "forced transparency" in
> CC-BY-SA
> > or
> > > CC0, but it's not there.
> > >
> > > So, as we are  working via GLAMs 

Re: [Wikimedia-l] Quality issues

[Andrea Zanni]

On Sun, Dec 13, 2015 at 9:35 PM, Jane Darnell  wrote:

> Andrea,
> I totally agree on the mission/vision thing, but am not sure what you mean
> exactly by scale - do you mean that Wikidata shouldn't try to be so
> granular that it has a statement to cover each factoid in any Wikipedia
> article, or do you mean we need to talk about what constitutes notability
> in order not to grow Wikidata exponentially to the point the servers crash?
> Jane
>
>
Hi Jane, I explained myself poorly (sometime English is too difficult :-)

What I mean is that the scale of the error *could* be of another scale,
another order of magnitude.
The propagation of the error is multiplied, it's not just a single error on
a wikipage: it's an error propagated in many wikipages, and then Google,
etc.
A single point of failure.

Of course, the opposite is also true: it's a single point of openness,
correction, information.
I was just wondering if this different scale is a factor in making
Wikipedia and Wikidata different enough to accept/reject Andreas arguments.

Andrea



> On Sun, Dec 13, 2015 at 7:10 PM, Andrea Zanni 
> wrote:
>
> > I really feel we are drowning in a glass of water.
> > The issue of "data quality" or "reliability" that Andreas raises is well
> > known:
> > what I don't understand if the "scale" of it is much bigger on Wikidata
> > than Wikipedia,
> > and if this different scale makes it much more important. The scale of
> the
> > issue is maybe something worth discussing, and not the issue itself? Is
> the
> > fact that Wikidata is centralised different from statements on
> Wikipedia? I
> > don't know, but to me this is a more neutral and interesting question.
> >
> > I often say that the Wikimedia world made quality an "heisemberghian"
> > feature: you always have to check if it's there.
> > The point is: it's been always like this.
> > We always had to check for quality, even when we used Britannica or
> > authority controls or whatever "reliable" sources we wanted. Wikipedia,
> and
> > now Wikidata, is made for everyone to contribute, it's open and honest in
> > being open, vulnerable, prone to errors. But we are transparent, we say
> > that in advance,  we can claim any statement to the smallest detail. Of
> > course it's difficult, but we can do it. Wikidata, as Lydia said, can
> > actually have conflicting statements in every item: we "just" have to put
> > them there, as we did to Wikipedia.
> >
> > If Google uses our data and they are wrong, that's bad for them. If they
> > correct the errors and do not give us the corrections, that's bad for us
> > and not ethical from them. The point is: there is no license (for what I
> > know) that can force them to contribute to Wikidata. That is, IMHO, the
> > problem with "over-the-top" actors: they can harness collective
> intelligent
> > and "not give back." Even with CC-BY-SA, they could store (as they are
> > probably already doing) all the data in their knowledge vault, which is
> > secret as it is an incredible asset for them.
> >
> > I'd be happy to insert a new clause of "forced transparency" in CC-BY-SA
> or
> > CC0, but it's not there.
> >
> > So, as we are  working via GLAMs with Wikipedia for getting reliable
> > sources and content, we are working with them also for good statements
> and
> > data. Putting good data in Wikidata makes it better, and I don't
> understand
> > what is the problem here (I understand, again, the issue of putting too
> > much data and still having a small community).
> > For example: if we are importing different reliable databases, andthe
> > institutions behind them find it useful and helpful to have an aggregator
> > of identifiers and authority controls, what is the issue? There is value
> in
> > aggregating data, because you can spot errors and inconsistencies. It's
> not
> > easy, of course, to find a good workflow, but, again, that is *another*
> > problem.
> >
> > So, in conclusion: I find many issues in Wikidata, but not on the
> > mission/vision, just in the complexity of the project, the size of the
> > dataset, the size of the community.
> >
> > Can we talk about those?
> >
> > Aubrey
> >
> >
> >
> > On Sun, Dec 13, 2015 at 6:40 PM, Andreas Kolbe 
> wrote:
> >
> > > On Sun, Dec 13, 2015 at 5:32 PM, geni  wrote:
> > >
> > > > On 13 December 2015 at 15:57, Andreas Kolbe 
> > wrote:
> > > >
> > > > > Jane,
> > > > >
> > > > > The issue is that you can't cite one Wikipedia article as a source
> in
> > > > > another.
> > > > >
> > > >
> > > >
> > > > However you can within the same article per [[WP:LEAD]].
> > > >
> > >
> > >
> > > Well, of course, if there are reliable sources cited in the body of the
> > > article that back up the statements made in the lead. You still need to
> > > cite a reliable source though; that's Wikipedia 101.
> > > ___
> > > Wikimedia-l mailing list, 

Re: [Wikimedia-l] Quality issues

[Gerard Meijssen]

Hoi,
The one thing where Wikidata shines is in connecting sources through
identifiers. It connects all Wikipedias through the interwiki links and
improving these has been an ongoing process of the last three years. Every
week more external identifiers are added and it is in the mix-n-match tool
by Magnus that many of these connections are made.

As more sources are added, the opportunity grows to compare and curate. The
law on copyright hold that you cannot use complete databases but it allows
you to compare and curate. When values match, there is no obvious issue.
When they do not, it is a matter of signalling the difference and
evaluating the opposing values.

What we should NOT do is accept any value as 100% correct. Sources are
known to be wrong but where everybody agrees, we can at least concentrate
on where there is a disagreement, where an investment in time makes the
most difference. In this way we do make a positive difference for our own
content and by signalling differences at the other end as well.

The problem with Andreas argument is that it does not provide any way
forward. It may be a problem and then what. By concentrating on what we do
best, sharing in the sum of all available knowledge we enable parties to
compare their content with all the other parties that have content. We
publish where we find a difference and it is then for us and others to do
the best we can.
Thanks,
  GerardM

On 16 December 2015 at 12:12, Andrea Zanni  wrote:

> On Sun, Dec 13, 2015 at 9:35 PM, Jane Darnell  wrote:
>
> > Andrea,
> > I totally agree on the mission/vision thing, but am not sure what you
> mean
> > exactly by scale - do you mean that Wikidata shouldn't try to be so
> > granular that it has a statement to cover each factoid in any Wikipedia
> > article, or do you mean we need to talk about what constitutes notability
> > in order not to grow Wikidata exponentially to the point the servers
> crash?
> > Jane
> >
> >
> Hi Jane, I explained myself poorly (sometime English is too difficult :-)
>
> What I mean is that the scale of the error *could* be of another scale,
> another order of magnitude.
> The propagation of the error is multiplied, it's not just a single error on
> a wikipage: it's an error propagated in many wikipages, and then Google,
> etc.
> A single point of failure.
>
> Of course, the opposite is also true: it's a single point of openness,
> correction, information.
> I was just wondering if this different scale is a factor in making
> Wikipedia and Wikidata different enough to accept/reject Andreas arguments.
>
> Andrea
>
>
>
> > On Sun, Dec 13, 2015 at 7:10 PM, Andrea Zanni 
> > wrote:
> >
> > > I really feel we are drowning in a glass of water.
> > > The issue of "data quality" or "reliability" that Andreas raises is
> well
> > > known:
> > > what I don't understand if the "scale" of it is much bigger on Wikidata
> > > than Wikipedia,
> > > and if this different scale makes it much more important. The scale of
> > the
> > > issue is maybe something worth discussing, and not the issue itself? Is
> > the
> > > fact that Wikidata is centralised different from statements on
> > Wikipedia? I
> > > don't know, but to me this is a more neutral and interesting question.
> > >
> > > I often say that the Wikimedia world made quality an "heisemberghian"
> > > feature: you always have to check if it's there.
> > > The point is: it's been always like this.
> > > We always had to check for quality, even when we used Britannica or
> > > authority controls or whatever "reliable" sources we wanted. Wikipedia,
> > and
> > > now Wikidata, is made for everyone to contribute, it's open and honest
> in
> > > being open, vulnerable, prone to errors. But we are transparent, we say
> > > that in advance,  we can claim any statement to the smallest detail. Of
> > > course it's difficult, but we can do it. Wikidata, as Lydia said, can
> > > actually have conflicting statements in every item: we "just" have to
> put
> > > them there, as we did to Wikipedia.
> > >
> > > If Google uses our data and they are wrong, that's bad for them. If
> they
> > > correct the errors and do not give us the corrections, that's bad for
> us
> > > and not ethical from them. The point is: there is no license (for what
> I
> > > know) that can force them to contribute to Wikidata. That is, IMHO, the
> > > problem with "over-the-top" actors: they can harness collective
> > intelligent
> > > and "not give back." Even with CC-BY-SA, they could store (as they are
> > > probably already doing) all the data in their knowledge vault, which is
> > > secret as it is an incredible asset for them.
> > >
> > > I'd be happy to insert a new clause of "forced transparency" in
> CC-BY-SA
> > or
> > > CC0, but it's not there.
> > >
> > > So, as we are  working via GLAMs with Wikipedia for getting reliable
> > > sources and content, we are working with them also for good 

[Wikimedia-l] Mid-December Fundraiser Update

[Megan Hernandez]

Hi everyone,


The fundraising team is wrapping up the second week of the December
campaign and we’d like to share an update with you--where we are, what
we’ve changed, and what you can do to get involved.


WHERE WE ARE:

We’ve passed the halfway mark to the $25 million campaign goal.  So far,
we’ve raised roughly $18 million (a preliminary total that is quickly
changing and has not been reconciled with official totals from the finance
department).   Banners are running on desktop and mobile devices. We are
also sending emails to past donors asking if they would give again this
year.  We’re monitoring the trends daily and look forward to sharing a
post-campaign analysis with you.   We will post an update on when we will
be able to end the campaign when we have a clearer picture.


WHAT WE’VE CHANGED:

Over the past several months, staff members and volunteers have provided
both critical and generative feedback and new fundraising banner ideas.
Their help has been very valuable. Many of these new messages have been
tried in pre-campaign tests and in the last two weeks. Thank you to
everyone who has shared their time and ideas!  A few message highlights:



   -

   We are no longer using the line "keep Wikipedia online and ad-free." It
   has been changed to “keep our work going another year.”
   -

   New text in the current banner: “We believe that knowledge is a
   foundation. It is a foundation for human potential, for freedom, for
   opportunity. We believe everyone should have access to knowledge—for free,
   without restriction, without limitation.”
   -

   "We survive on donations" has been changed to "We're sustained by
   donations"
   -

   "Please help us end the fundraiser and get back to improving Wikipedia"
   has been changed to "Please help us end the fundraiser and improve
   Wikipedia."
   -

   We have removed the persistent reminder from large banners. The reminder
   is still included in the small banners, which is consistent with the same
   style banners from the 2013 and 2014 campaigns.
   -

   The coffee cup image has been removed from banners



We have also run some initial tests with new messaging that show
encouraging results. We're still working on more messages and sorting out
how we'll incorporate new ideas into the overall banner, but here are some
sentences we’re testing:



   -

   “Wikipedia has become nothing short of a global public library.”
   -

   “We don’t run ads. We respect your privacy. We don’t sell your data.”
   -

   “Wikipedia exists to verify, protect, and share the combined knowledge
   of humanity.”
   -

   "There is nothing else on the internet like Wikipedia. We are a global
   information hub with 15 billion page views a month, written by a community
   of volunteers with a passion for knowledge."
   -

   "The information in Wikipedia is constantly growing, but we need your
   help to keep up with rapidly changing technology. Wikipedia is like a
   library or public park created by a passionate community."
   -

   "Wikipedia changes every second of every day. We just hit 5 million
   English articles, but we need to continually grow to serve our readers."
   -

   "Please become a volunteer or a donor to help end us the fundraiser and
   improve Wikipedia. Thank you."


With just a couple weeks left to go in 2015, the team is working hard to
make improvements. We’d love your help.


HOW TO GET INVOLVED:

   -

   To file a bug report or technical issue, please create a phabricator
   ticket
   
   or email problemsdonat...@wikimedia.org
   -

   To get up-to-date on the the latest reader survey, read the full report
   on commons
   

   -

   To read the latest news from the team, see the fundraising meta page
   
   -

   To suggest another banner idea, visit the test ideas meta page
   
   -

   To learn more about the fundraising program and last year’s campaign,
   see the 2014-15 fundraising report
   


Thank you to everyone for your support and to the fundraising team for
working so collaboratively and such long hours throughout this campaign.
And thank you to all those that have given thus far.


Megan

-- 

Megan Hernandez

Director of Online Fundraising
Wikimedia Foundation
___
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,