[Wikimedia-l] [Announcement] James Forrester joins WMF as Technical Product Analyst
Everyone, It’s my pleasure to announce that James Forrester is joining our San Francisco office as a Technical Product Analyst, supporting the Visual Editor team. James started his work as a remote contractor yesterday and will be joining us in San Francisco later this year as a staff member. James will help prioritize the short term and long term work log on the Visual Editor, conduct user research, and incorporate community feedback into the development process. As many of you know, James is a long-time Wikimedian. He started contributing to English Wikipedia in October 2002, and was a founding member of their Arbitration Committee. He was also the movement’s volunteer Chief Research Officer, helping shepherd the predecessor of what is today the Research Committee, has for years been the “gopher-in-chief” at the Wikimania community conferences, and helped found Wikimedia UK in 2005. James joins us following a successful career in the UK government, where he implemented key open access and open government initiatives. Most recently, he was the acting Head of data.gov.uk, and then the Digital Engagement Policy Lead in the Government Digital Service, both at the Cabinet Office. James holds a Masters of Engineering in Computer Science from the University of Warwick. Beyond technology, James has strong interests in international politics, physics, communications, economics, law, the constitutional history of Britain, and education. Please join me in welcoming James! Howie ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure
Picking up this thread as Erik asked me to explain the different functions that fall under Product. To do that, it's worth describing in a bit more detail how our project teams work. This may be a bit reductive (apologies in advance), but there are a basic set of things that need to happen when building a product. These things happen regardless of what the product actually is (e.g., t-shirts count): 1. Decide what to build 2. Design it 3. Build it 4. Measure how it's used (if you want to improve the product) Roughly speaking, that's how we organize our teams when it comes to building features. Product Managers decide what features to build, Designers design the feature, Developers build the feature, and Analysts measure how the features perform. (features = things on our websites or mobile that readers or editors would use). Let's take PageCuration as an example of a feature that WMF developed. In this case, the feature development team consisted of a Product Manager, Designers, Developers, and Analysts, all working together. Here's how the various roles worked: 1. Product Manager [1]: Represents the user's point of view. Works with the rest of the team to identify and solve a user problem. For example, we knew that the backlog for Special:NewPages on the English Wikipedia was consistently too large and that existing page patrollers felt overworked. To solve the problem, we needed to make page patrolling more efficient [2]. Product Manager worked with the rest of the team to develop potential solutions to this problem. The outcome of this was the decision to build two separate features for the end user (i.e., page patrollers): Special:NewPagesFeed [3] (redesign of Special:NewPages) and the Curation Toolbar. The Product Manager worked with the rest of the WMF and volunteers in the community to identify specific features by asking question such as If we were to redesign Special:NewPages, what kind of information would page patrollers want to see that would make their jobs more efficient. Out of this inquiry came ideas like surfacing the # of categories, # of citations, whether an article is an orphan, a snippet of the content, etc. as these pieces of information would help the patroller determine which articles warranted attention. Fabrice Florin was the Product Manager. We also have a Community Liaison (Oliver Keyes) who is responsible for reaching out to the editor community to make sure the feature we're building actually meets the needs of our editors. The Community Liaison creates the space where community members can give input into the feature by holding IRC chats, on-wiki discussions, reaching out to editors, etc. 2. Designer: The designer then takes this input and designs the user interface for Special:NewPagesFeed. Part of this is Interaction Design [4] e.g., how are the elements of the page laid out so that page patrollers can easily parse the information? How does a page patroller actually accomplish the task of selecting an article to review (e.g., should there be a Review button associated with each article, or should the article link be sufficient?). Does this action open up a separate tab? How should filtering of this list work? Etc. There's also Visual Design: How do we use color to help identify the different states of an article? How can icons be used to reduce the cognitive load associated with parsing information? How can we create a look feel that's visually engaging? Brandon Harris and Vibha Bamba were the designers for Page Curation. 3. Developer: The developers then take these functional and design ideas and code the feature. On this project, the developers were Ryan Kaldari and Benny Situ. 4. Analyst: The data analyst works with the developers to determine what types of stats would give the team a handle on whether/how the feature is being used. For example, here is the dashboard that Dario Taraborelli: http://toolserver.org/~dartar/pc/ These roles aren't rigidly defined. For example, ideas for features can come from anywhere, not just the Product Manager. In my view, a well-functioning team is one where everyone is engaged in coming up with ideas. But there should be someone responsible for ensuring that the various ideas come together into a coherent whole, ones that addresses the problem at hand. That responsibility lies with the Product Manager. Also, Product Managers and Designers don't spec out stuff which they then hand over to developers to build. Teams work collaboratively to come up with solutions. That's how our project teams are structured. When it comes to the proposed organizational structure, Product consists of Product Managers, Designers, and Analysts (1, 2 and 4) and Engineering consists engineers across the different areas Terry describes. One way to view it is that Product involves everything outside of writing code for a feature and developers in Engineering write the code. It's oversimplification (e.g.,
[Wikimedia-l] Hiring Community Liaisons (Contract)
* Hey all, For the last 18 months, the Engineering Product Development department has been experimenting with the role of “Community Liaison, Product Development” - a staff member embedded in the Product team and tasked with factoring community concerns into our software development process, keeping editors informed about what we’re doing, and maintaining a dialogue between those who write code and those who write articles. While there is always room for improvement, I think this role has shown a lot of promise. We have a number of large projects coming down the pipeline (e.g., visual editor, discussion systems) and we need more help reaching out to our contributor communities, especially our non-English speaking projects, as our outreach there has traditionally been challenged. We’d like to recruit a small number of English-speaking or multilingual editors to do the Community Liaison job with different development teams and focuses. In particular we’re looking for people with a strong history of contributions to our projects who can provide sound and reasoned judgment and are trusted to do so by their community. Speaking other languages in addition to English is a major plus, as one of the objectives here is to ensure we can properly interact with and support non-English projects. I’ve included the full job description below. Our immediate need is for help with the Visual Editor. We’d like to hire a few community liaisons to help inform different Wikipedia language communities of the upcoming launch, create spaces for feedback and discussion, synthesize feedback for the Visual Editor team, and other activities required to support the Visual Editor launch later this year. If this is a role that would interest you, please e-mail Philippe Beaudette at pbeaude...@wikimedia.orghttps://mail.google.com/mail/?view=cmfs=1tf=1to=pbeaude...@wikimedia.org. And if you know someone else who might fit the role, let them know about it :-). We’re provisionally interested in hiring 2-3 liaisons, at an hourly rate commensurate with experience. This can be a part-time role, but we’ll need at least 15 hours/week for the length of the engagement (minimum 3 months). Please do apply if you think it’s a role that suits you, and if you find places we haven’t notified, spread the word! Thanks. Howie * _ Howie Fung Director of Product Development Wikimedia Foundation * Community Liaison Job Description Background Information and Statement of Purpose The Wikimedia Foundation’s Engineering Product Development Department is looking at ways to more effectively incorporate broad community perspectives in decisions and hold dialogues with our editors about the scope, pace and features of upcoming changes to Wikimedia projects. As part of this, it is hiring additional Community Liaisons from our volunteer community. Scope of Work Support and improve our ongoing software development projects, in particular: - Building up a network of volunteers from both English language and non-English language wikis, increasing the number of projects we can interact with; - Engaging the community in the software development process, by acting as a conduit for community questions, bugs and and feature requests, talking to editors about our work and how they can participate in it effectively, and recruiting them for workgroups and studies; - Being available from time to time to provide expertise and knowledge about our projects, including but not limited to training externally-sourced staff in the way our projects work, answering their questions, and providing expert advice on an ad-hoc basis; - Ensuring that our community is represented in the decision-making process and that our planned software adequately reflects user needs; - Monitoring Wikimedia projects, with the assistance of a network of volunteers, for emerging issues that have an impact on Engineering programmes; and - Other duties as needed. Requirements Effective Community Liaisons will be: - Experienced users of Wikimedia projects, capable of representing our community within the Foundation and vice-versa. - Strong communicators (both verbally and with the written word), able to explain our products to different groups of users with different levels of technical understanding. - Able to focus on the larger picture, understanding which concerns and views are widespread and which are marginal or individual. - Approachable, as both users and product developers must be able to trust these people for the relationship to function. - Self-motivated - they will be given important projects and expected to execute with little to no supervision. - Strongly empathetic - they excel at understanding the perspectives of others and bridging the gap between different approaches to the world. - Willing and able
[Wikimedia-l] [Wikimedia Announcements] Hiring Community Liaisons (Contract)
* Hey all, For the last 18 months, the Engineering Product Development department has been experimenting with the role of “Community Liaison, Product Development” - a staff member embedded in the Product team and tasked with factoring community concerns into our software development process, keeping editors informed about what we’re doing, and maintaining a dialogue between those who write code and those who write articles. While there is always room for improvement, I think this role has shown a lot of promise. We have a number of large projects coming down the pipeline (e.g., visual editor, discussion systems) and we need more help reaching out to our contributor communities, especially our non-English speaking projects, as our outreach there has traditionally been challenged. We’d like to recruit a small number of English-speaking or multilingual editors to do the Community Liaison job with different development teams and focuses. In particular we’re looking for people with a strong history of contributions to our projects who can provide sound and reasoned judgment and are trusted to do so by their community. Speaking other languages in addition to English is a major plus, as one of the objectives here is to ensure we can properly interact with and support non-English projects. I’ve included the full job description below. Our immediate need is for help with the Visual Editor. We’d like to hire a few community liaisons to help inform different Wikipedia language communities of the upcoming launch, create spaces for feedback and discussion, synthesize feedback for the Visual Editor team, and other activities required to support the Visual Editor launch later this year. If this is a role that would interest you, please e-mail Philippe Beaudette at pbeaude...@wikimedia.orghttps://mail.google.com/mail/?view=cmfs=1tf=1to=pbeaude...@wikimedia.org. And if you know someone else who might fit the role, let them know about it :-). We’re provisionally interested in hiring 2-3 liaisons, at an hourly rate commensurate with experience. This can be a part-time role, but we’ll need at least 15 hours/week for the length of the engagement (minimum 3 months). Please do apply if you think it’s a role that suits you, and if you find places we haven’t notified, spread the word! Thanks. Howie * _ Howie Fung Director of Product Development Wikimedia Foundation * Community Liaison Job Description Background Information and Statement of Purpose The Wikimedia Foundation’s Engineering Product Development Department is looking at ways to more effectively incorporate broad community perspectives in decisions and hold dialogues with our editors about the scope, pace and features of upcoming changes to Wikimedia projects. As part of this, it is hiring additional Community Liaisons from our volunteer community. Scope of Work Support and improve our ongoing software development projects, in particular: - Building up a network of volunteers from both English language and non-English language wikis, increasing the number of projects we can interact with; - Engaging the community in the software development process, by acting as a conduit for community questions, bugs and and feature requests, talking to editors about our work and how they can participate in it effectively, and recruiting them for workgroups and studies; - Being available from time to time to provide expertise and knowledge about our projects, including but not limited to training externally-sourced staff in the way our projects work, answering their questions, and providing expert advice on an ad-hoc basis; - Ensuring that our community is represented in the decision-making process and that our planned software adequately reflects user needs; - Monitoring Wikimedia projects, with the assistance of a network of volunteers, for emerging issues that have an impact on Engineering programmes; and - Other duties as needed. Requirements Effective Community Liaisons will be: - Experienced users of Wikimedia projects, capable of representing our community within the Foundation and vice-versa. - Strong communicators (both verbally and with the written word), able to explain our products to different groups of users with different levels of technical understanding. - Able to focus on the larger picture, understanding which concerns and views are widespread and which are marginal or individual. - Approachable, as both users and product developers must be able to trust these people for the relationship to function. - Self-motivated - they will be given important projects and expected to execute with little to no supervision. - Strongly empathetic - they excel at understanding the perspectives of others and bridging the gap between different approaches to the world. - Willing and able
