Greetings!
Last week, the multimedia team had its first planning meeting for 2014-15 and we would like to share our proposed goals for the coming year (July 2014 to June 2015).
1. Goals This year, we would like to focus on improving the contribution and editing workflows, while addressing our technical debt and fixing critical bugs. To that end, we aim to: • engage more users to contribute media • add more media content on our sites • provide a smoother experience for all • fix critical bugs to make things work better.
2. Users Last year, we focused mostly on readers, with a focus on Media Viewer. This year, we propose to switch our focus to these users: • contributors -- the people who upload media on our sites • editors -- the people who add media on articles
Note that we aim to support both casual and experienced users within each group. We will initially focus on Commons users, then move on to serve more users on Wikipedia and other sites. Secondary user groups include admins, campaign organizers and developers.
3. Activities This year, we propose to invest our time on these main activities: • Structured Data: improve the way we store metadata — an important goal, because most other features depend on it. • Critical Bugs: fix urgent bugs in our infrastructure -- and become more familiar with our entire code base, including: - Image scalers, Core media handling, TimedMediaHandler, Media backend storage, Media Viewer, etc. • Features: develop or improve user-facing projects, including: - Upload Wizard -- our main user-facing project this year (includes Commons Upgrade and Modal Tool for other sites) - Other Features -- Media Viewer 0.3, File Notifications, File Page, Kaltura Player Upgrade, Campaign Tools
4. Roadmap We plan to spread out these activities throughout the coming year, as proposed in this rough timeline: • Q1: metrics, upload wizard fixes, structured data planning, bug fixes • Q2: structured data on Commons, new upload features, bug fixes • Q3: more structured data, modal upload tools, media viewer, notifications, bug fixes • Q4: insert media tools, A/V upgrade, file pages, more bug fixes
For a more detailed roadmap, visit this planning page for 2014-2015: https://www.mediawiki.org/wiki/Multimedia/2014-15_Goals
Note that these first milestones may be adjusted in coming weeks (and will be updated on a quarterly basis), based on prior quarter's results, as well as community and team discussions. To that end, we invite you to leave your feedback on this plan’s discussion page.
5. Upload Wizard We have now started our first phase of planning and development on Upload Wizard, and have prepared a first task list and proposed timeline on this updated project page: https://www.mediawiki.org/wiki/UploadWizard
In coming weeks, we will host focused community discussions about this Upload Wizard plan and its key features. We look forward to discussing some of the main challenges and solutions together. For now, please leave comments on that project’s discussion page.
Many thanks to all the community and team members who took the time to guide our work this year. We look forward to more great collaborations with you next year. :)
Regards as ever,
Fabrice - for the Multimedia Team
_______________________________
Fabrice Florin Product Manager, Multimedia Wikimedia Foundation
On Tue, Jun 3, 2014 at 1:59 AM, Fabrice Florin fflorin@wikimedia.org wrote:
• Q1: metrics, upload wizard fixes, structured data planning, bug fixes • Q2: structured data on Commons, new upload features, bug fixes
I'm delighted that structured data and metrics made it to the top priorities for the multimedia team and we're going to see improvements there. Long overdue, and i think that GLAM's all around the world will be very happy when they can finally update the metadata and see proper views for their uploaded media collections.
-- Hay
Hi,
• Q3: […] modal upload tools […]
Could you elaborate on what this term encompass? From the MediaWiki pages, I gather that this is about providing upload/multimedia bits & pieces to be used in other tools like VE or the mobile site? What would be these bits and pieces exactly? Would they be made only to be used by Wikimedia tools, or should we see it as libraires to build stuff outside (like, for example, desktop upload tools, or image editing software addons) ?
Thanks,
On 6/2/14, Fabrice Florin fflorin@wikimedia.org wrote:
Greetings!
Last week, the multimedia team had its first planning meeting for 2014-15 and we would like to share our proposed goals for the coming year (July 2014 to June 2015).
- Goals
This year, we would like to focus on improving the contribution and editing workflows, while addressing our technical debt and fixing critical bugs. To that end, we aim to: • engage more users to contribute media • add more media content on our sites • provide a smoother experience for all • fix critical bugs to make things work better.
- Users
Last year, we focused mostly on readers, with a focus on Media Viewer. This year, we propose to switch our focus to these users: • contributors -- the people who upload media on our sites • editors -- the people who add media on articles
Note that we aim to support both casual and experienced users within each group. We will initially focus on Commons users, then move on to serve more users on Wikipedia and other sites. Secondary user groups include admins, campaign organizers and developers.
"Editors" is a broad term. Often it is used to include many groups of people who don't add media to articles (e.g. People who delete inappropriate things, people who categorize files). Are we including them with "editors", or are we calling them something else (curators?). Developers is also an ambigious term encompassing multiple groups. When assumes you mean local js wizards? Or do you also include tool makers (as in tool labs), and people making third party upload tools. I assume you don't mean people interested in making multimedia related MediaWiki extensions.
- Activities
• Critical Bugs: fix urgent bugs in our infrastructure -- and become more familiar with our entire code base, including:
- Image scalers, Core media handling, TimedMediaHandler, Media backend
storage, Media Viewer, etc.
[..]
- Other Features -- Media Viewer 0.3, File Notifications, File Page,
Kaltura Player Upgrade, Campaign Tools
People have been saying that the kaltura player upgrade was going to be plopped into gerrit any day now for about the last six months. Do we have more information about what's going on with that and what sort of timeline it will be for it. I ask because the kaltura player update is going to replace an unknown portion of TimedMediaHandler code, so the pending nature of it means its blocking work on TimedMediaHandler, since not much point working on TimedMediaHandler if half the code is about to be replaced.
- Roadmap
We plan to spread out these activities throughout the coming year, as proposed in this rough timeline: • Q1: metrics, upload wizard fixes, structured data planning, bug fixes
From the linked page, "Multimedia Metrics - upload funnel analysis,
drop-off rate, UI clicks, # uploads, # uploaders, other upload tools, files used"
So this is going to exclude the types of metrics that GLAM folks are interested in? (From what I understand (I'm not sure about this, so correct me if I am wrong), glam folks are interested in page hits for media files (Currently we have hits for file description pages, but not the file assets) along with improvements/support for Magnus's glamourus thing and more query-able versions of the hourly page hits statistics in the vein of what Henrik does)
-- -bawolff
On Wed, Jun 4, 2014 at 1:45 PM, Brian Wolff bawolff@gmail.com wrote:
- Roadmap
We plan to spread out these activities throughout the coming year, as proposed in this rough timeline: • Q1: metrics, upload wizard fixes, structured data planning, bug fixes
From the linked page, "Multimedia Metrics - upload funnel analysis, drop-off rate, UI clicks, # uploads, # uploaders, other upload tools, files used"
So this is going to exclude the types of metrics that GLAM folks are interested in? (From what I understand (I'm not sure about this, so correct me if I am wrong), glam folks are interested in page hits for media files (Currently we have hits for file description pages, but not the file assets) along with improvements/support for Magnus's glamourus thing and more query-able versions of the hourly page hits statistics in the vein of what Henrik does)
File view count is something we plan to work on (see #628 https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/628 and the related thread https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/628 on analytics-l). AFAIK improving pageview stats is something the analytics team intends to take on; for us it is not really in scope. GLAMorous is about file usage; we plan to track usage of file groups (to see whether there is a difference in the usefulness of files uploaded in different ways). The way we will do that might or might not be useful for GLAM people, it is too early to say. (Of course if they tell us what exactly they need, that will increase the chance of us being able to choose an implementation which they can use as well.)
On Wed, Jun 4, 2014 at 4:13 PM, Gergo Tisza gtisza@wikimedia.org wrote:
(Of course if they tell us what exactly they need, that will increase the chance of us being able to choose an implementation which they can use as well.)
Lots of well-organized thinking on that already:
https://upload.wikimedia.org/wikipedia/commons/a/a2/Report_on_requirements_f... https://outreach.wikimedia.org/wiki/GLAM/Resources/Tools
On Wed, Jun 4, 2014 at 9:11 PM, Erik Moeller erik@wikimedia.org wrote:
On Wed, Jun 4, 2014 at 4:13 PM, Gergo Tisza gtisza@wikimedia.org wrote:
(Of course if they tell us what exactly they need, that will increase
the chance
of us being able to choose an implementation which they can use as well.)
Lots of well-organized thinking on that already:
https://upload.wikimedia.org/wikipedia/commons/a/a2/Report_on_requirements_f... https://outreach.wikimedia.org/wiki/GLAM/Resources/Tools
Some relevant work in this area was already done at the Zurich hackathon:
https://commons.wikimedia.org/wiki/Commons:GLAMwiki_Toolset_Project/NARA_ana...
Fabrice & team,
A bit past the goals deadline, but I hope I can still be useful :)
On Mon, Jun 02, 2014 at 04:59:05PM -0700, Fabrice Florin wrote:
- Activities
This year, we propose to invest our time on these main activities: • Structured Data: improve the way we store metadata — an important goal, because most other features depend on it. • Critical Bugs: fix urgent bugs in our infrastructure -- and become more familiar with our entire code base, including:
- Image scalers, Core media handling, TimedMediaHandler, Media backend storage, Media Viewer, etc.
• Features: develop or improve user-facing projects, including:
- Upload Wizard -- our main user-facing project this year (includes Commons Upgrade and Modal Tool for other sites)
- Other Features -- Media Viewer 0.3, File Notifications, File Page, Kaltura Player Upgrade, Campaign Tools
I notice that you've split the roadmap into "critical bugs" and "features". What exactly do you mean by "critical" here? Is there time allocated for non-critical but also non-feature work, e.g. infrastructure/architecture design?
Our current media infrastructure is getting old, has been traditionally under-resourced and hence has accumulated technical debt over the years.
As an example, there are currently four RFCs related to thumbnails and I'm sure opinions on their characterization as "critical" would vary. Additionally, as you know, we've had some outage lately that can and have been dealt with by deploying hotfixes, but unless we invest time on a properly scalable & secure architecture these issues will keep cropping up. Our thumbnailing architecture could surely use some love :)
My impression is that the team has been doing a bit of both, as time permits; is this the plan going forward as well? I've discussed various ideas with the team (mostly Gilles) and I know there is both the will and the necessary combination of skill and experience to do those larger changes, so I'm wondering if there's going to be time allocated for this, this upcoming FY.
Thanks, Faidon
Dear Faidon,
Sorry for not responding sooner to your thoughtful recommendations about next year’s plan.
We have been swamped this week, to address a flood of community responses to Media Viewer on Enwiki, and are just now catching up with previously scheduled tasks. :)
To answer your question below, the ‘Critical bugs’ category intends to cover two main activities: critical bugs and technical debt. We are allocating about a third of our time to this category next year, evenly split between these two activities.
We have purposely kept that category open-ended, so we can determine every few weeks which specific tasks to take on: for example, when image scaler issues started causing problems for the operations team, we switched our focus to work on solutions to those issues.
So if the thumbnails issue you describe below turns out to be the most critical issue to tackle next, we would turn our attention to that problem, using up that 30% of team capacity to attempt solving it. Over time, we hope to address some of the most important issues with our aging media infrastructure.
Gilles will be spearheading that technical initiative, in collaboration with Mark and Gergo. He is on vacation this week, but can respond in more detail then.
In the meantime, I hope this first answer can give you a sense of where we’re headed.
We look forward to working with you to make progress on these fronts in the coming year.
Regards as ever,
Fabrice
On Jun 7, 2014, at 7:51 PM, Faidon Liambotis faidon@wikimedia.org wrote:
Fabrice & team,
A bit past the goals deadline, but I hope I can still be useful :)
On Mon, Jun 02, 2014 at 04:59:05PM -0700, Fabrice Florin wrote:
- Activities
This year, we propose to invest our time on these main activities: • Structured Data: improve the way we store metadata — an important goal, because most other features depend on it. • Critical Bugs: fix urgent bugs in our infrastructure -- and become more familiar with our entire code base, including:
- Image scalers, Core media handling, TimedMediaHandler, Media backend storage, Media Viewer, etc.
• Features: develop or improve user-facing projects, including:
- Upload Wizard -- our main user-facing project this year (includes Commons Upgrade and Modal Tool for other sites)
- Other Features -- Media Viewer 0.3, File Notifications, File Page, Kaltura Player Upgrade, Campaign Tools
I notice that you've split the roadmap into "critical bugs" and "features". What exactly do you mean by "critical" here? Is there time allocated for non-critical but also non-feature work, e.g. infrastructure/architecture design?
Our current media infrastructure is getting old, has been traditionally under-resourced and hence has accumulated technical debt over the years.
As an example, there are currently four RFCs related to thumbnails and I'm sure opinions on their characterization as "critical" would vary. Additionally, as you know, we've had some outage lately that can and have been dealt with by deploying hotfixes, but unless we invest time on a properly scalable & secure architecture these issues will keep cropping up. Our thumbnailing architecture could surely use some love :)
My impression is that the team has been doing a bit of both, as time permits; is this the plan going forward as well? I've discussed various ideas with the team (mostly Gilles) and I know there is both the will and the necessary combination of skill and experience to do those larger changes, so I'm wondering if there's going to be time allocated for this, this upcoming FY.
Thanks, Faidon
_______________________________
Fabrice Florin Product Manager Wikimedia Foundation
What exactly do you mean by "critical" here? Is there time allocated for non-critical but also non-feature work, e.g. infrastructure/architecture design?
We consider improvements to be "critical" in the scope of the multimedia team's responsibilities. We don't want to do only hotfixes, we want to improve the code in all those areas. So yes, the idea is to allocate a third of our time in the coming year to improving those areas. We've already started working on thumbnailing code in particular (still in review) and raised the bar in terms of code quality and test coverage compared to the existing code. Until a few weeks ago we barely dedicated any time to these tasks and recently we've been able to give more focus to it. I expect that the 33% capacity goal will be achievable once the Media Viewer post-launch UX fixes are out of the way. Right now despite our prioritization efforts urgent Media Viewer tasks keep coming up, as a result of the enwiki/dewiki launch.
On Sun, Jun 8, 2014 at 4:51 AM, Faidon Liambotis faidon@wikimedia.org wrote:
Fabrice & team,
A bit past the goals deadline, but I hope I can still be useful :)
On Mon, Jun 02, 2014 at 04:59:05PM -0700, Fabrice Florin wrote:
- Activities
This year, we propose to invest our time on these main activities: • Structured Data: improve the way we store metadata — an important
goal, because most other features depend on it.
• Critical Bugs: fix urgent bugs in our infrastructure -- and become
more familiar with our entire code base, including:
- Image scalers, Core media handling, TimedMediaHandler, Media backend
storage, Media Viewer, etc.
• Features: develop or improve user-facing projects, including:
- Upload Wizard -- our main user-facing project this year (includes
Commons Upgrade and Modal Tool for other sites)
- Other Features -- Media Viewer 0.3, File Notifications, File Page,
Kaltura Player Upgrade, Campaign Tools
I notice that you've split the roadmap into "critical bugs" and "features". What exactly do you mean by "critical" here? Is there time allocated for non-critical but also non-feature work, e.g. infrastructure/architecture design?
Our current media infrastructure is getting old, has been traditionally under-resourced and hence has accumulated technical debt over the years.
As an example, there are currently four RFCs related to thumbnails and I'm sure opinions on their characterization as "critical" would vary. Additionally, as you know, we've had some outage lately that can and have been dealt with by deploying hotfixes, but unless we invest time on a properly scalable & secure architecture these issues will keep cropping up. Our thumbnailing architecture could surely use some love :)
My impression is that the team has been doing a bit of both, as time permits; is this the plan going forward as well? I've discussed various ideas with the team (mostly Gilles) and I know there is both the will and the necessary combination of skill and experience to do those larger changes, so I'm wondering if there's going to be time allocated for this, this upcoming FY.
Thanks, Faidon
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
multimedia@lists.wikimedia.org