Mailing List Archive

[HTML5] Improving Commons upload interface
Hi Everyone,

I searched the archives of both list and couldn't find any thread
about it. I could miss it, so sorry it it already has been discussed.

We all know that uploading a file on commons, and on Wikimedia, is
kind of tricky nowdays. However, this could be changed thanks to
HTML5.

HTML5 includes the drag and drop thingy that makes the uploads easier
and that can automatically fetch the EXIF datas. If we want we could
even allow the multiple drag and drop.

Anyway this could be a solution to look at, you can get more
information there :
http://hacks.mozilla.org/2009/12/firefox-36-fileapi-demo-reading-exif-data-from-a-local-jpeg-file/
and there : http://hacks.mozilla.org/2009/12/file-drag-and-drop-in-firefox-3-6/

All the best,

--
Christophe

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
On Thu, Sep 2, 2010 at 6:01 AM, Christophe Henner
<christophe.henner@gmail.com> wrote:
> Hi Everyone,
>
> I searched the archives of both list and couldn't find any thread
> about it. I could miss it, so sorry it it already has been discussed.
>
> We all know that uploading a file on commons, and on Wikimedia, is
> kind of tricky nowdays. However, this could be changed thanks to
> HTML5.
>
> HTML5 includes the drag and drop thingy that makes the uploads easier
> and that can automatically fetch the EXIF datas. If we want we could
> even allow the multiple drag and drop.
>
> Anyway this could be a solution to look at, you can get more
> information there :
> http://hacks.mozilla.org/2009/12/firefox-36-fileapi-demo-reading-exif-data-from-a-local-jpeg-file/
> and there : http://hacks.mozilla.org/2009/12/file-drag-and-drop-in-firefox-3-6/
>
> All the best,
>
> --
> Christophe
>

Keeping in mind that it won't work for everybody :)

http://caniuse.com/#feat=fileapi

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
Bonjour,

Le jeudi 02 septembre 2010 à 12:01 +0200, Christophe Henner a écrit :*
>
> We all know that uploading a file on commons, and on Wikimedia, is
> kind of tricky nowdays. However, this could be changed thanks to
> HTML5.
>
> HTML5 includes the drag and drop thingy that makes the uploads easier
> and that can automatically fetch the EXIF datas. If we want we could
> even allow the multiple drag and drop.

There are a lot of things we /could/ do, but only few we /can/ do with
limited resources. Unless you're offering to develop the feature
yourself :)

--
Guillaume Paumier
Product Manager, Multimedia Usability
Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
For what it's worth, I'm taking a multiple-backend approach where the
actual upload method can be configured based on browser capabilities.
It's been a "nice to have" feature since day one to do an HTML5 drag &
drop upload, but that keeps getting delayed as other things come up.

If someone is interested in doing this feature, I'd help.



On 9/2/10 8:36 AM, Guillaume Paumier wrote:
> Bonjour,
>
> Le jeudi 02 septembre 2010 à 12:01 +0200, Christophe Henner a écrit :*
>>
>> We all know that uploading a file on commons, and on Wikimedia, is
>> kind of tricky nowdays. However, this could be changed thanks to
>> HTML5.
>>
>> HTML5 includes the drag and drop thingy that makes the uploads easier
>> and that can automatically fetch the EXIF datas. If we want we could
>> even allow the multiple drag and drop.
>
> There are a lot of things we /could/ do, but only few we /can/ do with
> limited resources. Unless you're offering to develop the feature
> yourself :)
>

--
Neil Kandalgaonkar ( <neilk@wikimedia.org>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
An'n 02.09.2010 17:36, hett Guillaume Paumier schreven:
> Bonjour,
>
> Le jeudi 02 septembre 2010 à 12:01 +0200, Christophe Henner a écrit :*
>> We all know that uploading a file on commons, and on Wikimedia, is
>> kind of tricky nowdays. However, this could be changed thanks to
>> HTML5.
>>
>> HTML5 includes the drag and drop thingy that makes the uploads easier
>> and that can automatically fetch the EXIF datas. If we want we could
>> even allow the multiple drag and drop.
> There are a lot of things we /could/ do, but only few we /can/ do with
> limited resources. Unless you're offering to develop the feature
> yourself :)
The Foundation has a budget of 20 million $ this financial year. It
plans to spend 8.972 million $ on 91 staff members. That's 98,593.41$
per person. So there are resources. They are just planned to be spend
for other things.

With that background I do not like the "yeah, nice idea, do it yourself"
approach whenever somebody proposes good ideas. We have many great ideas
lingering around for years that never get implemented because the number
of volunteer developers is limited especially when it comes to projects
that could take months to implement. (Datawiki, Central Interwiki,
support for internal map services instead of JPGs on Commons, true
support for multilingual wikis, working category intersections etc. pp.)

In my opinion the Foundation should employ several developers who don't
have any other task than improving Wikimedia. There should be a pool of
improvement ideas that can be rated by importance by the Wikimedia
users. The paid developers should then be able to pick improvement ideas
and implement them preferring projects that are rated important. That
way we can ensure a constant flow of innovation for Wikimedia.

Guillaume, you are a Foundation employee, how about presenting my
improvement idea in the next meeting with the bosses ;-)

Marcus Buck
User:Slomox

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
Hi,

Le jeudi 02 septembre 2010 à 20:48 +0200, Marcus Buck a écrit :
> The Foundation has a budget of 20 million $ this financial year. It
> plans to spend 8.972 million $ on 91 staff members. That's 98,593.41$
> per person.

I wish that were my salary.

> So there are resources. They are just planned to be spend
> for other things.
>
> With that background I do not like the "yeah, nice idea, do it yourself"
> approach whenever somebody proposes good ideas. We have many great ideas
> lingering around for years that never get implemented because the number
> of volunteer developers is limited especially when it comes to projects
> that could take months to implement. (Datawiki, Central Interwiki,
> support for internal map services instead of JPGs on Commons, true
> support for multilingual wikis, working category intersections etc. pp.)
>
> In my opinion the Foundation should employ several developers who don't
> have any other task than improving Wikimedia. There should be a pool of
> improvement ideas that can be rated by importance by the Wikimedia
> users. The paid developers should then be able to pick improvement ideas
> and implement them preferring projects that are rated important. That
> way we can ensure a constant flow of innovation for Wikimedia.
>
> Guillaume, you are a Foundation employee, how about presenting my
> improvement idea in the next meeting with the bosses ;-)

They don't seem to have waited for you to get that idea ;-) See
http://wikimediafoundation.org/wiki/File:2010-11_Wikimedia_Foundation_Annual_Plan_FINAL_FOR_WEBSITE.pdf


--
Guillaume Paumier


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
An'n 02.09.2010 20:58, hett Guillaume Paumier schreven:
> They don't seem to have waited for you to get that idea ;-) See
> http://wikimediafoundation.org/wiki/File:2010-11_Wikimedia_Foundation_Annual_Plan_FINAL_FOR_WEBSITE.pdf
That's where I got the numbers from. It speaks about hirings (the new
hirings are already included in the number of 91 employees) but it does
nowhere mention developers.

So, was your post a statement of a Foundation employee that confirms
that the Foundation will hire several developers whose main and only
task it is to program new functionalities for Wikimedia, based on demand
ratings, functionalities like the ones I named and the community has
waited for since at least half a decade? Is that correct?

Marcus Buck
User:Slomox

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
On Thu, Sep 2, 2010 at 3:16 PM, Marcus Buck <wiki@marcusbuck.org> wrote:
> So, was your post a statement of a Foundation employee that confirms
> that the Foundation will hire several developers whose main and only
> task it is to program new functionalities for Wikimedia, based on demand
> ratings, functionalities like the ones I named and the community has
> waited for since at least half a decade? Is that correct?
>

What a terrible way to write software.

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
"Marcus Buck" <wiki@marcusbuck.org> wrote in message
news:4C7FF181.7010501@marcusbuck.org...
> The Foundation has a budget of 20 million $ this financial year. It
> plans to spend 8.972 million $ on 91 staff members. That's 98,593.41$
> per person. So there are resources. They are just planned to be spend
> for other things.

The "salaries, wages and recruiting" category includes spending on pensions,
healthcare, recruitment advertising, consultancy, and spending on employing
contractors not counted in the permanent staff, AFAIK.

> In my opinion the Foundation should employ several developers who don't
> have any other task than improving Wikimedia...

Can I ask what you think the current technical team members are doing? :-P

The WMF is planning to almost double the size of the technical staff this
year, including one role intriguingly titled "Bugmeister"... You're right
that it's no longer accurate to say that the money is not there, but it's
also rather unfair to suggest that what the current tech team are doing is
solely firefighting. We have seen some great developments over the past
year or two, and hopefully the pace will continue to accelerate.

--HM




_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
Chad wrote:
> On Thu, Sep 2, 2010 at 3:16 PM, Marcus Buck <wiki@marcusbuck.org> wrote:
>> So, was your post a statement of a Foundation employee that confirms
>> that the Foundation will hire several developers whose main and only
>> task it is to program new functionalities for Wikimedia, based on demand
>> ratings, functionalities like the ones I named and the community has
>> waited for since at least half a decade? Is that correct?
>
> What a terrible way to write software.

Terrible because it might produce something that isn't vaporware or an
uninstalled extension?

MZMcBride



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
Hey Marcus,
Slow down. There used to be no budget and now that there is a budget they
have to grow the workforce. That is not easy and as you will have seen there
is a very ambitious program. You may be right that for some features we have
been waiting for five years, for other features we have been waiting even
longer.

Let us not go into who has waited the longest for what as it is not
productive. It is more interesting to bitch about priorities. To do that it
makes sense to first decide how to measure benefit and potential. Then have
a look at the current plans and understand them. It may require a question
or two to understand the plan. Now when we ask polite questions, we may even
get a true answer even an answer we do not like :)

The good news is, we are growing the workforce during a recession. That
means that we get talent for not too outrageous prices .. :)

Any way, the question is how to measure benefit and potential.
Thanks,
GerardM

On 2 September 2010 21:16, Marcus Buck <wiki@marcusbuck.org> wrote:

> An'n 02.09.2010 20:58, hett Guillaume Paumier schreven:
> > They don't seem to have waited for you to get that idea ;-) See
> >
> http://wikimediafoundation.org/wiki/File:2010-11_Wikimedia_Foundation_Annual_Plan_FINAL_FOR_WEBSITE.pdf
> That's where I got the numbers from. It speaks about hirings (the new
> hirings are already included in the number of 91 employees) but it does
> nowhere mention developers.
>
> So, was your post a statement of a Foundation employee that confirms
> that the Foundation will hire several developers whose main and only
> task it is to program new functionalities for Wikimedia, based on demand
> ratings, functionalities like the ones I named and the community has
> waited for since at least half a decade? Is that correct?
>
> Marcus Buck
> User:Slomox
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
On Thu, Sep 2, 2010 at 2:48 PM, Marcus Buck <wiki@marcusbuck.org> wrote:
> The Foundation has a budget of 20 million $ this financial year. It
> plans to spend 8.972 million $ on 91 staff members. That's 98,593.41$
> per person. So there are resources. They are just planned to be spend
> for other things.
>
> With that background I do not like the "yeah, nice idea, do it yourself"
> approach whenever somebody proposes good ideas.

What's the alternative? There are *always* going to be many more
ideas than implementers. Ideas are cheap. Wikimedia has to decide
which features are the most critical to invest developer time in.
Their decision is not going to make everyone happy. The only
guarantee you can ever have is if you do it yourself. Happily,
MediaWiki is open-source, so you *do* have that option! On
practically any other major website, you couldn't add a feature no
matter how much you wanted to.

> In my opinion the Foundation should employ several developers who don't
> have any other task than improving Wikimedia. There should be a pool of
> improvement ideas that can be rated by importance by the Wikimedia
> users. The paid developers should then be able to pick improvement ideas
> and implement them preferring projects that are rated important. That
> way we can ensure a constant flow of innovation for Wikimedia.

We already have that to a decent extent. Bugzilla votes do count for
something. That's undoubtedly part of why I was asked to work on bug
164 -- it's had the most votes of any Bugzilla bug for years. But
popularity is only a small part of the story. What you have to ask is
not what features would you like to see most, but what features are
most *cost-effective*. Users can easily say how much they'd like
feature X, but they're in no position to gauge how many other features
would have to be cut to account for it. A very popular bug that would
require a couple of developers working full-time for months to fix
properly might just not be worth it, if the same development effort
could fix a large number of less-popular bugs. Users are just not in
a position to judge this, so while popularity is a factor, it can't be
the deciding one.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
An'n 02.09.2010 21:23, hett Happy-melon schreven:
> "Marcus Buck"<wiki@marcusbuck.org> wrote in message
> news:4C7FF181.7010501@marcusbuck.org...
>> The Foundation has a budget of 20 million $ this financial year. It
>> plans to spend 8.972 million $ on 91 staff members. That's 98,593.41$
>> per person. So there are resources. They are just planned to be spend
>> for other things.
> The "salaries, wages and recruiting" category includes spending on pensions,
> healthcare, recruitment advertising, consultancy, and spending on employing
> contractors not counted in the permanent staff, AFAIK.
>
It's clear to me and I didn't say that's the sum that ends up on their
accounts. But it's the sum that is spent on them.
>> In my opinion the Foundation should employ several developers who don't
>> have any other task than improving Wikimedia...
> Can I ask what you think the current technical team members are doing? :-P
>
> The WMF is planning to almost double the size of the technical staff this
> year, including one role intriguingly titled "Bugmeister"... You're right
> that it's no longer accurate to say that the money is not there, but it's
> also rather unfair to suggest that what the current tech team are doing is
> solely firefighting. We have seen some great developments over the past
> year or two, and hopefully the pace will continue to accelerate.
I don't want to downplay the role of bugfixing or maintenance of the
existing systems or all the other great stuff the tech team does. But a
Bugmeister will not help us to leap forward with big innovations. For
the big leaps we need people who dedicate full-time on a project.

Marcus Buck
User:Slomox

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
Aryeh Gregor wrote:
> What's the alternative? There are *always* going to be many more
> ideas than implementers. Ideas are cheap. Wikimedia has to decide
> which features are the most critical to invest developer time in.
> Their decision is not going to make everyone happy. The only
> guarantee you can ever have is if you do it yourself. Happily,
> MediaWiki is open-source, so you *do* have that option! On
> practically any other major website, you couldn't add a feature no
> matter how much you wanted to.

The current status of Wikimedia code deployment makes this no longer
applicable to Wikimedia either.

MZMcBride



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
On Thu, Sep 2, 2010 at 9:36 PM, MZMcBride <z@mzmcbride.com> wrote:
>
> The current status of Wikimedia code deployment makes this no longer
> applicable to Wikimedia either.
>
Ack. I recall a thread on this list about that. Did that have any outcomes?


Bryan

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
On 2010-09-02, MZMcBride wrote:
> Aryeh Gregor wrote:
> > What's the alternative? There are *always* going to be many more
> > ideas than implementers. Ideas are cheap. Wikimedia has to decide
> > which features are the most critical to invest developer time in.
> > Their decision is not going to make everyone happy. The only
> > guarantee you can ever have is if you do it yourself. Happily,
> > MediaWiki is open-source, so you *do* have that option! On
> > practically any other major website, you couldn't add a feature no
> > matter how much you wanted to.
>
> The current status of Wikimedia code deployment makes this no longer
> applicable to Wikimedia either.

See also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=23268
https://bugzilla.wikimedia.org/show_bug.cgi?id=18461
https://bugzilla.wikimedia.org/show_bug.cgi?id=15308
https://bugzilla.wikimedia.org/show_bug.cgi?id=14207
https://bugzilla.wikimedia.org/show_bug.cgi?id=15165

All asking for a feature which has been implemented since April 2008 to
be reviewed and installed.

Robert

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
An'n 02.09.2010 21:26, hett Gerard Meijssen schreven:
> Any way, the question is how to measure benefit and potential.
My idea for that, as I said, is having a pool of possible improvements
and then letting decide a mix of user ratings ("pro - we need this!",
"contra - not really necessary...") and common sense of the developers.
Create a page at Meta where people can propose things. Then check the
proposal (can it be implemented in a performant way? is it actually a
direction we want to develop to? technical traps? etc.pp.). If the check
is positive put the proposal on a second, protected, page on Meta and
let users vote pro and contra. Developers can then choose from the list
which project they want to implement next (preferring projects with high
ratings, but with room for an amount of common sense by the developers
because they know better about the technical feasibility).

My main point is, that at the moment I as a user have no chance to
influence the development of Wikimedia (except for doing it myself). I
can pray or I can vote on Bugzilla but I have no way to predict when and
who takes the time to start a project. It would be nice to know that
there are people committed.

If I have an idea, what do I do at the moment? I can post on wikitech-l.
I will be told that the best way to get it done is by doing it myself. I
can go to Meta and propose something there. On Meta nobody will even
read it. So what I would like to have is a process. When I make a
proposal it should either get rejected or it should end up in the
above-mentioned pool and be implemented sooner or later dependant on its
importance.

My concern is that people have ideas, propose them, people tell them
"great idea!" and then nothing happens for years. If we had an official
process to handle proposals people can at least have confidence that the
proposal gets attention and they can observe their proposal and estimate
the proposal's chances based on its ratings.

Marcus Buck
User:Slomox

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
On Thu, Sep 2, 2010 at 4:42 PM, Marcus Buck <wiki@marcusbuck.org> wrote:
> My idea for that, as I said, is having a pool of possible improvements
> and then letting decide a mix of user ratings ("pro - we need this!",
> "contra - not really necessary...") and common sense of the developers.
> Create a page at Meta where people can propose things. Then check the
> proposal (can it be implemented in a performant way? is it actually a
> direction we want to develop to? technical traps? etc.pp.). If the check
> is positive put the proposal on a second, protected, page on Meta and
> let users vote pro and contra. Developers can then choose from the list
> which project they want to implement next (preferring projects with high
> ratings, but with room for an amount of common sense by the developers
> because they know better about the technical feasibility).

We have this system already, it's called Bugzilla.

> My main point is, that at the moment I as a user have no chance to
> influence the development of Wikimedia (except for doing it myself).

It's not possible to give users significant direct influence. There
are too many users and too few developers. Users are collectively
given significant say in development, but the influence is spread very
thin because the users are so numerous. You have little say because
there are many thousands of users whose say is weighted equally to
yours.

> I
> can pray or I can vote on Bugzilla but I have no way to predict when and
> who takes the time to start a project. It would be nice to know that
> there are people committed.

You do know when there are people committed, because the bug is
changed to ASSIGNED (or FIXED if it's quick). Usually there are no
people committed, but this is because there are vastly more ideas than
implementer time, not because of procedural issues.

> If I have an idea, what do I do at the moment? I can post on wikitech-l.
> I will be told that the best way to get it done is by doing it myself. I
> can go to Meta and propose something there. On Meta nobody will even
> read it. So what I would like to have is a process. When I make a
> proposal it should either get rejected or it should end up in the
> above-mentioned pool and be implemented sooner or later dependant on its
> importance.

This is exactly what Bugzilla does. In practice, of course, the
overwhelming majority of feature requests there are not fixed, but
again, this is not a problem with the process and it cannot be fixed
or even mitigated by changing the process.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
Hoi,
It sounds nice "all users have equal say". They have not and, they should
not. Because what will be the benefit? People are more happy when they are
told what the priorities are and why and when they are kept informed about
developments.

Questions like "what will be the benefit", "how to measure benefit" are
vitally important. It is a question of what should be rated and how. Many of
the obvious projects have been rated and are getting attention. There are
many great ideas, there are even many coded "solutions" and it takes a lot
of effort to get those considered and evaluated.

The notion that bugzilla is the obvious solution is interesting. It is not
obvious to me because it is not where the important questions are answered.
With too little resources the only thing is to make choices and explain
them. <grin> this will not please everyone that is a given, but it leaves
plenty of room for a lot of bitching </grin>
Thanks,
GerardM

On 2 September 2010 22:50, Aryeh Gregor
<Simetrical+wikilist@gmail.com<Simetrical%2Bwikilist@gmail.com>
> wrote:

> On Thu, Sep 2, 2010 at 4:42 PM, Marcus Buck <wiki@marcusbuck.org> wrote:
> > My idea for that, as I said, is having a pool of possible improvements
> > and then letting decide a mix of user ratings ("pro - we need this!",
> > "contra - not really necessary...") and common sense of the developers.
> > Create a page at Meta where people can propose things. Then check the
> > proposal (can it be implemented in a performant way? is it actually a
> > direction we want to develop to? technical traps? etc.pp.). If the check
> > is positive put the proposal on a second, protected, page on Meta and
> > let users vote pro and contra. Developers can then choose from the list
> > which project they want to implement next (preferring projects with high
> > ratings, but with room for an amount of common sense by the developers
> > because they know better about the technical feasibility).
>
> We have this system already, it's called Bugzilla.
>
> > My main point is, that at the moment I as a user have no chance to
> > influence the development of Wikimedia (except for doing it myself).
>
> It's not possible to give users significant direct influence. There
> are too many users and too few developers. Users are collectively
> given significant say in development, but the influence is spread very
> thin because the users are so numerous. You have little say because
> there are many thousands of users whose say is weighted equally to
> yours.
>
> > I
> > can pray or I can vote on Bugzilla but I have no way to predict when and
> > who takes the time to start a project. It would be nice to know that
> > there are people committed.
>
> You do know when there are people committed, because the bug is
> changed to ASSIGNED (or FIXED if it's quick). Usually there are no
> people committed, but this is because there are vastly more ideas than
> implementer time, not because of procedural issues.
>
> > If I have an idea, what do I do at the moment? I can post on wikitech-l.
> > I will be told that the best way to get it done is by doing it myself. I
> > can go to Meta and propose something there. On Meta nobody will even
> > read it. So what I would like to have is a process. When I make a
> > proposal it should either get rejected or it should end up in the
> > above-mentioned pool and be implemented sooner or later dependant on its
> > importance.
>
> This is exactly what Bugzilla does. In practice, of course, the
> overwhelming majority of feature requests there are not fixed, but
> again, this is not a problem with the process and it cannot be fixed
> or even mitigated by changing the process.
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
Hello all,

just a quick big picture update:

1) In general, as you may have noticed, Danese has hired Engineering
Program Managers. This is a standard way in growing tech organizations
to manage, organize and communicate technology projects. The current
setup is:

Rob Lanphier - general core engineering (MediaWiki core, API, code
review, QA, etc.)
Alolita Sharma - features/product engineering
Tomasz Finc - fundraising, mobile/offline

Guillaume Paumier is currently doing both product planning and some
EPM work for the multimedia usability project.

This has led to much-improved internal planning and organization of
WMF's technical projects, and as you've probably seen, a solid general
update and documentation of the engineering projects that are
underway:

http://techblog.wikimedia.org/2010/09/wmf-engineering/

If you want to keep up with hiring of staff and contractors, there's
now also a new Twitter feed:

http://twitter.com/wikimediaatwork

2) My role is shifting to helping articulate our overall product
development strategy and research, meaning to synthesize input from
many different sources (community, other departments, researchers,
etc.) that helps inform our decision as to which projects we either
want to build or prioritize. That includes questions such as "Let's
take this existing MediaWiki extension and help review it and whip it
into shape". To support this work, I will work with one strategically
oriented Senior Product Manager (Howie Fung) and a Senior Research
Analyst (currently posted).

This, of course, will be primarily relevant to projects we're directly
paying for, but also to some extent the kinds of meetings and the
types of volunteer projects we'll facilitate and try to actively
generate interest in. Ultimately, volunteer developers invest time in
projects they care about, but we do not guarantee that every MediaWiki
extension will be reviewed, improved or deployed by WMF staff
engineers, irrespective of whether there's a large amount of community
interest in it or not. (For example, there might be large interest in
a feature that's prohibitively complex, or poorly thought out, or very
low-impact.)

Indeed, I don't believe in an approach that only relies on user
ratings or votes, rather, priorities should be set based on the
overall impact on our strategic objectives that any planned project
(technology or not) is going to have. Is it going to help our editor
community be more effective? Is it going to help us reach more people?
Is it going to drive the overall quality of the content? Is it going
to support reaching disadvantaged or underrepresented communities?

That said, that doesn't mean that a process can't be open and
consultative. I invite you to look at the (permanently open) Call for
Proposals on StrategyWiki, and the special extension that's used to
show a dashboard of particularly active or interesting proposals:

http://strategy.wikimedia.org/wiki/Main_Page

I hope to help kick this process back into gear a little bit, and
improve upon it, as a way to solicit more extensive and carefully
thought-out proposals than what typically finds its way into Bugzilla.
(And I agree that Bugzilla is a great tool, especially for smaller
requests.)

Together with Danese, the EPM team, and others, we will aim to make
WMF's decisions transparent and understandable. When Danese writes
about "making code review more transparent", this is a big part of
what she's talking about -- the entire process of deciding, for
example, that a community-developed software extension is being
reviewed, deployed, and possibly even integrated into MediaWiki core.
So we do want to be clear _why_ something happens, even if you might
disagree with the reasons.

Last but not least, please bear with us, as we're a) still a small
team, b) still generally professionalizing and maturing our
engineering practices, c) in active growth and transition mode,
meaning we have to absorb and orient lots of new people. We're all
here to help Wikimedia succeed, and we appreciate patience, kindness,
good faith and good humor in working together.

All best,
Erik
--
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
An'n 02.09.2010 22:50, hett Aryeh Gregor schreven:
> On Thu, Sep 2, 2010 at 4:42 PM, Marcus Buck<wiki@marcusbuck.org> wrote:
>> My idea for that, as I said, is having a pool of possible improvements
>> and then letting decide a mix of user ratings ("pro - we need this!",
>> "contra - not really necessary...") and common sense of the developers.
>> Create a page at Meta where people can propose things. Then check the
>> proposal (can it be implemented in a performant way? is it actually a
>> direction we want to develop to? technical traps? etc.pp.). If the check
>> is positive put the proposal on a second, protected, page on Meta and
>> let users vote pro and contra. Developers can then choose from the list
>> which project they want to implement next (preferring projects with high
>> ratings, but with room for an amount of common sense by the developers
>> because they know better about the technical feasibility).
> We have this system already, it's called Bugzilla.
>> My main point is, that at the moment I as a user have no chance to
>> influence the development of Wikimedia (except for doing it myself).
> It's not possible to give users significant direct influence. There
> are too many users and too few developers. Users are collectively
> given significant say in development, but the influence is spread very
> thin because the users are so numerous. You have little say because
> there are many thousands of users whose say is weighted equally to
> yours.
>> I
>> can pray or I can vote on Bugzilla but I have no way to predict when and
>> who takes the time to start a project. It would be nice to know that
>> there are people committed.
> You do know when there are people committed, because the bug is
> changed to ASSIGNED (or FIXED if it's quick). Usually there are no
> people committed, but this is because there are vastly more ideas than
> implementer time, not because of procedural issues.
>> If I have an idea, what do I do at the moment? I can post on wikitech-l.
>> I will be told that the best way to get it done is by doing it myself. I
>> can go to Meta and propose something there. On Meta nobody will even
>> read it. So what I would like to have is a process. When I make a
>> proposal it should either get rejected or it should end up in the
>> above-mentioned pool and be implemented sooner or later dependant on its
>> importance.
> This is exactly what Bugzilla does. In practice, of course, the
> overwhelming majority of feature requests there are not fixed, but
> again, this is not a problem with the process and it cannot be fixed
> or even mitigated by changing the process.
It certainly can be improved. As I said, my main concern is not
bugfixing, but development. Like the implementation of a common image
repository, parser functions, single user login to name some from the
past. The HTML5 upload is smaller, but it's a new feature and not a bugfix.

Nikola Smolenski has done great work on Interwiki transclusion. But
nothing has happened since two years. If I were a member of the tech
department at Wikimedia, I'd be enthused and would put all my energy in
reviewing his code, straigthening out any remaining problems and making
it real as soon as possible. I mean, making interwiki bots obsolete,
making obsolete like hundreds of thousands edits per day, that would be
an amazing improvement, wouldn't it? This dormancy worries me.


Marcus Buck
User:Slomox



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
Marcus Buck schreven:
> An'n 02.09.2010 22:50, hett Aryeh Gregor schreven:
>> This is exactly what Bugzilla does. In practice, of course, the
>> overwhelming majority of feature requests there are not fixed, but
>> again, this is not a problem with the process and it cannot be fixed
>> or even mitigated by changing the process.
> It certainly can be improved. As I said, my main concern is not
> bugfixing, but development. Like the implementation of a common image
> repository, parser functions, single user login to name some from the
> past. The HTML5 upload is smaller, but it's a new feature and not a bugfix.

Bugzilla is also for enhacements, not only for bugfixes
Having the proposal in bugzilla gives a point where it is recorded and
hopefully taken up at some time. As opposed to an email which gets
buried int he archive. Although if there's no reaction to the bug, a
note here eg. after a week may help to raise attention.

You may also come to #mediawiki in irc to talk with us about specific
features (How likely is that we can get a foobar bazinastic implemented
soon?).


> Nikola Smolenski has done great work on Interwiki transclusion. But
> nothing has happened since two years. If I were a member of the tech
> department at Wikimedia, I'd be enthused and would put all my energy in
> reviewing his code, straigthening out any remaining problems and making
> it real as soon as possible. I mean, making interwiki bots obsolete,
> making obsolete like hundreds of thousands edits per day, that would be
> an amazing improvement, wouldn't it? This dormancy worries me.

Have you seen
http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_transclusion
recent GSOC project?
It's still not merged to trunk, but it's there.
And do note that you can help reviewing the code, even if you can't give
it the final ok. Any problem you spot now, is an error less to be found
later.
You can follow MediaWiki (core & extensions) development at
http://www.mediawiki.org/wiki/Special:Code/MediaWiki


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
On Thu, Sep 2, 2010 at 5:34 PM, Marcus Buck <wiki@marcusbuck.org> wrote:
> It certainly can be improved. As I said, my main concern is not
> bugfixing, but development. Like the implementation of a common image
> repository, parser functions, single user login to name some from the
> past. The HTML5 upload is smaller, but it's a new feature and not a bugfix.

Feature requests go on Bugzilla too.

> Nikola Smolenski has done great work on Interwiki transclusion. But
> nothing has happened since two years. If I were a member of the tech
> department at Wikimedia, I'd be enthused and would put all my energy in
> reviewing his code, straigthening out any remaining problems and making
> it real as soon as possible. I mean, making interwiki bots obsolete,
> making obsolete like hundreds of thousands edits per day, that would be
> an amazing improvement, wouldn't it? This dormancy worries me.

There is no dormancy. You are making the cardinal error of feature
requests: assuming that if you think something is important, everyone
else must too. Quite simply, other people aren't as interested as you
in this particular feature. They're working on other things that they
feel are more interesting or important. In the end, the people who
are doing the work, or paying for it, call the shots on where
resources are invested -- there is nothing that can change that.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
An'n 03.09.2010 19:43, hett Aryeh Gregor schreven:
>
>> Nikola Smolenski has done great work on Interwiki transclusion. But
>> nothing has happened since two years. If I were a member of the tech
>> department at Wikimedia, I'd be enthused and would put all my energy in
>> reviewing his code, straigthening out any remaining problems and making
>> it real as soon as possible. I mean, making interwiki bots obsolete,
>> making obsolete like hundreds of thousands edits per day, that would be
>> an amazing improvement, wouldn't it? This dormancy worries me.
> There is no dormancy. You are making the cardinal error of feature
> requests: assuming that if you think something is important, everyone
> else must too. Quite simply, other people aren't as interested as you
> in this particular feature. They're working on other things that they
> feel are more interesting or important. In the end, the people who
> are doing the work, or paying for it, call the shots on where
> resources are invested -- there is nothing that can change that.
The people who are paying for it... Hm, and by that you mean the
Foundation? Cause, the money comes from the users, by donations. And the
Foundation's purpose is to be the executing branch of the community.

I certainly have a POV. My POV is that of "let's make MediaWiki a more
powerful tool" and of "let's make MediaWiki easier for the wiki users".
If I look at the techblog post linked by Erik Möller I see some new
features that are aimed at the wiki users, like LiquidThreads, Upload
and AddMedia wizard, and Pending changes. But I also see several
features that are aimed solely at the Wikimedia employees, like media
storage architecture, monitoring, resource loader, CentralNotice,
Analytics, Selenium deployment, CiviCRM upgrade, and fraud prevention.

I don't want to say that these projects are bad ideas. They are
certainly very good ideas. But they have no big advantages to the
average wiki user.

In my opinion the work of the wiki volunteers is viewed as a cheap
resource. Well, it _is_ cheap, it doesn't cost us anything. But we
should value it more. Every day hundreds of working hours by our
volunteers are wasted to set interwiki links. This work would be
unnecessary if we had a central interwiki repository. In my own home
wiki more than three quarters of all edits are done by interwiki bots,
cluttering the edit histories.

So if you say that my support of the central interwiki repository is
based on false assumptions of importance then I really don't like your
assumptions of importance.

The central datawiki could immediately make available information on
millions of topics in dozens of languages with very few effort. It would
also improve the reliability of all our existing articles, even on
projects with big communities like en or de. If that is less important
than improved spamming using CentralNotice, then please tell me. The
oldest proposal for Wikidata I could find on Meta (although it's not
unlikely that the idea is even older) is from 2004 and was proposed by
Erik Möller. There are a bunch of other proposals for the same. So there
are much more people who deem this important than just me.

Maybe I appear as a grudgy grouser who dispraises your hard work and
doesn't contribute much myself, but all I want is that somebody maybe
says "oh, remember the days when we didn't care about financing plans
and fundraising and deployment and maintaining our servers, but when we
had visions about free access to the sum of all human knowledge!"

Marcus Buck
User:Slomox

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [HTML5] Improving Commons upload interface [ In reply to ]
"Marcus Buck" <wiki@marcusbuck.org> wrote in message
news:4C8172C8.1030609@marcusbuck.org...
> The people who are paying for it... Hm, and by that you mean the
> Foundation? Cause, the money comes from the users, by donations. And the
> Foundation's purpose is to be the executing branch of the community.

No, the purpose of the Foundation is to fulfil its stated vision and
principles. People join the communities, or donate, because they agree with
that vision; both are donations, or either money or time, towards the famous
"free access to all human knowledge". The Foundation does *not* serve the
community, nor the other way around; they work together in symbiosis, the
community doing the bulk of the heavy work, the Foundation being a more
streamlined and efficient decision-making process to guide the development.

> I certainly have a POV. My POV is that of "let's make MediaWiki a more
> powerful tool" and of "let's make MediaWiki easier for the wiki users".
> If I look at the techblog post linked by Erik Möller I see some new
> features that are aimed at the wiki users, like LiquidThreads, Upload
> and AddMedia wizard, and Pending changes. But I also see several
> features that are aimed solely at the Wikimedia employees, like media
> storage architecture, monitoring, resource loader, CentralNotice,
> Analytics, Selenium deployment, CiviCRM upgrade, and fraud prevention.
>
> I don't want to say that these projects are bad ideas. They are
> certainly very good ideas. But they have no big advantages to the
> average wiki user.
>
> In my opinion the work of the wiki volunteers is viewed as a cheap
> resource. Well, it _is_ cheap, it doesn't cost us anything. But we
> should value it more. Every day hundreds of working hours by our
> volunteers are wasted to set interwiki links. This work would be
> unnecessary if we had a central interwiki repository. In my own home
> wiki more than three quarters of all edits are done by interwiki bots,
> cluttering the edit histories.
>
> So if you say that my support of the central interwiki repository is
> based on false assumptions of importance then I really don't like your
> assumptions of importance.

No one is saying that CentralInterwiki isn't important, or that it wouldn't
be a huge improvement. We're saying that there are other projects which are
*more* beneficial to Wikimedia, in terms of increasing our reach, drawing in
new editors, and improving productivity, that are therefore more deserving
of our perpetually limited development time. Please understand the
difference between "not important" and "not _as_ important as...".

> Maybe I appear as a grudgy grouser who dispraises your hard work and
> doesn't contribute much myself, but all I want is that somebody maybe
> says "oh, remember the days when we didn't care about financing plans
> and fundraising and deployment and maintaining our servers, but when we
> had visions about free access to the sum of all human knowledge!"

Yes, those were the days when Wikimedia was a tiny fraction of its present
size, and where users were uploading dozens of duplicate files to each wiki
individually, where the technology was so far behind where it is today that
you can't even remember how hamstringed we were by it. Don't think that
going back to a time without any development team at all is going to make
your projects go any faster, it would just mean that all the other projects
would join them on the pile of "not going anywhere because no one's got any
money to spend on them".

--HM





_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 2  View All