All,
this is a quick note to let you know that we've signed on two people, William Pietri and Howie Fung, to help us on a contract basis with the deployment of Flagged Revisions on the English Wikipedia.
William is an IT consultant and systems/software engineer; see his userpage at http://en.wikipedia.org/wiki/User:William_Pietri -- he is also a long-time Wikipedian. He will support the overall roll-out coordination and requirements planning.
Howie is an experienced Product Manager who previously worked with Real Networks/Rhapsody and PayPal; see LinkedIn profile here: http://www.linkedin.com/profile?viewProfile=&key=3830901.
We met Howie during our search for the Multimedia Usability Product Manager position, and were impressed by his background, particularly with regard to user focused product development, and some great first thoughts he sent us on how to improve the usability of Wikimedia Commons. Given his background, we thought it would be great to have his help in doing some more systematic analysis of usability, terminology and workflow issues with the proposed English Wikipedia roll-out.
We are eager to roll out the "Flagged Protection" functionality soon. As Howie and William get up to speed, they'll post info on remaining work, and get community feedback on what's vital to have before the first release.
Erik Moeller wrote:
We met Howie during our search for the Multimedia Usability Product Manager position, and were impressed by his background, particularly with regard to user focused product development, and some great first thoughts he sent us on how to improve the usability of Wikimedia Commons.
So right now, they are only hired to roll out flagged revs on en.wp. I think that improvements to Commons are at least as vital as en.wp problems, seeing that Commons is a mess in many places right now. Are there any plans to hire him for a Commons makeover? What exactly did he propose we improve? Have those improvements been published and discussed?
Regards,
ChrisiPK
Hoi, There is a meeting of "Commons" people in Paris in November.. so Commons is not forgotten. The issue is that it makes sense to finnish things. One of my biggest frustrations is how long things take. It is for this reason that I am so pleased with the Usability Initiative because it regularly produces results. It is not an unending wait for whatever reason.
There is considerable stress to get Flagged Revisions rolled out. Let us get it over and done with so that we can move to other things.. for instance improvements to Commons..
FYI I have an interest in improving several things for Commons. Some things are waiting for adoption for over a year and I am not done waiting. Thanks, GerardM
2009/10/16 ChrisiPK chrisipk@gmail.com
Erik Moeller wrote:
We met Howie during our search for the Multimedia Usability Product Manager position, and were impressed by his background, particularly with regard to user focused product development, and some great first thoughts he sent us on how to improve the usability of Wikimedia Commons.
So right now, they are only hired to roll out flagged revs on en.wp. I think that improvements to Commons are at least as vital as en.wp problems, seeing that Commons is a mess in many places right now. Are there any plans to hire him for a Commons makeover? What exactly did he propose we improve? Have those improvements been published and discussed?
Regards,
ChrisiPK
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Gerard Meijssen wrote:
There is considerable stress to get Flagged Revisions rolled out. Let us get it over and done with so that we can move to other things.. for instance improvements to Commons..
I was not arguing that we delay Flagged Revs for Commons' sake, I was only interested whether Commons would also get some hired councilors (or whatever they are). Sorry if that was how my post read. I'm surprised anyway that it takes two employees to deploy a feature which other projects have implemented with community consensus only and without official support, but that's not at issue here.
Gerard Meijssen wrote:
FYI I have an interest in improving several things for Commons. Some things are waiting for adoption for over a year and I am not done waiting.
So do I and I think we need to make some sort of summary what we actually want to do. I have tried this by creating a proposal on the strategy wiki[1], but there has not been an awful lot of input over there. If you know a better place where such discussion should take place, please let me know. Also some sort of watchlist would be nice where suggested improvemets are listed, among with improvements awaiting implementation and so on.
Thanks and regards,
ChrisiPK
ChrisiPK wrote:
Gerard Meijssen wrote:
FYI I have an interest in improving several things for Commons. Some things are waiting for adoption for over a year and I am not done waiting.
So do I and I think we need to make some sort of summary what we actually want to do. I have tried this by creating a proposal on the strategy wiki[1], but there has not been an awful lot of input over there. If you know a better place where such discussion should take place, please let me know. Also some sort of watchlist would be nice where suggested improvemets are listed, among with improvements awaiting implementation and so on.
Thanks and regards,
ChrisiPK
There is http://commons.wikimedia.org/wiki/Commons:Bugs listing a good number of things that we want. If Howie is going to work "improving commons" I hope him to cut down that list, instead of working on a new feature that he thought might be neat. I'm not trying to discourage new ideas, they wouldprobably be good. But I see that the Foundation POV of the issues needing tech attention is often different than the one seen from the community, since the work for many hires surprise me. For example, I don't think that working on LiquidThreads would have been pointed as a priority by many members (the current system is "not too broken"). Strategy intends to learn which things are important, but just having a developer coming to the Village Pump to implement whatever the local community needs [and is reasonable] could make a difference. It wouldn't be appropiate for Big Changes, but would give an easy say for many small changes that may simply annoy them. Making volunteers happy is important, too.
2009/10/16 Platonides Platonides@gmail.com:
Strategy intends to learn which things are important, but just having a developer coming to the Village Pump to implement whatever the local community needs [and is reasonable] could make a difference.
I agree that we need a healthy mix of project-based work (where we identify priorities together, but WMF ultimately needs to make a call of where it wants to focus its resources) and reactive work that is about fixing or assigning small bugs, integrating existing community-built extensions or making toolserver hacks into core functionality, reviewing code, etc. This is why in addition to larger scale project-based work and project contracts, we also are growing our core team. The recently posted Code Maintenance Engineer position falls into the core team category:
http://wikimediafoundation.org/wiki/Job_openings/Code_Maintenance_Engineer
We have additional positions budgeted later in the year, and if the fundraiser performs according to plan, we'll continue to expand both project and core capacity. I think even if WMF were 10 times as large as it is, though, we'd still have many of the same conversations about "why this thing and not the other thing" all the time - probably more, because there'd be more resources to compete for. :-)
On Fri, Oct 16, 2009 at 9:58 AM, Platonides Platonides@gmail.com wrote:
ChrisiPK wrote:
Gerard Meijssen wrote:
FYI I have an interest in improving several things for Commons. Some things are waiting for adoption for over a year and I am not done waiting.
So do I and I think we need to make some sort of summary what we actually want to do. I have tried this by creating a proposal on the strategy wiki[1], but there has not been an awful lot of input over there. If you know a better place where such discussion should take place, please let me know. Also some sort of watchlist would be nice where suggested improvemets are listed, among with improvements awaiting implementation and so on.
Thanks and regards,
ChrisiPK
There is http://commons.wikimedia.org/wiki/Commons:Bugs listing a good number of things that we want. If Howie is going to work "improving commons" I hope him to cut down that list, instead of working on a new feature that he thought might be neat. I'm not trying to discourage new ideas, they wouldprobably be good. But I see that the Foundation POV of the issues needing tech attention is often different than the one seen from the community, since the work for many hires surprise me. For example, I don't think that working on LiquidThreads would have been pointed as a priority by many members (the current system is "not too broken"). Strategy intends to learn which things are important, but just having a developer coming to the Village Pump to implement whatever the local community needs [and is reasonable] could make a difference. It wouldn't be appropiate for Big Changes, but would give an easy say for many small changes that may simply annoy them. Making volunteers happy is important, too.
Rather than having developers visit village pumps on various projects, it would be good for a standard and well-advertised technical forum to be set up somewhere (mediawiki.org, meta) to discuss feature requests from the community and help communicate community desires and priorities to the developer community. Bugzilla sort of serves that purpose now, but I know that many people are intimidated by that format and it isn't well suited for general consensus gauging discussions.
-Robert Rohde
Robert Rohde wrote:
Rather than having developers visit village pumps on various projects, it would be good for a standard and well-advertised technical forum to be set up somewhere (mediawiki.org, meta) to discuss feature requests from the community and help communicate community desires and priorities to the developer community. Bugzilla sort of serves that purpose now, but I know that many people are intimidated by that format and it isn't well suited for general consensus gauging discussions.
-Robert Rohde
Having the developer come to your Village Pump instead of going to The Site* where the powerful devs live, makes him closer.
*Please, don't make yet another wiki for that.
On Fri, Oct 16, 2009 at 8:43 AM, ChrisiPK chrisipk@gmail.com wrote:
So right now, they are only hired to roll out flagged revs on en.wp. I think that improvements to Commons are at least as vital as en.wp problems, seeing that Commons is a mess in many places right now.
I don't know any more about the decision than you do, but I would point out that a) FlaggedRevs is all coded and ready for deployment, unlike most Commons features that are desired; and b) Wikimedia has made a quite public commitment to deploy FlaggedRevs soon, unlike any Commons features. It's not like Commons has been ignored, anyway -- the new-upload branch should greatly benefit Commons, from what I've heard. It's just apparently not ready for deployment yet.
I'm not trying to discourage anyone for poking people about improvements to Commons here, of course. I'm sure more work should be put into Commons. But at this precise moment, prioritizing this one specific enwiki feature seems to make sense.
Aryeh Gregor wrote:
[snip] It's not like Commons has been ignored, anyway -- the new-upload branch should greatly benefit Commons, from what I've heard. It's just apparently not ready for deployment yet.
... here is a quick update...
New upload branch has been deployed for a few weeks now. You can take advantage of some of its feature set with the mwEmbed gadgets: http://techblog.wikimedia.org/2009/10/new-media-features-gadget/
I hope to transition those gadgets to be 'enabled by default' or 'opt-in' as part of the usability efforts. Not sure how that will work yet.
The next big things coming up:
a) enabling copy-by-url uploads on commons then in-line insert from remote repositories and in-line uploading can be exposed as seen on http://prototype.wikimedia.org/sandbox.2/Main_Page
b) getting a api-iframe-proxy in-place so you can do those in-line uploads and remote inserts into commons from any edit page on *.wikipedia or arbitrary approved remote domains.
Also aim to polish up the ogg derivatives extension 'wikiAtHome'. Also in the nearish future I should be working on sequencer support, multi-lingual timed text for video subtitles / annotations, SVG parametrization, and finishing up the javascript language packaging system support for template parameters ( early version here: http://prototype.wikimedia.org/s-2/js2/mwEmbed/tests/testLang.html (only English showed but some progress has been made on a general cldr interpreter)
More general overview of media projects efforts is available here: http://www.mediawiki.org/wiki/Media_Projects_Overview
peace, michael
2009/10/16 ChrisiPK chrisipk@gmail.com:
So right now, they are only hired to roll out flagged revs on en.wp. I think that improvements to Commons are at least as vital as en.wp problems, seeing that Commons is a mess in many places right now. Are there any plans to hire him for a Commons makeover?
As per
http://wikimediafoundation.org/wiki/Press_releases/Wikimedia_Ford_Foundation...
we have a $300,000 project underway to improve the usability of Wikimedia Commons. We've just about wrapped up the hiring process for it, and will make an announcement soon. Please note that Howie and William are contractors, not full-time employees; they're supporting FlaggedRevs on a part-time basis, and Howie will also provide some support to the Commons project.
Erik Moeller wrote:
All,
this is a quick note to let you know that we've signed on two people, William Pietri and Howie Fung, to help us on a contract basis with the deployment of Flagged Revisions on the English Wikipedia.
William is an IT consultant and systems/software engineer; see his userpage at http://en.wikipedia.org/wiki/User:William_Pietri -- he is also a long-time Wikipedian. He will support the overall roll-out coordination and requirements planning.
Howie is an experienced Product Manager who previously worked with Real Networks/Rhapsody and PayPal; see LinkedIn profile here: http://www.linkedin.com/profile?viewProfile=&key=3830901.
We met Howie during our search for the Multimedia Usability Product Manager position, and were impressed by his background, particularly with regard to user focused product development, and some great first thoughts he sent us on how to improve the usability of Wikimedia Commons. Given his background, we thought it would be great to have his help in doing some more systematic analysis of usability, terminology and workflow issues with the proposed English Wikipedia roll-out.
We are eager to roll out the "Flagged Protection" functionality soon. As Howie and William get up to speed, they'll post info on remaining work, and get community feedback on what's vital to have before the first release.
What exactly is William going to be doing? From what I understood, all of the coding work is basically done and enwiki has settled on a configuration (and if there is coding work to do, it seems like it would make more sense to hire someone who is already familiar with the FlaggedRevs/MediaWiki code).
As far as usability goes, FlaggedRevs has been in use on other large projects (German Wikipedia, English Wikinews) for quite a while now, and I know the eventual goal has been to have this on the English Wikipedia, why did we wait until now to start studying this?
This seems like it has the potential to introduce even more delays into something that people are already impatient for.
2009/10/16 Alex mrzmanwiki@gmail.com:
What exactly is William going to be doing?
For one thing, hand-hold the process until the technology is rolled out, since there is nobody else internally who can actually devote any attention to it - Brion just left the organization, so we have a CTO vacancy to fill, plus several other key vacancies, and an upcoming fundraiser, etc. The project needs focused attention.
Secondly, while the technology is basically feature-complete at least for the flagged protection part, the configuration used on en.wp is unique: it's a per-page approach to FlaggedRevs. The flagged protection functionality was integrated into the page protection UI by Aaron just very recently, for example, and we need to systematically assess things like labels, icons, and workflows together with the community, which will require a few further changes to the extension as well. Again, this is about coordinating this process.
Hi, folks! Erik already answered this, but I wanted to add one bit.
Alex wrote:
What exactly is William going to be doing? [...]
This seems like it has the potential to introduce even more delays into something that people are already impatient for.
That's a very reasonable worry, but I don't think that will be the case.
Aaron will continue to do any coding[1], and my goal is to maximize the amount of time he can spend actually doing that. Partly by handling the communication with the community, and partly by turning that, plus Howie's usability recommendations, into a queue of clear, precise feature requests.
In addition, I'm hoping we can split the future work into a series of releases, rather than one big one. That will let us get the core part out as soon as possible. Not only will that benefit readers and the community, but feedback and data from real-world usage will help make future releases better.
William
[1] If I end up with extra cycles, I'd love to write some automated tests for this to hook into the existing test suite. The usage by the en and de wikis is divergent enough that it seems like there's a real risk of accidentally breaking something, and I'd rather have the computer do my worrying for me. I aim to stay out of the production code, though.
On Fri, Oct 16, 2009 at 2:26 PM, William Pietri william@scissor.com wrote:
[1] If I end up with extra cycles, I'd love to write some automated tests for this to hook into the existing test suite.
What existing test suite?
Aryeh Gregor wrote:
On Fri, Oct 16, 2009 at 2:26 PM, William Pietri william@scissor.com wrote:
[1] If I end up with extra cycles, I'd love to write some automated tests for this to hook into the existing test suite.
What existing test suite?
Well, looking here, I see a column for "Tests":
http://www.mediawiki.org/wiki/Special:Code/MediaWiki
I figure that means there are some tests in the code base and a continuous integration server that runs them. And I see at least a brief mention of testing here:
http://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Testing
If anybody has more info, though, I'm all ears.
William
Right now the only test we run is the parser tests which is just a big list of expected input/output for the parser. It's by no means complete and only covers the parser.
The stuff in /t and /tests should be ignored...as they're wildly out of date and completely unmaintaned.
-Chad
On Oct 16, 2009 2:35 PM, "William Pietri" william@scissor.com wrote:
Aryeh Gregor wrote: > On Fri, Oct 16, 2009 at 2:26 PM, William Pietri < william@scissor.com> wrote: >... Well, looking here, I see a column for "Tests":
http://www.mediawiki.org/wiki/Special:Code/MediaWiki
I figure that means there are some tests in the code base and a continuous integration server that runs them. And I see at least a brief mention of testing here:
http://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Testing
If anybody has more info, though, I'm all ears.
William
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia...
Hi, Chad. Thanks for the help.
Chad wrote:
Right now the only test we run is the parser tests which is just a big list of expected input/output for the parser. It's by no means complete and only covers the parser.
That's interesting. Some tests are better than no tests, for sure.
Luckily, we have a giant corpus of known-good inputs and outputs, so it would be fun to do some mutation testing to find the holes in the parser coverage. At a conference yesterday I asked around to see if anybody had heard of a mutation testing tool (like http://jester.sourceforge.net/) for PHP and regexes, but alas, nobody had.
If somebody gets interested in that, let me know, and I'm glad to dig further.
The stuff in /t and /tests should be ignored...as they're wildly out of date and completely unmaintaned.
Good to know. If I get to the point where I have time to write tests, I'll ask here further about the best way to go about it.
William
On Fri, Oct 16, 2009 at 8:41 PM, Chad innocentkiller@gmail.com wrote:
The stuff in /t and /tests should be ignored...as they're wildly out of date and completely unmaintaned.
I suggest that we svn rm them, because they are only tricking people into thinking we have a testing framework.
Bryan
On Fri, Oct 16, 2009 at 2:35 PM, William Pietri william@scissor.com wrote:
And I see at least a brief mention of testing here:
http://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Testing
I've updated that to be more accurate.
Aryeh Gregor wrote:
On Fri, Oct 16, 2009 at 2:35 PM, William Pietri william@scissor.com wrote:
And I see at least a brief mention of testing here:
http://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Testing
I've updated that to be more accurate.
Thanks. That's helpful to know.
If end up with enough time to do something about the lack of tests, I'll start by bringing it up here to see if there's a way to do it that avoids the fate of previous efforts.
Thanks,
William
wikitech-l@lists.wikimedia.org