Hi all,
We've got the first DRAFT (sorry for shouting, but can't hurt to emphasize :)) of the annual goals for the engineering/product department up on mediawiki.org. We're now mid-point in the process, and will finalize through June.
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals
Note that at this point in the process, teams have flagged inter-dependencies, but they've not necessarily been taken into account across the board, i.e. team A may say "We depend on X from team B" and team B may not have sufficiently accounted for X in its goals. :P Identifying common themes, shared dependencies, and counteracting silo tendencies is the main focus of the coming weeks. We may also add whole new sections for cross-functional efforts not currently reflected (e.g. UX standardization). Site performance will likely get its own section as well.
My own focus will be on fleshing out the overall narrative, aligning around organization-wide objectives, and helping to manage scope.
As far as quantitative targets are concerned, we will aim to set them where we have solid baselines and some prior experience to work with (a good example is Wikipedia Zero, where we now have lots of data to build targets from). Otherwise, though, our goal should be to _obtain_ metrics that we want to track and build targets from. This, in itself, is a goal that needs to be reflected, including expectations e.g. from Analytics.
Like last year, these goals won't be set in stone. At least on a quarterly basis, we'll update them to reflect what we're learning. Some areas (e.g. scary new features like Flow) are more likely to be significantly revised than others.
With this in mind: Please leave any comments/questions on the talk page (not here). Collectively we're smarter than on our own, so we do appreciate honest feedback:
- What are our blind spots? Obvious, really high priority things we're not paying sufficient attention to?
- Where are we taking on too much? Which projects/goals make no sense to you and require a stronger rationale, if they're to be undertaken at all?
- Which projects are a Big Deal from a community perspective, or from an architecture perspective, and need to be carefully coordinated?
These are all conversations we'll have in coming weeks, but public feedback is very helpful and may trigger conversations that otherwise wouldn't happen.
Please also help to carry this conversation into the wikis in coming weeks. Again, this won't be the only opportunity to influence, and I'll be thinking more about how the quarterly review process can also account for community feedback.
Warmly,
Erik
On Mon, Jun 9, 2014 at 9:24 PM, Erik Moeller erik@wikimedia.org wrote:
Hi all,
We've got the first DRAFT (sorry for shouting, but can't hurt to emphasize :)) of the annual goals for the engineering/product department up on mediawiki.org. We're now mid-point in the process, and will finalize through June.
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals
Note that at this point in the process, teams have flagged inter-dependencies, but they've not necessarily been taken into account across the board, i.e. team A may say "We depend on X from team B" and team B may not have sufficiently accounted for X in its goals. :P Identifying common themes, shared dependencies, and counteracting silo tendencies is the main focus of the coming weeks. We may also add whole new sections for cross-functional efforts not currently reflected (e.g. UX standardization). Site performance will likely get its own section as well.
My own focus will be on fleshing out the overall narrative, aligning around organization-wide objectives, and helping to manage scope.
As far as quantitative targets are concerned, we will aim to set them where we have solid baselines and some prior experience to work with (a good example is Wikipedia Zero, where we now have lots of data to build targets from). Otherwise, though, our goal should be to _obtain_ metrics that we want to track and build targets from. This, in itself, is a goal that needs to be reflected, including expectations e.g. from Analytics.
Like last year, these goals won't be set in stone. At least on a quarterly basis, we'll update them to reflect what we're learning. Some areas (e.g. scary new features like Flow) are more likely to be significantly revised than others.
With this in mind: Please leave any comments/questions on the talk page (not here). Collectively we're smarter than on our own, so we do appreciate honest feedback:
- What are our blind spots? Obvious, really high priority things we're
not paying sufficient attention to?
- Where are we taking on too much? Which projects/goals make no sense
to you and require a stronger rationale, if they're to be undertaken at all?
- Which projects are a Big Deal from a community perspective, or from
an architecture perspective, and need to be carefully coordinated?
These are all conversations we'll have in coming weeks, but public feedback is very helpful and may trigger conversations that otherwise wouldn't happen.
Please also help to carry this conversation into the wikis in coming weeks. Again, this won't be the only opportunity to influence, and I'll be thinking more about how the quarterly review process can also account for community feedback.
Warmly,
Erik
Hi Erik,
Can you describe how specific engineering projects are helping to address the gender gap? Do you typically review user-facing projects with the gender gap specifically in mind? I notice that while there is a FOSS outreach program for women, there is nothing specific in the Wikimania Hackathon materials to suggest that an effort was made to attract women to this event. There is another hackathon planned for early next year - will engineering make the gender gap part of the goals of that event?
I also notice that the editor engagement projects don't specifically list the gender gap or women users. I think that testing new features (such as communication tools, notifications, teahouse-style innovations and others that bear specifically on interactions) with female user/focus groups would greatly improve our understanding of how these tools impact the gender gap. For example: If part of the plan for the growth team is to invite anonymous editors to sign up, why not tailor some of those invitations specifically to female anonymous editors? Then you could add a measure, retention of female editors, to that particular growth project. The results should be instructive.
Likewise, it would be nice to see gender-gap related goals within VisualEditor and the user experience groups goals, and to see some focus from the Analytics and Research teams on measuring and understanding the gap better. Needless to say its a little disappointing that the FOSS outreach program (which currently has 8 participants) is the only mention of women in the entire goals document, and the gender gap is never mentioned.
Nathan
Nathan, 23/06/2014 19:28:
it would be nice to see gender-gap related goals within VisualEditor
Cf. https://meta.wikimedia.org/wiki/Research:Gender_micro-survey
Nemo
On Mon, Jun 23, 2014 at 10:28 AM, Nathan nawrich@gmail.com wrote:
Can you describe how specific engineering projects are helping to address the gender gap? Do you typically review user-facing projects with the gender gap specifically in mind? I notice that while there is a FOSS outreach program for women, there is nothing specific in the Wikimania Hackathon materials to suggest that an effort was made to attract women to this event. There is another hackathon planned for early next year - will engineering make the gender gap part of the goals of that event?
Dear Nathan,
Thanks for asking this question, and thanks to Sumana for the pointers to good places for deeper conversations.
At a high level, I think we need to be careful not to over-mandate engineering. Building a great experience for editing and discussion and testing it against a representative demographic cross-section is in itself a very complex undertaking (especially when doing so in the wonderful world of wikitext), without "And it also needs to increase the %/# of women participating in our projects" as a specific measure of success for each feature. I do want us to get better at more quickly and frequently capturing the demographic baseline data so we can at least understand the trends better. Quick, lightweight survey tools are high on the wishlist for a lot of folks, and we'll think about when/how to prioritize that in the overall roadmap.
Where I see some of the strongest potential to actually engage under-represented groups is in the area of task recommendations. Whenever we build systems that suggest things to do to new users, we're making implicit value judgments about what kinds of work we consider to be important. I think it's reasonable in this context to consider factors such as the under-representation of a topic area in the encyclopedia, which may draw in potential content contributors familiar with that topic specifically, and in turn counter systemic bias both in topic coverage and participation.
Erik
As an update on the goals process for WMF engineering, we've begun fleshing out out the top priorities for the first quarter. Going forward, we'll aim to call out the top priorities for each quarter as we approach it, to create more shared visibility into the most urgent and high-impact projects we're working on.
I've decided for now to use a division between "User-Impacting Changes" and "Cross-Functional Platform and Process Improvements". The intent of calling out both areas is to ensure that important organizational priorities don't fall off our collective radar. At the management level, the intent is for us to pay special attention to the priorities called out in this manner, and this may also impact our willingness to request help from across the organization if necessary to support these priorities, at least in Q1.
I've merged the current draft into the goals document, here: https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals#Top_depar...
Once again, this is draft and marked as such. The "Impact" column will include links to relevant metrics once those are a bit more solid; if you look further down in the document you'll see that these are being refined and tweaked in multiple areas right now.
A little bit of rationale for some items that may surprise you:
- I've decided to list HHVM as the top priority in both categories. This is because a) it's a very complex undertaking from an engineering perspective and requires significant coordination across development & operations, b) it's probably the biggest change regarding how code gets executed in production since we adopted PHP in the first place, c) the expected performance benefits for many uncached logged-in user operations are very significant (I defer to the team to quantify before throwing out estimates).
This is also indicative of the importance we're attaching to site performance. There's no question that performance is directly correlated with user engagement, and it's appropriate that we spend significant effort in this area.
- We're elevating SUL finalisation ( https://www.mediawiki.org/wiki/SUL_finalisation ) to a top priority, and I've classified it as user-impacting. This is because it's on the critical path for making it easier to develop cross-site functionality (as long as we have to deal with the edge case of "detached accounts", certain features that work across wikis are just trickier to implement), and one of those long term issues of technical debt we've been kicking down the road for years. It's also a pretty complex project -- if it goes wrong and we mess up our account database, we're in big trouble. So we want to make sure we have lots of eyeballs on this from a technical and community management perspective. We may not completely wrap up in Q1 since we need to give users whose accounts are affected significant warning time, which is just elapsed time we can't shorten.
- Front-end code standardization is called out as a top priority. We really need to dig ourselves out of the mess of having disjointed templating systems, widget libraries, and JS frameworks across our codebase if we want to increase development velocity and UX consistency. I'm prepared to sacrifice short term development velocity on other projects in order to make this happen.
- The content API that Gabriel is working on ( https://www.mediawiki.org/wiki/Requests_for_comment/Content_API ) is called out as a top priority. This is because the Parsoid output (for which the content API will be a high performance front-end) is now getting to the point where it's starting to become plausible to increasingly use it not just for VisualEditor, but also for views as well. The potential here are performance benefits across the board: for logged-in users in general by consistently relying on fast, cached output; for users loading VisualEditor by giving them most of the payload required to edit in read mode; for users saving through VisualEditor by potentially turning the wikitext transformation into a post-save asynchronous process and thereby making saves near instantaneous.
Moreover, it will put us on the long term path towards possibly using HTML5 as MediaWiki's native format, supporting HTML5-only wikis, and more. And it will be valuable for third party re-use and re-processing of Wikimedia content for a multitude of use cases. Last but not least, it's also a great use case for a service-oriented architecture including REST APIs & good/clean API documentation.
In short, this is a big deal, and it has lots and lots of architectural implications -- so raising the visibility on this is intended to get more people to actually think through what all of this means for the future of MediaWiki.
Other elements of the prioritization shouldn't be surprising: Phabricator is a big deal, and it's coming; Mobile (including new contributory features) and VE (including a really awesome new citations experience we're prepping for) continue to be high on the agenda, and we need to standardize and improve our quantitative measures across the board. Growth is going to work on new user acquisition in Q1 which didn't quite make the cut for the top 5 because it's not as broadly impacting as some of the other things listed here, but still a big deal -- as are other things not called out here. The intent isn't to demote anyone's work, but to give ourselves shared awareness of some of the most mission-critical things that are going on.
If you do feel the prioritization is off, leave a note on the talk page. It's still draft and we reserve the right to correct and adjust as we learn things, but we'll wrap the Q1 prioritization by July 1.
Thanks!
Erik
Erik Moeller, 27/06/2014 03:55:
As an update on the goals process for WMF engineering, we've begun fleshing out out the top priorities for the first quarter.
This has already been an interesting and useful exercise, I feel. Those are indeed goals which need help from everyone who can. Which brings me to:
[...]
- The content API that Gabriel is working on (
https://www.mediawiki.org/wiki/Requests_for_comment/Content_API ) is called out as a top priority. This is because the Parsoid output (for which the content API will be a high performance front-end) is now getting to the point where it's starting to become plausible to increasingly use it not just for VisualEditor, but also for views as well.
This is something I encourage everyone on this list to play with. I spent a couple days on Parsoid's output for it.wiki and it's been fun, finding many things to report: while reasonable pages are rarely very broken, on a random page there is some 50 % chance of finding some visual glitch.
My favourite toy to this purpose is Kiwix: * download a recent file for your favourite wiki at http://download.kiwix.org/zim/wikipedia/ , * download Kiwix to open it http://download.kiwix.org/nightly/bin/latest/ , * start pressing "random page" and report surprises e.g. to https://sourceforge.net/p/kiwix/bugs/
Nemo
I'm delighted to see a document that is clear enough to encourage useful comments from non-techies (on some parts of it)
I have 5, at increasing levels of specificity
1) At least in the US, the need for increasing contributions by underrepresented groups is not limited to women. Various ethnic groups in the US are even more under=represented. But I'm not sure how much of this is solvable by technology, either for them or for women.
2) The user retention goals are not the province of engineering alone, or even for the most part. Attracting initial contributors will indeed be greatly helped by Visual editor, but the enWP people will need considerable convincing about both features and interaction with the current editor and current procedures before doing what most needs to be done, making it the default for non-loggged in users. The other aspects are primarily that of improving the social environment and on-wiki processes at the individual WPs & Commons, and more effective work by the various chapters and associated projects. Flow will be of some help here, but it isn't the critical factor. I d I think the decline not only may be irreversible but ought to be expected to be irreversible: WP is no longer the most exciting thing in the world to the extent that it can have the same attractive power as in the first few years.
3)I have never understood the need for Flow- I find the existing talk page systems quite functional. But since many others don't find the current system satisfactory. the one place Flow should not be trialed on the enWP is the Teahouse, which has its own distinctive system. It should rather be trialed on places where there is long and particularly intricate discussions and were beginners are not likely to be confused.
4) The most intractable conflicts at enWP arise from the need to apply brief descriptive phrases or words to situations that ae inherently ambiguous. A system for category searching by intersection would eliminate about half the problems.
5) Perhaps this should be put off till the following year, but a system for constructing articles from infoboxes populated by wikidata would essentially give a fill in the blanks interface for constructing many types of articles. This would help beginners, and people writing in other than their native languages.,
On Fri, Jun 27, 2014 at 3:55 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Erik Moeller, 27/06/2014 03:55:
As an update on the goals process for WMF engineering, we've begun
fleshing out out the top priorities for the first quarter.
This has already been an interesting and useful exercise, I feel. Those are indeed goals which need help from everyone who can. Which brings me to:
[...]
- The content API that Gabriel is working on (
https://www.mediawiki.org/wiki/Requests_for_comment/Content_API ) is called out as a top priority. This is because the Parsoid output (for which the content API will be a high performance front-end) is now getting to the point where it's starting to become plausible to increasingly use it not just for VisualEditor, but also for views as well.
This is something I encourage everyone on this list to play with. I spent a couple days on Parsoid's output for it.wiki and it's been fun, finding many things to report: while reasonable pages are rarely very broken, on a random page there is some 50 % chance of finding some visual glitch.
My favourite toy to this purpose is Kiwix:
- download a recent file for your favourite wiki at
http://download.kiwix.org/zim/wikipedia/ ,
- download Kiwix to open it http://download.kiwix.org/nightly/bin/latest/
,
- start pressing "random page" and report surprises e.g. to
https://sourceforge.net/p/kiwix/bugs/
Nemo
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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Fri, Jun 27, 2014 at 3:55 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
My favourite toy to this purpose is Kiwix:
- download a recent file for your favourite wiki at
http://download.kiwix.org/zim/wikipedia/ ,
- download Kiwix to open it http://download.kiwix.org/nightly/bin/latest/ ,
- start pressing "random page" and report surprises e.g. to
I wrote http://nell-wikipedia.github.cscott.net a while ago with a similar goal. It is an offline wiki using parsoid output. It needs a bit of updating, since the Parsoid output has changed slightly since I wrote it.
But you can also use http://parsoid.wmflabs.org/enwiki/Main_Page directly now. The Parsoid output includes a style sheet which ought to render the parsoid DOM output identically to the standard PHP page output.
We're constructing a visual diff tool this quarter so that "soon" we should be able to do even better: testing for pixel-accurate matches against standard output. But that's not done yet, so bug reports on Parsoid output and CSS/rendering issues are still valuable. --scott
On 06/27/2014 01:51 PM, C. Scott Ananian wrote:
On Fri, Jun 27, 2014 at 3:55 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
My favourite toy to this purpose is Kiwix:
- download a recent file for your favourite wiki at
http://download.kiwix.org/zim/wikipedia/ ,
- download Kiwix to open it http://download.kiwix.org/nightly/bin/latest/ ,
- start pressing "random page" and report surprises e.g. to
I wrote http://nell-wikipedia.github.cscott.net a while ago with a similar goal. It is an offline wiki using parsoid output. It needs a bit of updating, since the Parsoid output has changed slightly since I wrote it.
But you can also use http://parsoid.wmflabs.org/enwiki/Main_Page directly now. The Parsoid output includes a style sheet which ought to render the parsoid DOM output identically to the standard PHP page output.
We're constructing a visual diff tool this quarter so that "soon" we should be able to do even better: testing for pixel-accurate matches against standard output. But that's not done yet, so bug reports on Parsoid output and CSS/rendering issues are still valuable.
We are beginning to get there. :-)
See https://github.com/subbuss/parsoid_visual_diffs/blob/master/diffs/enwiki.Med... for the latest pixel-level visual diff on a sample page. Within the next couple weeks, we should be able to start generating these on a wider range of pages and set up regression testing on them as well to track progress.
Subbu.
--scott
Hi Erik,
Thanks for sharing this update. It looks like a move in a good direction for WMF's engineering.
I am worried by how short-term the current plans/goals are, though. I know that a lot of work that the engineering department does, particularly with regards software, which can only be planned on a quarterly basis to ensure it's as agile and responsive to changing needs as possible. However, there's also the long-term view - what the key pieces of work that department wants to get done over the course of the next year or longer are - which is currently missing. I think this is particularly important for the engineering side of things (expected server capacity needs etc.), but it's also relevant for the software development side in terms of the larger picture.
Is there a wikipage available somewhere that sets out the long-term view/strategic priorities for the engineering department? If not, could I encourage you to think about starting one?
Thanks, Mike
On 27 Jun 2014, at 02:55, Erik Moeller erik@wikimedia.org wrote:
As an update on the goals process for WMF engineering, we've begun fleshing out out the top priorities for the first quarter. Going forward, we'll aim to call out the top priorities for each quarter as we approach it, to create more shared visibility into the most urgent and high-impact projects we're working on.
I've decided for now to use a division between "User-Impacting Changes" and "Cross-Functional Platform and Process Improvements". The intent of calling out both areas is to ensure that important organizational priorities don't fall off our collective radar. At the management level, the intent is for us to pay special attention to the priorities called out in this manner, and this may also impact our willingness to request help from across the organization if necessary to support these priorities, at least in Q1.
I've merged the current draft into the goals document, here: https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals#Top_depar...
Once again, this is draft and marked as such. The "Impact" column will include links to relevant metrics once those are a bit more solid; if you look further down in the document you'll see that these are being refined and tweaked in multiple areas right now.
A little bit of rationale for some items that may surprise you:
- I've decided to list HHVM as the top priority in both categories.
This is because a) it's a very complex undertaking from an engineering perspective and requires significant coordination across development & operations, b) it's probably the biggest change regarding how code gets executed in production since we adopted PHP in the first place, c) the expected performance benefits for many uncached logged-in user operations are very significant (I defer to the team to quantify before throwing out estimates).
This is also indicative of the importance we're attaching to site performance. There's no question that performance is directly correlated with user engagement, and it's appropriate that we spend significant effort in this area.
- We're elevating SUL finalisation (
https://www.mediawiki.org/wiki/SUL_finalisation ) to a top priority, and I've classified it as user-impacting. This is because it's on the critical path for making it easier to develop cross-site functionality (as long as we have to deal with the edge case of "detached accounts", certain features that work across wikis are just trickier to implement), and one of those long term issues of technical debt we've been kicking down the road for years. It's also a pretty complex project -- if it goes wrong and we mess up our account database, we're in big trouble. So we want to make sure we have lots of eyeballs on this from a technical and community management perspective. We may not completely wrap up in Q1 since we need to give users whose accounts are affected significant warning time, which is just elapsed time we can't shorten.
- Front-end code standardization is called out as a top priority. We
really need to dig ourselves out of the mess of having disjointed templating systems, widget libraries, and JS frameworks across our codebase if we want to increase development velocity and UX consistency. I'm prepared to sacrifice short term development velocity on other projects in order to make this happen.
- The content API that Gabriel is working on (
https://www.mediawiki.org/wiki/Requests_for_comment/Content_API ) is called out as a top priority. This is because the Parsoid output (for which the content API will be a high performance front-end) is now getting to the point where it's starting to become plausible to increasingly use it not just for VisualEditor, but also for views as well. The potential here are performance benefits across the board: for logged-in users in general by consistently relying on fast, cached output; for users loading VisualEditor by giving them most of the payload required to edit in read mode; for users saving through VisualEditor by potentially turning the wikitext transformation into a post-save asynchronous process and thereby making saves near instantaneous.
Moreover, it will put us on the long term path towards possibly using HTML5 as MediaWiki's native format, supporting HTML5-only wikis, and more. And it will be valuable for third party re-use and re-processing of Wikimedia content for a multitude of use cases. Last but not least, it's also a great use case for a service-oriented architecture including REST APIs & good/clean API documentation.
In short, this is a big deal, and it has lots and lots of architectural implications -- so raising the visibility on this is intended to get more people to actually think through what all of this means for the future of MediaWiki.
Other elements of the prioritization shouldn't be surprising: Phabricator is a big deal, and it's coming; Mobile (including new contributory features) and VE (including a really awesome new citations experience we're prepping for) continue to be high on the agenda, and we need to standardize and improve our quantitative measures across the board. Growth is going to work on new user acquisition in Q1 which didn't quite make the cut for the top 5 because it's not as broadly impacting as some of the other things listed here, but still a big deal -- as are other things not called out here. The intent isn't to demote anyone's work, but to give ourselves shared awareness of some of the most mission-critical things that are going on.
If you do feel the prioritization is off, leave a note on the talk page. It's still draft and we reserve the right to correct and adjust as we learn things, but we'll wrap the Q1 prioritization by July 1.
Thanks!
Erik
Erik Möller VP of Engineering and Product Development, 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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Sun, Jun 29, 2014 at 10:19 AM, Michael Peel email@mikepeel.net wrote:
I am worried by how short-term the current plans/goals are, though. I know that a lot of work that the engineering department does, particularly with regards software, which can only be planned on a quarterly basis to ensure it's as agile and responsive to changing needs as possible. However, there's also the long-term view - what the key pieces of work that department wants to get done over the course of the next year or longer are - which is currently missing. I think this is particularly important for the engineering side of things (expected server capacity needs etc.), but it's also relevant for the software development side in terms of the larger picture.
Is there a wikipage available somewhere that sets out the long-term view/strategic priorities for the engineering department? If not, could I encourage you to think about starting one?
Dear Mike,
Thanks for the thoughtful question.
On the subject of short term vs. long term precision, I'd encourage you (and others) to view Lila's presentation from the metrics meeting today [1]. We should be able to say with precision with what we're going to do in the next quarter and paint a general picture as to what we're going to do in a year.
There are indeed areas of planning that are a bit more predictable, e.g. hardware purchases. The line item detailed view of the budget is internal, but it includes year-long estimates for operating expenses and capital expenditures, for example, based on hardware inventory, warranty information, capacity projections, vendor agreements, and project planning. They can still be thrown off if a major project with lots of inter-dependencies like a data-center build-out falls behind schedule.
The current engineering draft goals do include team-level Q3 and Q4 goals, but I've been OK keeping these fairly minimal for now. What's more important is adding the narrative and through-line as well as department-wide targets, which is still on my to-do list. Lila added a couple of example dept-wide targets that we'll be fleshing out further. We've already stated some of this in the FDC proposal (esp. the mobile section), but I'll be bringing it into a more concise summary focused on explaining the strategic context and the expected outcomes.
I'm optimistic that as we develop this goalsetting framework further it can serve as a template for how some of this work is done organization-wide, potentially replacing the additional narratives developed for the Annual Planning/FDC process.
Erik
[1] https://www.youtube.com/watch?v=993lpGrittg
wikimedia-l@lists.wikimedia.org