https://wiki.mozilla.org/api.php?action=feedcontributions&user=Pfinch&feedformat=atomMozillaWiki - User contributions [en]2024-03-28T20:20:18ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=Innovation/Projects/Open_Innovation_Strategy&diff=1184140Innovation/Projects/Open Innovation Strategy2017-11-14T09:34:05Z<p>Pfinch: shortened description on challenges</p>
<hr />
<div>== MoCo Open Innovation Strategy Project ==<br />
[[File:OpenInno StrategyProject Open.JPG|thumbnail]]<br />
<br />
“Openness” defines Mozilla more than any other characteristic, in both the products and technologies the organisation builds and in how it operates. <br />
<br />
<br />
In 2017, the '''Open Innovation team''' conducted a research project to help Mozilla (MoCo) revitalize participation and broader external engagement to be a source of competitive advantage for its products and technologies. The project analysed how effective Mozilla is in its open practices across both staff and contributor communities as well as how other industry actors use openness for competitive advantage. Based upon these findings, the project made recommendations for how MoCo can better invest in and execute on being “open.”<br />
<br />
Although the project was focused on developing products and technologies (typically the focus of Mozilla Corp, MoCo), it was conducted in collaboration with the Mozilla Foundation.<br />
<br />
==Methodology==<br />
In order to begin from an evidence-based, shared understanding of the problem, the project researched three perspectives:<br />
<br />
<br />
'''Internal Research''' <br />
<br />
We documented internal perspectives on open source and external collaboration at Mozilla by interviewing numerous employees, particularly those working most directly with contributors.<br />
<br />
<br />
'''Communities and Contributors Research'''<br />
<br />
This component analyzed Mozilla communities and contributors to understand who they are, how and what they engage with, their motivations, and how they’re connected to one another as well as to other open source and open Web projects. This was done through a survey of over 1000 community members and an analysis of 16 years of contribution data (Bugzilla, GitHub, and more), which was driven by [https://bitergia.com/ Bitergia]. <br />
<br />
<br />
'''External Research'''<br />
<br />
In partnership with the Copenhagen Institute of Design, ([http://ciid.dk CIID]), we conducted case studies of seven organizations for inspiration and lessons. Target organizations were Sage Bionetworks, 23andme, Arduino, Aleph Objects, Automattic, NASA, and Kubernetes. They were chosen because they varied in market sector and met selective criteria such as being mission-focused, reliant upon external participation in ways fundamental to strategy and product, and supported by vital, growing communities.<br />
<br />
<br />
'''Past Research'''<br />
<br />
The project was also informed by related research, such as the [http://tiptoes.ca/diversity-inclusion-for-participation-a-plan-for-strategy/ D&I study], [https://wiki.mozilla.org/Contribute/2014_Community_Survey historical community research], and current [[Innovation/Open_Source_Experiments|Open Source Experiments]].<br />
<br />
<br />
<br />
This was the first time Mozilla undertook such a comprehensive analysis of its community efforts, and we expect to revisit the communities and contributors research annually. <br />
<br />
Also, note that although the project was focused on MoCo, it was run in coordination with MoFo.<br />
<br />
==Results==<br />
<br />
'''Internal Research'''<br />
<br />
Interviews covered opportunities and challenges with external community engagement as well as day-to-day management of relationships and communities. Mozilla employees firmly believe in 'open' as a core Mozilla value and that ‘working open’ can provide benefit to the organisation; however, they described many challenges to working more effectively with participants and communities. A summary of these challenges is that Mozilla has generally not kept up with market developments and opportunities around open, collaborative methods, nor has it consistently and strategically invested in participation and collaboration.<br />
<br />
<br />
'''Communities and Contributors Research''' <br />
<br />
Mozilla’s position with community and participation is stronger than perhaps believed. While some areas of contribution have experienced recent difficulties – SUMO and Web Compatibility both report challenges with tools and processes – the data on actual code contribution is solid. The organization has a very visible industry profile, attracting thousands of global code authors every year (almost 2,400 new code authors in 2017 alone), which is notable relative to other mature FOSS projects. Non-employee contribution to Firefox and Gecko has grown and appears reasonably stable, and the communities around Emerging Technologies projects are growing. In addition, the data show that Mozilla is quicker than other open source projects to respond and act on pull requests.<br />
<br />
Mozilla has strived to make its operational processes transparent and to provide engagement opportunities beyond open source co-development. Although there's room for improvement, Mozilla community participation seems well distributed across coding and non-coding projects. The qualitative survey found participation focused around events, localization, marketing, and teaching, as well as coding, with most participation occurring later in the product lifecycle. This points to an opportunity to work more effectively with our communities earlier in the product lifecycle. Mozilla certainly needs to work on gender diversity in its communities, but the age and geographical distribution was better than expected. <br />
<br />
<br />
Other key community research findings include:<br />
<br />
* Mozilla often perceives its large group of volunteers as ‘the Mozilla community’ -- as an entity somehow definably singular. However, the research showed that there is not one singular Mozilla community, but many. Differences are related not only to project focus and personal interest but also to motivations, operational norms, social capital and density, feelings of affiliation, and more. Understanding the differences and the reasons behind them is foundational to improving engagement, retention, and collaboration opportunities of mutual benefit. <br />
<br />
* There are clear gaps in Mozilla’s collective knowledge about its community activities and health. The Open Innovation team is already addressing these areas for improvement.<br />
<br />
* There are likely interesting opportunities for Mozilla to build stronger alliances for the open web through the broader open source networks of Mozilla contributors. The research identified that the 1,000 Mozilla contributors who made at least 5 commits in Mozilla projects over the past 3 years also participated in more than 35,000 non-Mozilla GitHub repositories between 2010 and 2016 (as defined by pull requests).<br />
<br />
<br />
'''External Research'''<br />
<br />
The case studies presented a rich set of findings, despite different products, markets, and organizational size. They also presented common themes in their approach to participation and external engagement. <br />
<br />
The Open Innovation team has been posting summaries of the external research on our [https://medium.com/mozilla-open-innovation Open Innovation blog]. We encourage you to follow the blog for more details on this aspect of the project.<br />
<br />
==Recommendations==<br />
The research made clear that while Mozilla's baseline is open, if the desired effects of this openness are unclear, the organisation's actions are prone to be unfocused and weak in impact. In order to be open effectively, Mozilla needs to be more deliberate about what it's aiming to accomplish and to design for that effect: Mozilla needs to be '''open by design'''.<br />
<br />
'''Open by design''' builds on the open nature and participatory culture that is core to Mozilla. Amplifying the organisation's ‘openness’ (code, culture, workflows, communities), '''open by design''' means being more intentional in how Mozilla builds communities and external engagements in order to achieve a desired market impact and, ultimately, a collective vision for the open web. <br />
<br />
There are several long-term recommendations for how Mozilla can be '''open by design'''. These recommendations will help Mozilla improve its position in key areas of competition and create attractive communities that provide the most benefit possible to participants (see image). They will also help Mozilla find a new, shared sense of the value of community and participation. Note that the recommendations' implications differ across Mozilla. For example, the Firefox and Emerging Technologies organizations operate under different conditions, with different areas of opportunity for '''open by design'''. <br />
<br />
(image pending)<br />
<br />
==Implementation of Open by Design Recommendations==<br />
Mozilla began implementing these recommendations through several prototype projects in 2H 2017. The organisation is identifying additional projects as part of 2018 planning, and we'll work in other ways to better align our structure, processes, people, and incentives to support '''open by design'''. <br />
<br />
In addition to these project-focused, 'teaching by doing' collaborations, the Open Innovation team is acting on some of the foundational items required to support an '''open by design''' organisation:<br />
<br />
* Our Service Design team is working to improve the contributor experience in Mozilla’s open source and open innovation programs.<br />
* We have implemented Bitergia’s GrimoireLab to provide community analytics at Mozilla, and we're [https://medium.com/mozilla-open-innovation/mozilla-running-into-chaoss-to-help-measure-and-improve-open-source-community-health-b71cf127cdfb collaborating] with other open source projects to identify best practices in contribution metrics. In addition, we're creating a Community Support Software Product (CoSS) to lay the systems foundation to ensure Mozilla has broad access to the community data we need to make sound programmatic decisions.<br />
* We're creating a set of guidelines for tools used in community work -- in particular, how to use closed tools in an open process. We recognize the inherent conflict, and we also recognize that many may feel it's an impossible conflict to resolve. Nonetheless, until there are enough open source tools that meet the specific needs of Mozilla's various projects, it's a conflict we'll have to manage. Open Innovation is working to minimize one aspect of this problem with a unified access management system (project IAM), which will allow all Mozillians (employees and contributors) to access Mozilla services through a unified, authoritative, and integrated identity system.<br />
* In collaboration with Mozilla's Diversity & Inclusion team, we've created a process for handling community behavior complaints.<br />
* We're reaching out to new sources of experts and advocates through the [https://opensource.mozilla.community/ Open Source Student Network]. <br />
* The Open Innovation team is also considering how to better approach the subset of Mozilla communities that have similar skillsets, goals, and needs. Although there are indeed many communities at Mozilla, there are enough similarities across this particular 'generalist group' that a more integrated, common interface and approach is merited.<br />
<br />
==Team==<br />
The project’s '''Steering Committee''' provided oversight and included: <br />
<br />
* Katharina Borchert • Chief Innovation Officer<br />
* Patrick Finch • Director, Open Innovation<br />
* John Jensen • Director, Organization Strategy<br />
* David Herman • Director of Strategy, Emerging Technologies<br />
* Nick Nguyen • VP, Firefox <br />
* George Roter • Director, Open Innovation <br />
<br />
The project’s '''Core Team''' members drove the project and included:<br />
<br />
* Patrick Finch • Responsible<br />
* Susy Struble • Strategic advisor & Internal research<br />
* Pierros Papadeas • Open source expert <br />
* Rina Tambo Jensen • Lead researcher<br />
* Ruben Martin • Communities and contributors research<br />
* Alex Klepel • Internal communications<br />
* David B. Schwartz (Princeton) • Researcher <br />
<br />
The project's '''External Partners''' helped with some aspects of the research:<br />
* Copenhagen Institute of Interactive Design ([http://ciid.dk/ CIID])<br />
* [https://bitergia.com/ Bitergia]<br />
<br />
==Timeline and Status==<br />
The project launched in March 2017 and concluded in November 2017. <br />
<br />
[[File:OpenInno StrategyProject Timeline.JPG|thumbnail|right]]<br />
<br />
* '''March''': Finalized analytical framework<br />
* '''April - May''': Conducted internal interviews, community survey and research, & external research; communicated about project to Mozilla community members and employees<br />
* '''May''': Synthesized findings & more internal communication <br />
* '''June''': Presented project findings and recommendations to Mozilla executives<br />
* '''July''': Recommendations signed off by Mozilla executives; pilot projects began for 2H 2017<br />
* '''October''': Communicated survey results to the Mozilla community <br />
* '''November''': Internal alignment on open by design as part of 2018 planning<br />
* '''November - the future''': Implement '''open by design''' recommendations<br />
<br />
<br />
As of November 2017, the Open Innovation Strategy project is complete, and we will not continue updating this wiki entry. Our attention turns now to implementation. <br />
<br />
We expect to run the communities and contributors research on an annual basis. We will share select findings from this research on Discourse and likely on the [https://medium.com/mozilla-open-innovation Open Innovation blog] as well. <br />
<br />
If you want to learn more about the project or have thoughts, suggestions, relevant research, or would like to directly participate in future research, please email [mailto:openinnovation@mozilla.com the Open Innovation Team.]<br />
<br />
Our deepest gratitude goes to all the Mozilla community members who helped on this project and who continue to donate their time, insight, and efforts to supporting the open web!</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation/Projects/Open_Innovation_Strategy&diff=1184139Innovation/Projects/Open Innovation Strategy2017-11-14T09:24:21Z<p>Pfinch: clarification on terms MoCo and MoFo</p>
<hr />
<div>== MoCo Open Innovation Strategy Project ==<br />
[[File:OpenInno StrategyProject Open.JPG|thumbnail]]<br />
<br />
“Openness” defines Mozilla more than any other characteristic, in both the products and technologies the organisation builds and in how it operates. <br />
<br />
<br />
In 2017, the '''Open Innovation team''' conducted a research project to help Mozilla (MoCo) revitalize participation and broader external engagement to be a source of competitive advantage for its products and technologies. The project analysed how effective Mozilla is in its open practices across both staff and contributor communities as well as how other industry actors use openness for competitive advantage. Based upon these findings, the project made recommendations for how MoCo can better invest in and execute on being “open.”<br />
<br />
Although the project was focused on developing products and technologies (typically the focus of Mozilla Corp, MoCo), it was conducted in collaboration with the Mozilla Foundation.<br />
<br />
==Methodology==<br />
In order to begin from an evidence-based, shared understanding of the problem, the project researched three perspectives:<br />
<br />
<br />
'''Internal Research''' <br />
<br />
We documented internal perspectives on open source and external collaboration at Mozilla by interviewing numerous employees, particularly those working most directly with contributors.<br />
<br />
<br />
'''Communities and Contributors Research'''<br />
<br />
This component analyzed Mozilla communities and contributors to understand who they are, how and what they engage with, their motivations, and how they’re connected to one another as well as to other open source and open Web projects. This was done through a survey of over 1000 community members and an analysis of 16 years of contribution data (Bugzilla, GitHub, and more), which was driven by [https://bitergia.com/ Bitergia]. <br />
<br />
<br />
'''External Research'''<br />
<br />
In partnership with the Copenhagen Institute of Design, ([http://ciid.dk CIID]), we conducted case studies of seven organizations for inspiration and lessons. Target organizations were Sage Bionetworks, 23andme, Arduino, Aleph Objects, Automattic, NASA, and Kubernetes. They were chosen because they varied in market sector and met selective criteria such as being mission-focused, reliant upon external participation in ways fundamental to strategy and product, and supported by vital, growing communities.<br />
<br />
<br />
'''Past Research'''<br />
<br />
The project was also informed by related research, such as the [http://tiptoes.ca/diversity-inclusion-for-participation-a-plan-for-strategy/ D&I study], [https://wiki.mozilla.org/Contribute/2014_Community_Survey historical community research], and current [[Innovation/Open_Source_Experiments|Open Source Experiments]].<br />
<br />
<br />
<br />
This was the first time Mozilla undertook such a comprehensive analysis of its community efforts, and we expect to revisit the communities and contributors research annually. <br />
<br />
Also, note that although the project was focused on MoCo, it was run in coordination with MoFo.<br />
<br />
==Results==<br />
<br />
'''Internal Research'''<br />
<br />
Interviews covered opportunities and challenges with external community engagement as well as day-to-day management of relationships and communities. Mozilla employees firmly believe in 'open' as a core Mozilla value and that ‘working open’ can provide benefit to the organisation; however, they described many challenges to working more effectively with participants and communities. A summary of these challenges is that Mozilla has generally not kept up with market developments and opportunities around open, collaborative methods, nor has it consistently and strategically invested in participation and collaboration.<br />
<br />
<br />
'''Communities and Contributors Research''' <br />
<br />
Mozilla’s position with community and participation is stronger than perhaps believed. While there are problematic areas – such as an overall contribution decrease in SUMO and L10N, and areas like Web Compatibility where retention and engagement can be improved – the data on actual code contribution is solid. The organization has a very visible industry profile, attracting thousands of global code authors every year (almost 2,400 new code authors in 2017 alone), which is notable relative to other mature FOSS projects. Non-employee contribution to Firefox and Gecko has grown and appears reasonably stable, and the communities around Emerging Technologies projects are growing. In addition, the data show that Mozilla is quicker than other open source projects to respond and act on pull requests.<br />
<br />
Mozilla has strived to make its operational processes transparent and to provide engagement opportunities beyond open source co-development. Although there's room for improvement, Mozilla community participation seems well distributed across coding and non-coding projects. The qualitative survey found participation focused around events, localization, marketing, and teaching, as well as coding, with most participation occurring later in the product lifecycle. This points to an opportunity to work more effectively with our communities earlier in the product lifecycle. Mozilla certainly needs to work on gender diversity in its communities, but the age and geographical distribution was better than expected. <br />
<br />
<br />
Other key community research findings include:<br />
<br />
* Mozilla often perceives its large group of volunteers as ‘the Mozilla community’ -- as an entity somehow definably singular. However, the research showed that there is not one singular Mozilla community, but many. Differences are related not only to project focus and personal interest but also to motivations, operational norms, social capital and density, feelings of affiliation, and more. Understanding the differences and the reasons behind them is foundational to improving engagement, retention, and collaboration opportunities of mutual benefit. <br />
<br />
* There are clear gaps in Mozilla’s collective knowledge about its community activities and health. The Open Innovation team is already addressing these areas for improvement.<br />
<br />
* There are likely interesting opportunities for Mozilla to build stronger alliances for the open web through the broader open source networks of Mozilla contributors. The research identified that the 1,000 Mozilla contributors who made at least 5 commits in Mozilla projects over the past 3 years also participated in more than 35,000 non-Mozilla GitHub repositories between 2010 and 2016 (as defined by pull requests).<br />
<br />
<br />
'''External Research'''<br />
<br />
The case studies presented a rich set of findings, despite different products, markets, and organizational size. They also presented common themes in their approach to participation and external engagement. <br />
<br />
The Open Innovation team has been posting summaries of the external research on our [https://medium.com/mozilla-open-innovation Open Innovation blog]. We encourage you to follow the blog for more details on this aspect of the project.<br />
<br />
==Recommendations==<br />
The research made clear that while Mozilla's baseline is open, if the desired effects of this openness are unclear, the organisation's actions are prone to be unfocused and weak in impact. In order to be open effectively, Mozilla needs to be more deliberate about what it's aiming to accomplish and to design for that effect: Mozilla needs to be '''open by design'''.<br />
<br />
'''Open by design''' builds on the open nature and participatory culture that is core to Mozilla. Amplifying the organisation's ‘openness’ (code, culture, workflows, communities), '''open by design''' means being more intentional in how Mozilla builds communities and external engagements in order to achieve a desired market impact and, ultimately, a collective vision for the open web. <br />
<br />
There are several long-term recommendations for how Mozilla can be '''open by design'''. These recommendations will help Mozilla improve its position in key areas of competition and create attractive communities that provide the most benefit possible to participants (see image). They will also help Mozilla find a new, shared sense of the value of community and participation. Note that the recommendations' implications differ across Mozilla. For example, the Firefox and Emerging Technologies organizations operate under different conditions, with different areas of opportunity for '''open by design'''. <br />
<br />
(image from Jim to come - will be the graphic we use in the consolidated report that doesn't have the foundational aspect)<br />
<br />
==Implementation of Open by Design Recommendations==<br />
Mozilla began implementing these recommendations through several prototype projects in 2H 2017. The organisation is identifying additional projects as part of 2018 planning, and we'll work in other ways to better align our structure, processes, people, and incentives to support '''open by design'''. <br />
<br />
In addition to these project-focused, 'teaching by doing' collaborations, the Open Innovation team is acting on some of the foundational items required to support an '''open by design''' organisation:<br />
<br />
* Our Service Design team is working to improve the contributor experience in Mozilla’s open source and open innovation programs.<br />
* We have implemented Bitergia’s GrimoireLab to provide community analytics at Mozilla, and we're [https://medium.com/mozilla-open-innovation/mozilla-running-into-chaoss-to-help-measure-and-improve-open-source-community-health-b71cf127cdfb collaborating] with other open source projects to identify best practices in contribution metrics. In addition, we're creating a Community Support Software Product (CoSS) to lay the systems foundation to ensure Mozilla has broad access to the community data we need to make sound programmatic decisions.<br />
* We're creating a set of guidelines for tools used in community work -- in particular, how to use closed tools in an open process. We recognize the inherent conflict, and we also recognize that many may feel it's an impossible conflict to resolve. Nonetheless, until there are enough open source tools that meet the specific needs of Mozilla's various projects, it's a conflict we'll have to manage. Open Innovation is working to minimize one aspect of this problem with a unified access management system (project IAM), which will allow all Mozillians (employees and contributors) to access Mozilla services through a unified, authoritative, and integrated identity system.<br />
* In collaboration with Mozilla's Diversity & Inclusion team, we've created a process for handling community behavior complaints.<br />
* We're reaching out to new sources of experts and advocates through the [https://opensource.mozilla.community/ Open Source Student Network]. <br />
* The Open Innovation team is also considering how to better approach the subset of Mozilla communities that have similar skillsets, goals, and needs. Although there are indeed many communities at Mozilla, there are enough similarities across this particular 'generalist group' that a more integrated, common interface and approach is merited.<br />
<br />
==Team==<br />
The project’s '''Steering Committee''' provided oversight and included: <br />
<br />
* Katharina Borchert • Chief Innovation Officer<br />
* Patrick Finch • Director, Open Innovation<br />
* John Jensen • Director, Organization Strategy<br />
* David Herman • Director of Strategy, Emerging Technologies<br />
* Nick Nguyen • VP, Firefox <br />
* George Roter • Director, Open Innovation <br />
<br />
The project’s '''Core Team''' members drove the project and included:<br />
<br />
* Patrick Finch • Responsible<br />
* Susy Struble • Strategic advisor & Internal research<br />
* Pierros Papadeas • Open source expert <br />
* Rina Tambo Jensen • Lead researcher<br />
* Ruben Martin • Communities and contributors research<br />
* Alex Klepel • Internal communications<br />
* David B. Schwartz (Princeton) • Researcher <br />
<br />
The project's '''External Partners''' helped with some aspects of the research:<br />
* Copenhagen Institute of Interactive Design ([http://ciid.dk/ CIID])<br />
* [https://bitergia.com/ Bitergia]<br />
<br />
==Timeline and Status==<br />
The project launched in March 2017 and concluded in November 2017. <br />
<br />
[[File:OpenInno StrategyProject Timeline.JPG|thumbnail|right]]<br />
<br />
* '''March''': Finalized analytical framework<br />
* '''April - May''': Conducted internal interviews, community survey and research, & external research; communicated about project to Mozilla community members and employees<br />
* '''May''': Synthesized findings & more internal communication <br />
* '''June''': Presented project findings and recommendations to Mozilla executives<br />
* '''July''': Recommendations signed off by Mozilla executives; pilot projects began for 2H 2017<br />
* '''October''': Communicated survey results to the Mozilla community <br />
* '''November''': Internal alignment on open by design as part of 2018 planning<br />
* '''November - the future''': Implement '''open by design''' recommendations<br />
<br />
<br />
As of November 2017, the Open Innovation Strategy project is complete, and we will not continue updating this wiki entry. Our attention turns now to implementation. <br />
<br />
We expect to run the communities and contributors research on an annual basis. We will share select findings from this research on Discourse and likely on the [https://medium.com/mozilla-open-innovation Open Innovation blog] as well. <br />
<br />
If you want to learn more about the project or have thoughts, suggestions, relevant research, or would like to directly participate in future research, please email [mailto:openinnovation@mozilla.com the Open Innovation Team.]<br />
<br />
Our deepest gratitude goes to all the Mozilla community members who helped on this project and who continue to donate their time, insight, and efforts to supporting the open web!</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1170566Innovation2017-05-08T05:47:49Z<p>Pfinch: /* Projects */ fixed a broken link</p>
<hr />
<div>= The Open Innovation Team =<br />
<br />
The '''Open Innovation Team''' exists to help Mozilla’s product and technology teams move more intentionally towards open methods across all phases of the lifecycle to gain long-term competitive advantage. The team works across the organization designing the necessary infrastructure (relationships, processes, tools) and modern, efficient and scalable forms of participation, based on a clear sense of value exchange. Our role is to be a centre of competence for<br />
<br />
* Shaping strategy for delivering value through open methods<br />
* Being practitioners of open methods<br />
* Delivering excellence in engaging external stakeholders<br />
<br />
==Management Team==<br />
* Katharina Borchert - Chief Innovation Officer<br />
* Patrick Finch - Strategy<br />
* Rina Jensen - Research Design<br />
* George Roter - Community Infrastructure<br />
* Henrik Mitsch - Participation Systems<br />
* Lucy Harris - Community Development<br />
* Rosana Ardila - Open Innovation Experiments <br />
* Don Marti - Open Source Experiments<br />
<br />
==Projects==<br />
* [https://wiki.mozilla.org/Innovation/toolkit Open Innovation Toolkit]<br />
* [https://wiki.mozilla.org/Innovation/Open_Source_Experiments Open Source Experiments]<br />
* [https://equalrating.com Equal Rating Innovation Challenge]<br />
* [https://wiki.mozilla.org/Innovation/Projects/Open_Innovation_Strategy Open Innovation Strategy]<br />
<br />
==Blog==<br />
* [https://medium.com/mozilla-open-innovation Mozilla Open Innovation]<br />
<br />
<br />
''This wiki is a work in progress. Please contact '''[mailto:pfinch@mozilla.com Patrick Finch]''' with any questions.''</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation/Projects/Open_Innovation_Strategy&diff=1167486Innovation/Projects/Open Innovation Strategy2017-04-04T12:58:36Z<p>Pfinch: placeholder for editting</p>
<hr />
<div>placeholder</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Participation/Projects/Open_Innovation_Strategy&diff=1167485Participation/Projects/Open Innovation Strategy2017-04-04T12:58:16Z<p>Pfinch: added redirect</p>
<hr />
<div>#REDIRECT [[https://wiki.mozilla.org/Innovation/Projects/Open_Innovation_Strategy]]<br />
<br />
{{Participation}}<br />
<br />
== Project Name: == <br />
Open Innovation Strategy<br />
<br />
== Description: == <br />
Conducting research on the open innovation landscape, providing case studies and recommendations for Mozilla. <br />
Identifying internal opportunities for open innovation and engaging with teams to determine which ones to prototype open innovation efforts with.<br />
<br />
== Objective: == <br />
We will research the open innovation landscape and the internal opportunities to craft a strategy to add value to the organization through open innovation <br />
<br />
== Alignment With Mozilla Goals == <br />
This feeds directly into Prototyping the Future at the Mozilla-wide level. <br />
<br />
== Why ==<br />
Open innovation brings a lot of value for many organizations around the world, Mozilla has an even higher potential due to the mission. This potential has not been tapped into yet.<br />
<br />
== Success: == <br />
We will have a strategy for adding value to the organization through open innovation and will have identifies first prototypes to prove value. <br />
<br />
== Timeline == <br />
We aim to finish the research and have a first idea of what project to work on by mid october. The process will be refined throughout the planning process. <br />
<br />
== Team == <br />
<br />
* Klaus is leading the external research piece. <br />
* Rina, Patrick and Rosana are working on the internal opportunities and strategy. <br />
* Innovation team, Firefox team (test pilot).<br />
<br />
== Internal Stakeholders ==<br />
<br />
== Resources ==<br />
<br />
== Link to key resources/strategy ==<br />
<br />
== Meetings ==<br />
<br />
== Roadmap ==<br />
<br />
== Github Issue(s) ==<br />
<br />
List by heartbeat i.e.:<br />
* <br />
<br />
== Work To Date ==<br />
<br />
List any finished work, decisions, report-backs, metrics etc to show progress.<br />
<br />
== How to get involved ==<br />
i.e.<br />
* [Join our Gitter Channel/Discourse Topic and say hi]</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1167475Innovation2017-04-04T10:20:33Z<p>Pfinch: updated email alias</p>
<hr />
<div>= The Open Innovation Group =<br />
<br />
The '''Open Innovation Group''' serves everyone who wants to innovate across all areas of the Mozilla project by advancing our capabilities in open, distributed, collaborative innovation. We do this by adopting and adapting best practises at the management and operational levels, including by<br />
* Providing tools, frameworks and information resources to innovators<br />
* Providing support to innovation projects throughout their lifecycle<br />
* Connecting the Mozilla project to aligned influencers, projects and communities<br />
* Directly managing initiatives that do not have existing sponsorship<br />
<br />
== Contact Information ==<br />
<br />
'''[mailto:openinnovation@mozilla.com Team alias]'''<br />
<br />
<br />
=Teams=<br />
<br />
==Core Team==<br />
<br />
* [https://mozillians.org/u/Katharina/ Katharina Borchert - Chief Innovation Officer]<br />
* [https://mozillians.org/u/pfinch/ Patrick Finch - Strategy]<br />
* [https://mozillians.org/u/rina/ Rina Jensen - Research Design]<br />
<br />
=Projects=<br />
* [https://wiki.mozilla.org/Innovation/toolkit Open Innovation Toolkit]<br />
* [https://wiki.mozilla.org/Innovation/Open_Source_Experiments Open Source Experiments]<br />
* [https://wiki.mozilla.org/Innovation/Open_Innovation_Strategy Open Innovation Strategy]<br />
<br />
=Services=<br />
* [https://wiki.mozilla.org/Innovation/statista Statista]<br />
<br />
''this wiki is a work in progress. Please contact pfinch with any questions.'''</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1167474Innovation2017-04-04T10:19:07Z<p>Pfinch: /* Core Team */ updated list</p>
<hr />
<div>= The Open Innovation Group =<br />
<br />
The '''Open Innovation Group''' serves everyone who wants to innovate across all areas of the Mozilla project by advancing our capabilities in open, distributed, collaborative innovation. We do this by adopting and adapting best practises at the management and operational levels, including by<br />
* Providing tools, frameworks and information resources to innovators<br />
* Providing support to innovation projects throughout their lifecycle<br />
* Connecting the Mozilla project to aligned influencers, projects and communities<br />
* Directly managing initiatives that do not have existing sponsorship<br />
<br />
== Contact Information ==<br />
<br />
'''[mailto:i8n-team@mozilla.com Team alias]'''<br />
<br />
<br />
=Teams=<br />
<br />
==Core Team==<br />
<br />
* [https://mozillians.org/u/Katharina/ Katharina Borchert - Chief Innovation Officer]<br />
* [https://mozillians.org/u/pfinch/ Patrick Finch - Strategy]<br />
* [https://mozillians.org/u/rina/ Rina Jensen - Research Design]<br />
<br />
=Projects=<br />
* [https://wiki.mozilla.org/Innovation/toolkit Open Innovation Toolkit]<br />
* [https://wiki.mozilla.org/Innovation/Open_Source_Experiments Open Source Experiments]<br />
* [https://wiki.mozilla.org/Innovation/Open_Innovation_Strategy Open Innovation Strategy]<br />
<br />
=Services=<br />
* [https://wiki.mozilla.org/Innovation/statista Statista]<br />
<br />
''this wiki is a work in progress. Please contact pfinch with any questions.'''</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1167473Innovation2017-04-04T10:17:19Z<p>Pfinch: /* Projects */ added strategy project</p>
<hr />
<div>= The Open Innovation Group =<br />
<br />
The '''Open Innovation Group''' serves everyone who wants to innovate across all areas of the Mozilla project by advancing our capabilities in open, distributed, collaborative innovation. We do this by adopting and adapting best practises at the management and operational levels, including by<br />
* Providing tools, frameworks and information resources to innovators<br />
* Providing support to innovation projects throughout their lifecycle<br />
* Connecting the Mozilla project to aligned influencers, projects and communities<br />
* Directly managing initiatives that do not have existing sponsorship<br />
<br />
== Contact Information ==<br />
<br />
'''[mailto:i8n-team@mozilla.com Team alias]'''<br />
<br />
<br />
=Teams=<br />
<br />
==Core Team==<br />
<br />
* [https://mozillians.org/u/Katharina/ Katharina Borchert - Chief Innovation Officer]<br />
* [https://mozillians.org/u/davida/ David Ascher - VP Product, Mozilla Foundation]<br />
* [https://mozillians.org/u/Hermina/ Hermina Condei - Program Management]<br />
* [https://mozillians.org/u/pfinch/ Patrick Finch - Marketing & Strategy]<br />
* [https://mozillians.org/u/rina/ Rina Jensen - Research Design]<br />
* Valerie Casey - Special Consultant<br />
<br />
=Projects=<br />
* [https://wiki.mozilla.org/Innovation/toolkit Open Innovation Toolkit]<br />
* [https://wiki.mozilla.org/Innovation/Open_Source_Experiments Open Source Experiments]<br />
* [https://wiki.mozilla.org/Innovation/Open_Innovation_Strategy Open Innovation Strategy]<br />
<br />
=Services=<br />
* [https://wiki.mozilla.org/Innovation/statista Statista]<br />
<br />
''this wiki is a work in progress. Please contact pfinch with any questions.'''</div>Pfinchhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2017-03-20&diff=1166108WeeklyUpdates/2017-03-202017-03-20T05:03:21Z<p>Pfinch: /* Welcome! */ added Susy Struble</p>
<hr />
<div><br />
{{WeeklyUpdateNav}}<br />
* Every Monday @ 11:00am Pacific Time (19:00 UTC) <br />
* https://air.mozilla.org/channels/project-meeting/ to watch and listen<br />
* join irc.mozilla.org #airmozilla for backchannel discussion<br />
* Presenters only: Vidyo room "Brownbags". Do '''not''' use this room if you're not planning to speak. <br />
{{conf|8600}}<br />
** If you plan on presenting, please join the Vidyo BrownBags 20 minutes prior to the start of the meeting and announce to the A/V Technicians that you will be speaking so that they can confirm your Audio and Video.<br />
<br />
__TOC__<br />
<br />
= All-hands Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live all-hand status meeting.<br />
<br />
== Friends of Mozilla [[Image:Tree.gif|Friends of Mozilla]] ==<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
* '''[https://indiewebcamp.com/events/2017-03-22-homebrew-website-club Homebrew Website Club Meetup]''' (nearly every Wednesday somewhere)<br/><strong>Be a part of the open web with your own website.</strong><br />
** '''Berlin (GERMANY)''', <br/>'''London (ENGLAND)''', <br/>'''Baltimore (<abbr title="Maryland">MD</abbr>)''', <br/>'''Bellingham (<abbr title="Washington">WA</abbr>)''', <br/>'''San Francisco''' (this week @MatterVC in South Park)<br />
** 17:30-18:30 Quiet Writing Hour, finish that blog post, wiki edit, etc.!<br />
** 18:30-19:30 IndieWeb meetup, demos, & hack night <blockquote><p>Create or update your personal web site!<br/>Share what you've gotten working, ask the experts questions.</p><p>Join a community with like-minded interests. <br/>Bring friends that want a personal site!</p></blockquote> Any questions? See '''[https://indiewebcamp.com/events/2017-03-22-homebrew-website-club the wiki page for details]''' <br/>or join IRC: http://indieweb.org/irc/today<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===<br />
<br />
=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
== Speakers ==<br />
<br />
The limit is '''3 minutes per topic'''. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week. The meeting is streamed in a 4:3 format in order to allow for split screen. If your slides are 16:9 "widescreen" format, please indicate in the "Sharing" column below.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! [https://mozillians.org/u/USERNAME Presenter]<br />
! Title<br />
! Topic<br />
! Location<br />
! Sharing<br />
! Media<br />
! More Details<br />
|-<br />
| Who Are You?<br />
| What Do You Do?<br />
| What are you going to talk about?<br />
| Where are you presenting from? (Moz Space, your house, space)<br />
| Will you be sharing your screen? (yes/no, 4:3 or 16:9)<br />
| Links to slides or images you want displayed on screen<br />
| Link to where audience can find out more information<br />
|-<br />
| Tom Ritter<br />
| Security Engineering<br />
| Third Party Library Alerts<br />
| Remote<br />
| No<br />
| [https://github.com/mozilla-services/third-party-library-alert This webpage] (or not, it's not necessary)<br />
| https://github.com/mozilla-services/third-party-library-alert<br />
|-<br />
| Jenn Beard<br />
| Gigabit Fund Manager at the Mozilla Foundation<br />
| Mozilla Gigabit Community Fund is expanding to two new cities: Eugene, OR and Lafayette, LA<br />
| Remote (Kansas City)<br />
| --<br />
| --<br />
| https://blog.mozilla.org/blog/2017/03/14/public-private-partnership-gigabit-innovation-internet-health/<br />
|-<br />
| Hugo<br />
| Pocket Product Manager<br />
| Weekly Pocket Update<br />
| SF (Pocket Office)<br />
| No<br />
| --<br />
| --<br />
|-<br />
|}<br />
<br />
= Welcome! =<br />
<br />
Let's say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! ''Who is being introduced?''<br />
! ''Who are you? (the introducer)''<br />
! ''Where are you doing the introduction?''<br />
! ''Where are they from?''<br />
! ''How will they be part of Mozilla?''<br />
|-<br />
<!-- Insert new rows here --><br />
| Susy Struble<br />
| Patrick Finch<br />
| SF Commons<br />
| Bay Area<br />
| Open Innovation team<br />
|}<br />
<br />
= Fireside Chat =<br />
A chance to hear from leadership at Mozilla, and have a short Q&A about a specific topic.<br />
<br />
===This Week===<br />
<br />
'''Next steps for Mozilla’s Internet Health efforts: Issue Briefs'''<br />
<br />
===Presenters===<br />
<br />
'''Chris Riley''', Head of Public Policy<br />
<br />
'''Sam Burton''', Issues, Insights & Impact Lead, Mozilla Foundation <br />
<br />
===Topic===<br />
<br />
Earlier this year, we published our first Internet Health Report, an open source research project that highlights the current state of, and what lies ahead for, the Internet. In the report we broke down the concept of Internet health into five issues. Now, we are publishing in-depth issue briefs about each of them: online privacy and security, decentralization, open innovation, web literacy, and digital inclusion. We believe these issues are the building blocks to a healthy and vibrant Internet. Through these briefs, we talk a little bit more about what these issues mean to Mozilla, what problems we are trying to solve to improve Internet health, and what we are doing as an organization to make a difference.<br />
<br />
You can submit questions in advance on the [https://moderator.mozilla.org/e/fireside-chat-3-20-next-steps-for-mozilla-s-internet-health-efforts-issue-briefs-with-denelle-dixon-chief-legal-and-business-officer-and-chris-riley-head-of-public-policy-and-sam-burton-issues-insights-impact-lead-mozilla-foundation Moderator Page], or ask them live on Air Mozilla using a Mozilla Space mic or in #airmozilla on IRC.<br />
<br />
[[Category:Weekly Updates]]<br />
[[Category:Meeting Notes]]</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1124858Innovation2016-03-30T12:29:01Z<p>Pfinch: corrected format error</p>
<hr />
<div>= The Open Innovation Group =<br />
<br />
The '''Open Innovation Group''' serves everyone who wants to innovate across all areas of the Mozilla project by advancing our capabilities in open, distributed, collaborative innovation. We do this by adopting and adapting best practises at the management and operational levels, including by<br />
* Providing tools, frameworks and information resources to innovators<br />
* Providing support to innovation projects throughout their lifecycle<br />
* Connecting the Mozilla project to aligned influencers, projects and communities<br />
* Directly managing initiatives that do not have existing sponsorship<br />
<br />
== Contact Information ==<br />
<br />
'''[mailto:i8n-team@mozilla.com Team alias]'''<br />
<br />
<br />
=Teams=<br />
<br />
==Core Team==<br />
<br />
* [https://mozillians.org/u/Katharina/ Katharina Borchert - Chief Innovation Officer]<br />
* [https://mozillians.org/u/davida/ David Ascher - VP Product, Mozilla Foundation]<br />
* [https://mozillians.org/u/Hermina/ Hermina Condei - Program Management]<br />
* [https://mozillians.org/u/pfinch/ Patrick Finch - Marketing & Strategy]<br />
* [https://mozillians.org/u/rina/ Rina Jensen - Research Design]<br />
* Valerie Casey - Special Consultant<br />
<br />
<br />
''this wiki is a work in progress. Please contact pfinch with any questions.'''</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1124857Innovation2016-03-30T12:28:12Z<p>Pfinch: added name and mission statement</p>
<hr />
<div>= The Open Innovation Group =<br />
<br />
The '''Open Innovation Group''' serves everyone who wants to innovate across all areas of the Mozilla project by advancing our capabilities in open, distributed, collaborative innovation. We do this by adopting and adapting best practises at the management and operational levels, including by<br />
* Providing tools, frameworks and information resources to innovators<br />
* Providing support to innovation projects throughout their lifecycle<br />
* Connecting the Mozilla project to aligned influencers, projects and communities<br />
* Directly managing initiatives that do not have existing sponsorship<br />
<br />
== Contact Information ==<br />
<br />
'''[mailto:i8n-team@mozilla.com Team alias]'''<br />
<br />
===Teams===<br />
<br />
==Core Team==<br />
<br />
* [https://mozillians.org/u/Katharina/ Katharina Borchert - Chief Innovation Officer]<br />
* [https://mozillians.org/u/davida/ David Ascher - VP Product, Mozilla Foundation]<br />
* [https://mozillians.org/u/Hermina/ Hermina Condei - Program Management]<br />
* [https://mozillians.org/u/pfinch/ Patrick Finch - Marketing & Strategy]<br />
* [https://mozillians.org/u/rina/ Rina Jensen - Research Design]<br />
* Valerie Casey - Special Consultant<br />
<br />
<br />
''this wiki is a work in progress. Please contact pfinch with any questions.'''</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1124853Innovation2016-03-30T12:20:37Z<p>Pfinch: /* Contact Information */ updated</p>
<hr />
<div>UNDER CONSTRUCTION - please refer to pfinch before editting.<br />
This is the wiki for the Open Innovation team - it is under construction, but provides a point of contact.<br />
<br />
== Contact Information ==<br />
<br />
'''[mailto:i8n-team@mozilla.com Team alias]'''<br />
<br />
===Team===<br />
<br />
* [https://mozillians.org/u/Katharina/ Katharina Borchert - Chief Innovation Officer]<br />
* [https://mozillians.org/u/davida/ David Ascher - VP Product, Mozilla Foundation]<br />
* [https://mozillians.org/u/Hermina/ Hermina Condei - Program Management]<br />
* [https://mozillians.org/u/pfinch/ Patrick Finch - Marketing & Strategy]<br />
* [https://mozillians.org/u/rina/ Rina Jensen - Research Design]<br />
* Valerie Casey - Special Consultant</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1123407Innovation2016-03-22T12:55:33Z<p>Pfinch: /* Contact Information */ updated</p>
<hr />
<div>UNDER CONSTRUCTION - please refer to pfinch before editting.<br />
This is the wiki for the Open Innovation team - it is under construction, but provides a point of contact.<br />
<br />
== Contact Information ==<br />
<br />
'''[mailto:i8n-team@mozilla.com Team alias]'''<br />
<br />
===Team===<br />
<br />
* Katharina Borchert - Chief Innovation Officer<br />
* [https://mozillians.org/en-GB/u/davida/ David Ascher - VP Product, Mozilla Foundation]<br />
* Hermina Condei - Program Management<br />
* [https://mozillians.org/en-GB/u/pfinch/ Patrick Finch - Marketing & Strategy]<br />
* [https://mozillians.org/en-GB/u/rina/ Rina Jensen - Research Design]<br />
* Valerie Casey - Special Consultant</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1123367Innovation2016-03-22T06:00:46Z<p>Pfinch: minor details on name</p>
<hr />
<div>UNDER CONSTRUCTION - please refer to pfinch before editting.<br />
This is the wiki for the Open Innovation team - it is under construction, but provides a point of contact.<br />
<br />
== Contact Information ==<br />
<big>i8n-team@mozilla.com</big><br />
<br />
* Katharina Borchert - Chief Innovation Officer<br />
* [https://mozillians.org/en-GB/u/davida/ David Ascher - VP Product, Mozilla Foundation]<br />
* Hermina Condei - Program Management<br />
* [https://mozillians.org/en-GB/u/pfinch/ Patrick Finch - Marketing & Strategy]<br />
* [https://mozillians.org/en-GB/u/rina/ Rina Jensen - Research Design]<br />
* Valerie Casey - Special Consultant</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1122360Innovation2016-03-16T13:35:51Z<p>Pfinch: /* Contact Information */</p>
<hr />
<div>UNDER CONSTRUCTION - please refer to pfinch before editting.<br />
This is the wiki for the Innovation team - it is under construction, but provides a point of contact.<br />
<br />
== Contact Information ==<br />
<big>i8n-team@mozilla.com</big><br />
<br />
* Katharina Borchert - Chief Innovation Officer<br />
* [https://mozillians.org/en-GB/u/davida/ David Ascher - VP Product, Mozilla Foundation]<br />
* Hermina Condei - Program Management<br />
* [https://mozillians.org/en-GB/u/pfinch/ Patrick Finch - Marketing & Strategy]<br />
* [https://mozillians.org/en-GB/u/rina/ Rina Jensen - Research Design]<br />
* Valerie Casey - Special Consultant</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1122359Innovation2016-03-16T13:33:20Z<p>Pfinch: /* Contact Information */</p>
<hr />
<div>UNDER CONSTRUCTION - please refer to pfinch before editting.<br />
This is the wiki for the Innovation team - it is under construction, but provides a point of contact.<br />
<br />
== Contact Information ==<br />
<big>[emailto:i8n-team@mozilla.com Team Alias]</big><br />
<br />
* Katharina Borchert - Chief Innovation Officer<br />
* [https://mozillians.org/en-GB/u/davida/ David Ascher - VP Product, Mozilla Foundation]<br />
* Hermina Condei - Program Management<br />
* [https://mozillians.org/en-GB/u/pfinch/ Patrick Finch - Marketing & Strategy]<br />
* [https://mozillians.org/en-GB/u/rina/ Rina Jensen - Research Design]<br />
* Valerie Casey - Special Consultant</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1122357Innovation2016-03-16T13:31:10Z<p>Pfinch: editted for format</p>
<hr />
<div>UNDER CONSTRUCTION - please refer to pfinch before editting.<br />
This is the wiki for the Innovation team - it is under construction, but provides a point of contact.<br />
<br />
== Contact Information ==<br />
<big>[http://emailto:i8n-team@mozilla.com Team Alias]</big><br />
<br />
* Katharina Borchert - Chief Innovation Officer<br />
* [https://mozillians.org/en-GB/u/davida/ David Ascher - VP Product, Mozilla Foundation]<br />
* Hermina Condei - Program Management<br />
* [https://mozillians.org/en-GB/u/pfinch/ Patrick Finch - Marketing & Strategy]<br />
* [https://mozillians.org/en-GB/u/rina/ Rina Jensen - Research Design]<br />
* Valerie Casey - Special Consultant</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1122356Innovation2016-03-16T13:29:44Z<p>Pfinch: Editted to provide clearer contact info for Mozillians</p>
<hr />
<div>UNDER CONSTRUCTION - please refer to pfinch before editting.<br />
This is the wiki for the Innovation team - it is under construction, but provides a point of contact.<br />
<br />
== Contact Information ==<br />
[http://emailto:i8n-team@mozilla.com Team Alias]<br />
<br />
Katharina Borchert - Chief Innovation Officer<br />
[https://mozillians.org/en-GB/u/davida/ David Ascher - VP Product, Mozilla Foundation]<br />
Hermina Condei - Program Management<br />
[https://mozillians.org/en-GB/u/pfinch/ Patrick Finch - Marketing & Strategy]<br />
[https://mozillians.org/en-GB/u/rina/ Rina Jensen - Research Design]<br />
Valerie Casey - Special Consultant</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1121924Innovation2016-03-14T21:09:11Z<p>Pfinch: /* Innovation Team Mission */</p>
<hr />
<div>UNDER CONSTRUCTION - please refer to pfinch before editting.<br />
<br />
<br />
== Innovation Team Mission ==<br />
<br />
== Contact Information ==<br />
[http://emailto:i8n-team@mozilla.com Team Alias]<br />
<br />
<br />
== Resources ==<br />
<br />
<br />
== Current Projects ==</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Innovation&diff=1121835Innovation2016-03-14T13:31:27Z<p>Pfinch: First version - under construction</p>
<hr />
<div>UNDER CONSTRUCTION - please refer to pfinch before editting.<br />
<br />
<br />
== Innovation Team Mission ==<br />
<br />
The Innovation Team serves to help the entire project improve its innovation performance. We do this through <br />
* facilitating dialog, <br />
* providing tools, frameworks and resources<br />
* connecting the project to influencers<br />
* incubating efforts of high relevance to the Mozilla project<br />
<br />
<br />
== Contact Information ==<br />
[http://emailto:i8n-team@mozilla.com Team Alias]<br />
<br />
<br />
== Resources ==<br />
<br />
<br />
== Current Projects ==</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Websites/Content_Services_Site&diff=1078810Websites/Content Services Site2015-06-08T12:27:42Z<p>Pfinch: project concluded: site live</p>
<hr />
<div>site is live https://content.mozilla.org<br />
<br />
= End of Life Plan =<br />
<br />
TBD</div>Pfinchhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2015-04-27&diff=1070563WeeklyUpdates/2015-04-272015-04-27T17:26:14Z<p>Pfinch: /* Content Services */ update with individual threads for dev.planning</p>
<hr />
<div><br />
{{WeeklyUpdateNav}}<br />
Every Monday @ 11:00am Pacific Time (19:00 UTC)<br />
{{conf|8600}}<br />
<br />
<br />
__TOC__<br />
<br />
= All-hands Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live all-hand status meeting.<br />
<br />
== Friends of Mozilla [[Image:Tree.gif|Friends of Mozilla]] ==<br />
<br />
[https://mozillians.org/u/AprilMorone/ April Morone] for adding her app to the marketplace store<br />
<br />
[https://mozillians.org/u/Mte90/ Daniele Scasciafratte] for stepping up and helping on the Contributor Social Media team - hes stepped up as the newest admin for the Mozilla Contributors group<br />
<br />
Western Oregon University students for diving in to the project and working on bugs across the project during the last term.<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
* Check out a [http://dragonair.student.iastate.edu/mozilla/sourcecodeknowledge/project/gecko-dev/ website/tool developed for academic dissertation work to help Mozilla developers better understand the codebase and communication structure]. Help out by participating in a short 15 minute interview on IRC. Contact Patrick to setup an interview time (IRC: '''carlsonp''', email: '''carlsonp@iastate.edu'''). Cheers!<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
*[https://quality.mozilla.org/event/bug-triage-day-57/ Weekly Bug Triage Day]<br />
*[http://empirejs.org/ EmpireJSCONF 2015] Held in NYC April 26/27th<br />
**Two day conference for the Javascript community. <br />
**Soledad Penadés speaking on: Web components and experimental mobile UI audio+p2p wifi+whatnot (next level js)<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
*[https://quality.mozilla.org/event/bug-verification-day-62/ Weekly Bug Verification Day]<br />
<br />
*[https://air.mozilla.org/sumo-mobile-april-2015/ SuMo Mobile and b2g meeting] 9am pt in #sumo or the SuMo vidyo room<br />
<br />
*[http://srccon.org/ Tickets for Knight-Mozilla OpenNews' journalism-tech conference SRCCON go on sale at 2pm Eastern!]<br />
<br />
* Experience the rollercoaster of software development by watching a real engineer hack on Firefox! [https://air.mozilla.org/the-joy-of-coding-mconley-livehacks-on-firefox-episode-12/ The Joy of Coding: Episode 12 streams LIVE] at 10 AM PT / 1 PM ET / 5 PM GMT on Air Mozilla. Perfect for your morning, afternoon, or late afternoon tea. [http://mikeconley.ca/blog/category/technology/livecoding/ Previous episodes with summaries available here], and [https://www.youtube.com/playlist?list=PLmaFLMwlbk8wKMvfEEzp9Hfdlid8VYpL5 mirrored to YouTube here].<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===<br />
<br />
=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
<br />
- There will be a contributors meeting on Tuesday moderator live for it please ask questions <br />
https://moderator.mozilla.org/e/may-contributor-meeting<br />
<br />
- Interns start arriving in the San Francisco and Toronto offices!<br />
<br />
== Project Status Updates (voice updates) ==<br />
<br />
=== Firefox and Cloud Services ===<br />
''Speaker Location: Dave Camp/Mountain View''<br />
<br />
* Take a look at the Aha for Pocket integration: https://mozilla.aha.io/published/809d6d2e5fd193e0a8e833560fdb4fe0?page=1<br />
[[File:Msucan-portrait.jpg|thumbnail|Mihai]]<br />
<br />
* Mihai Șucan<br />
** Mihai's blog post: http://mihai.sucan.ro/mihai/blog/touched<br />
** [http://www.sohanaresearchfund.org/ The Sohana Research Fund]<br />
** [http://www.debra.org.uk/ Debra UK] and [http://www.debra-international.org/ international].<br />
** [http://ebresearch.org/ The EB research partnership].<br />
<br />
=== Firefox OS ===<br />
''Speaker Location:''<br />
<br />
=== CTO Update ===<br />
''Speaker Location:''<br />
<br />
=== Content Services ===<br />
''Speaker Location: Kevin Ghim | NYC''<br />
* Suggested Tiles<br />
** Content Services will be landing Suggested Tiles in Fx39<br />
* Links and Stuff<br />
** Ed Lee's technical blog post: http://ed.agadak.net/2015/04/whys-and-hows-of-suggested-tiles<br />
** dev.planning threads: <br />
*** [https://groups.google.com/forum/#!topic/mozilla.dev.planning/0J2j64Uq9AI Improving trust and transparency for Suggested Tiles] <br />
*** [https://groups.google.com/forum/#!topic/mozilla.dev.planning/MAl04q0tXzE Ideas for policies to protect Suggested Tiles users' data]<br />
*** [https://groups.google.com/forum/#!topic/mozilla.dev.planning/N8w5dphjBf8 Suggesting tiles by region with finer granularity than country]<br />
*** [https://groups.google.com/forum/#!topic/mozilla.dev.planning/S5m7Rjuz-Xc Potential privacy issues of not showing suggestions in certain contexts]<br />
** Bugs filed for to Improve technical guarantees for Suggested Tiles launch: https://bugzilla.mozilla.org/show_bug.cgi?id=1158230<br />
** More blogs, wikis, product page updates and brownbags to come before Suggested Tiles launch<br />
<br />
=== Webmaker ===<br />
''Andrew Sliwinski (Portland)''<br />
<br />
http://mzl.la/changelog<br />
<br />
*Webmaker for Android<br />
**Team pushing towards alpha release<br />
**Developing content and localization for our launch markets<br />
***US<br />
***UK<br />
***Canada<br />
***Brazil<br />
***Indonesia<br />
***Bangladesh<br />
***Kenya<br />
**https://github.com/mozilla/webmaker-app/tree/v1<br />
*Chicago Field Research<br />
**User testing<br />
**Ethnographic study<br />
<br />
=== Mozilla Communities ===<br />
''Speaker Location:''<br />
<br />
== Speakers ==<br />
<br />
The limit is 3 minutes per speaker. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! [https://mozillians.org/u/USERNAME Presenter]<br />
! Title<br />
! Topic<br />
! Location<br />
! Share?<br />
! Media<br />
! More Details<br />
|-<br />
| Who Are You?<br />
| What Do You Do?<br />
| What are you going to talk about?<br />
| Where are you presenting from? (Moz Space, your house, space)<br />
| Will you be sharing your screen? (yes/no, other info)<br />
| Links to slides or images you want displayed on screen<br />
| Link to where audience can find out more information<br />
|-<br />
| Dan Sinker<br />
| OpenNews<br />
| OpenNews Updates: SRCCON & the Coral Project<br />
| Chicago, IL<br />
| no<br />
| no slides<br />
| [http://coralproject.net Coral Project] and [http://opennews.org/ OpenNews]<br />
|-<br />
| [https://mozillians.org/en-US/u/andym/ Andy McKay]<br />
| Canada Bill C-51<br />
| Bill C-51<br />
| Vancouver<br />
| no<br />
| no<br />
| Visit [https://stopc51.ca/ Stop C-51] to contact your MP and see [https://blog.mozilla.org/netpolicy/2015/03/25/information-sharing-debates-continuing-in-problematic-directions/ Mozilla position]<br />
|}<br />
<br />
= Roundtable =<br />
<br />
Do you have a question about a Mozilla Project or initiative? Let us know by Friday- we'll do our best to get you an answer.<br />
<br />
Please note that we may not always be able to get to every item on this list, but we will try!<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! Who are you?<br />
! Area of question<br />
! Question<br />
|-<br />
| ''What's your name? What do you work on?''<br />
| ''Is your question about policy, a product, a Foundation initiative, etc.''<br />
| ''What would you like to know?''<br />
<!-- Insert new rows here --><br />
|-<br />
| ''David Weir (contributor)''<br />
| ''B2G devices.''<br />
| ''As being a long time contributor for Mozilla is their any flame devices going I can test and let users in the UK know how great b2g is?''<br />
<!-- Insert new rows here --><br />
|-<br />
|}<br />
<br />
= Welcome! =<br />
<br />
Let's say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.<br />
<br />
== Introducing New Volunteers ==<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! New Volunteer<br />
! Introduced by<br />
! Speaker location<br />
! New Volunteer location<br />
! Will be working on<br />
|-<br />
| ''Who is the new volunteer?''<br />
| ''Who will be introducing that person?''<br />
| ''Where is the introducer?''<br />
| ''Where will the new person be contributing from?''<br />
| ''What will the new person be working on?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
|}<br />
<br />
== Introducing New Hires ==<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! New Hire<br />
! Introduced by<br />
! Speaker location<br />
! New Hire location<br />
! Will be working on<br />
|-<br />
| ''Who is the new hire?''<br />
| ''Who will be introducing that person?''<br />
| ''Where is the introducer?''<br />
| ''Where will the new person be working from?''<br />
| ''What will the new person be working on?''<br />
|-<br />
| Ben Niolet<br />
| Michaela Smiley<br />
| Alexandria, VA<br />
| Durham, NC<br />
| Email Marketing<br />
|-<br />
| Liz Hull<br />
| Michaela Smiley<br />
| Alexandria, VA<br />
| Norfolk, VA<br />
| Social Media Marketing<br />
|-<br />
| Andrew Losowsky<br />
| Dan Sinker<br />
| Chicago, IL<br />
| New York City<br />
| Coral Project, project lead<br />
|-<br />
| Andre Natal<br />
| Dylan Oliver<br />
| Mountain View<br />
| Brazil Remote<br />
| Firefox OS Developer<br />
|-<br />
|}<br />
<br />
== Introducing New Interns ==<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! New Intern<br />
! Introduced by<br />
! Speaker location<br />
! New Hire location<br />
! Will be working on<br />
|-<br />
| ''Who is the new intern?''<br />
| ''Who will be introducing that person?''<br />
| ''Where is the introducer?''<br />
| ''Where will the new person be working from?''<br />
| ''What will the new person be working on?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
|}<br />
<br />
= &lt;meta&gt; =<br />
<br />
Notes and non-voice status updates that aren't part of the live meeting go here.<br />
<br />
== Status Updates By Team (*non-voice* updates) ==<br />
<br />
=== Firefox ===<br />
<br />
=== Platform ===<br />
<br />
=== Cloud Services ===<br />
<br />
=== Messaging ===<br />
<br />
=== Mobile ===<br />
<br />
=== IT ===<br />
<br />
=== Release Engineering ===<br />
<br />
=== QA ===<br />
<br />
==== Test Execution ====<br />
<br />
==== Web QA ====<br />
<br />
==== QA Community ====<br />
<br />
=== Automation & Tools ===<br />
<br />
==== bugzilla.mozilla.org ====<br />
Notable changes to [https://bugzilla.mozilla.org/ bugzilla.mozilla.org] during the last week:<br />
* {{bug|579089}} The default Hardware and Operating-System fields now default to "Unspecified/Unspecified" instead of the reporter's platform<br />
** This can be overwritten per-product, [https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org&component=Administration file a bug] if you own a product and want this changed<br />
* {{bug|1151830}} GitHub Auth is now enabled, allowing non-powerful accounts to sign in using their github credentials.<br />
[[BMO/Recent_Changes|All changes]].<br />
<br />
=== Security ===<br />
<br />
=== Engagement ===<br />
<br />
* [https://docs.google.com/a/mozilla.com/spreadsheets/d/1X5kUBkEAicEe2unDaaLGTYzAJbphWFoaJYBTasHrcHQ/edit#gid=1764494528 Engagement's Active Project Dashboard]<br />
<br />
==== PR ====<br />
<br />
==== Events ====<br />
<br />
==== Social Support ====<br />
<br />
[[Category:Weekly Updates]]<br />
[[Category:Meeting Notes]]</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Websites/Content_Services_Site&diff=1058928Websites/Content Services Site2015-03-02T10:26:51Z<p>Pfinch: Update to template for formatting</p>
<hr />
<div>[[Category:Webdev/Processes|Website Template]]<br />
[[Category:Webdev/Templates]]<br />
<br />
This page contains all of the important details for content.mozilla.org.<br />
<br />
= Project Description =<br />
<br />
This project will create a partner-facing Website for Mozilla's Content Services group. It will:<br />
* Cast the value proposition for Tiles products to potential partners<br />
* Generate and automatically collect leads<br />
* Showcase Mozilla Content Services products to industry and community observers<br />
<br />
<br />
= Project Purpose & Details =<br />
<br />
<br />
Content Services is a partner-facing, revenue generating business unit. Our product is seen by 100s of millions of Firefox users, we have existing channels to communicate with these users. We do not have a distinct venue for communicating with potential partners, explaining the benefits of Tiles and being contactable.<br />
<br />
<br />
==Project Brief==<br />
<br />
'''Key Objectives'''<br />
Generate, qualify and automate sales leads.<br />
<br />
'''Target Audience'''<br />
Primary audience is our target advertising brand, and these are marketing decision makers at<br />
* Web services<br />
* Web publishers<br />
* eCommerce vendors<br />
<br />
Secondary audience is the ad agency that works on behalf of our target brand<br />
Tertiary audience is the Mozilla community<br />
<br />
'''Market Insights'''<br />
The problem that we are solving for is understanding of the Tiles value proposition and a “what to do” if you are interested in Tiles. That means:<br />
* Why would I want to buy a Tile?<br />
* What is the process and requirements for buying a Tile?<br />
* What is the next step?<br />
<br />
Anyone arriving at the site has awareness of the product. What they lack is a reason to purchase.<br />
<br />
The problems our product solves are:<br />
* Need to reach a large scale audience quickly<br />
* Need to reach a new targeted audience<br />
* Need to re-engage current users<br />
<br />
''NOTE: Market research on these customer problems is ongoing. ''<br />
<br />
<br />
'''Audience think/do/feel'''<br />
Before the customer has visited this site they have awareness of the product - at least of the URL content.mozilla.org. After visiting this site, the customer will know if this product is aimed at them, the effort involved to buy a Tile, and how to proceed.<br />
<br />
'''Tone'''<br />
<br />
The Tone should be in line with Mozilla corporate partner communications:<br />
* https://www.mozilla.org/en-US/firefox/partners/<br />
* https://www.mozilla.org/en-US/about/partnerships/<br />
* https://mobilepartners.mozilla.org/ <br />
* This site will not have a different / distinct voice.<br />
<br />
'''Content Strategy & Requirements'''<br />
<br />
* The site is relatively straightforwards: it does not impact other pages<br />
* It will need to host relatively static content.<br />
* The site should not use Flash, and will conform to all Mozilla privacy requirements.<br />
* The site will require some copy-editing, and should be localised after launch into German and French.<br />
* The site will require at least two video assets. <br />
* The site will require a contact form which should be integrated with or instance of Salesforce.<br />
<br />
'''Other Considerations'''<br />
<br />
This is the start of Content Services go-to-market and we will be both adding social proof and new product in the coming year. The site must, therefore, be relatively easy to update, specially the value proposition and customer success story spaces.<br />
<br />
<br />
==User Stories==<br />
''Pending''<br />
<br />
= Project Information =<br />
<br />
==Communications Channel(s)==<br />
IRC, Basecamp, or other communications method<br />
''TBD in negotiation with project team''<br />
<br />
==Team members (RASCI)==<br />
''TBD in negotiation with project team.''<br />
R: TBD<br />
A: Patrick Finch is deemed approver.<br />
S: Content Services product management and BD (Kevin Ghim, Sean Bohan, Justin Terry)<br />
C: Business and legal affairs content owner (Geoff Piper)<br />
I: Content Services, Mozilla non-Content Services BD<br />
<br />
==Notes & Meetings Hub==<br />
<br />
==How to contribute== <br />
To help test and localise, please contact Patrick Finch<br />
<br />
== Website Information ==<br />
<br />
* Code name: Content.Mozilla.Org<br />
* Prod URL: http://content.mozilla.org<br />
* Dev URL: http://example-dev.allizom.org/<br />
* Stage URL: http://example-stage.allizom.org/<br />
* Code Repo: https://github.com/mozilla/example<br />
* L10N Repo: https://svn.mozilla.org/projects/l10n-misc/trunk/example/locale/<br />
* Code: Language / Framework<br />
<br />
= Team =<br />
<br />
The primary and secondary contacts for each role of this project:<br />
<br />
* Product owner - {Name}<br />
* TPM - {Name}<br />
* Web Project Manager - {Name}<br />
* Developers - {Name}<br />
* L10N - {Name}<br />
* Designer - {Name}<br />
* IT - {Name}<br />
* QA - {Name}<br />
* UX - {Name}<br />
* Security - {Name}<br />
* Legal - {Name}<br />
<br />
<br />
= Project Management =<br />
* {{Bug|123456}} Project Tracking Bug<br />
* Project Timeline<br />
<br />
== Key Deliverable Bugs ==<br />
<br />
* {{Bug|123456}} Project Tracking Bug<br />
<br />
= End of Life Plan =</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Websites/Website_Project_Name&diff=1058927Websites/Website Project Name2015-03-02T10:23:21Z<p>Pfinch: erroneously created</p>
<hr />
<div></div>Pfinchhttps://wiki.mozilla.org/index.php?title=Websites/Content_Services_Site&diff=1058926Websites/Content Services Site2015-03-02T10:22:42Z<p>Pfinch: Content Services Site first iteration</p>
<hr />
<div>[[Category:Webdev/Processes|Website Template]]<br />
[[Category:Webdev/Templates]]<br />
<br />
This page contains all of the important details for content.mozilla.org.<br />
<br />
= Project Description =<br />
<br />
This project will create a partner-facing Website for Mozilla's Content Services group. It will:<br />
* Cast the value proposition for Tiles products to potential partners<br />
* Generate and automatically collect leads<br />
* Showcase Mozilla Content Services products to industry and community observers<br />
<br />
<br />
= Project Purpose & Details =<br />
<br />
<br />
Content Services is a partner-facing, revenue generating business unit. Our product is seen by 100s of millions of Firefox users, we have existing channels to communicate with these users. We do not have a distinct venue for communicating with potential partners, explaining the benefits of Tiles and being contactable.<br />
<br />
<br />
* Project Brief<br />
<br />
'''Key Objectives'''<br />
Generate, qualify and automate sales leads.<br />
<br />
'''Target Audience'''<br />
Primary audience is our target advertising brand, and these are marketing decision makers at<br />
* Web services<br />
* Web publishers<br />
* eCommerce vendors<br />
<br />
Secondary audience is the ad agency that works on behalf of our target brand<br />
Tertiary audience is the Mozilla community<br />
<br />
'''Market Insights'''<br />
The problem that we are solving for is understanding of the Tiles value proposition and a “what to do” if you are interested in Tiles. That means:<br />
* Why would I want to buy a Tile?<br />
* What is the process and requirements for buying a Tile?<br />
* What is the next step?<br />
<br />
Anyone arriving at the site has awareness of the product. What they lack is a reason to purchase.<br />
<br />
The problems our product solves are:<br />
* Need to reach a large scale audience quickly<br />
* Need to reach a new targeted audience<br />
* Need to re-engage current users<br />
<br />
''NOTE: Market research on these customer problems is ongoing. ''<br />
<br />
<br />
'''Audience think/do/feel'''<br />
Before the customer has visited this site they have awareness of the product - at least of the URL content.mozilla.org. After visiting this site, the customer will know if this product is aimed at them, the effort involved to buy a Tile, and how to proceed.<br />
<br />
'''Tone'''<br />
<br />
The Tone should be in line with Mozilla corporate partner communications:<br />
* https://www.mozilla.org/en-US/firefox/partners/<br />
* https://www.mozilla.org/en-US/about/partnerships/<br />
* https://mobilepartners.mozilla.org/ <br />
* This site will not have a different / distinct voice.<br />
<br />
'''Content Strategy & Requirements'''<br />
<br />
* The site is relatively straightforwards: it does not impact other pages<br />
* It will need to host relatively static content.<br />
* The site should not use Flash, and will conform to all Mozilla privacy requirements.<br />
* The site will require some copy-editing, and should be localised after launch into German and French.<br />
* The site will require at least two video assets. <br />
* The site will require a contact form which should be integrated with or instance of Salesforce.<br />
<br />
'''Other Considerations'''<br />
<br />
This is the start of Content Services go-to-market and we will be both adding social proof and new product in the coming year. The site must, therefore, be relatively easy to update, specially the value proposition and customer success story spaces.<br />
<br />
<br />
* User Stories<br />
''Pending''<br />
<br />
= Project Information =<br />
<br />
* Communications Channel(s): IRC, Basecamp, or other communications method<br />
''TBD in negotiation with project team''<br />
<br />
* Team members (RASCI): <br />
''TBD in negotiation with project team.''<br />
R: TBD<br />
A: Patrick Finch is deemed approver.<br />
S: Content Services product management and BD (Kevin Ghim, Sean Bohan, Justin Terry)<br />
C: Business and legal affairs content owner (Geoff Piper)<br />
I: Content Services, Mozilla non-Content Services BD<br />
<br />
* Notes & Meetings Hub<br />
<br />
* How to contribute <br />
To help test and localise, please contact Patrick Finch<br />
<br />
== Website Information ==<br />
<br />
* Code name: Content.Mozilla.Org<br />
* Prod URL: http://content.mozilla.org<br />
* Dev URL: http://example-dev.allizom.org/<br />
* Stage URL: http://example-stage.allizom.org/<br />
* Code Repo: https://github.com/mozilla/example<br />
* L10N Repo: https://svn.mozilla.org/projects/l10n-misc/trunk/example/locale/<br />
* Code: Language / Framework<br />
<br />
= Team =<br />
<br />
The primary and secondary contacts for each role of this project:<br />
<br />
* Product owner - {Name}<br />
* TPM - {Name}<br />
* Web Project Manager - {Name}<br />
* Developers - {Name}<br />
* L10N - {Name}<br />
* Designer - {Name}<br />
* IT - {Name}<br />
* QA - {Name}<br />
* UX - {Name}<br />
* Security - {Name}<br />
* Legal - {Name}<br />
<br />
<br />
= Project Management =<br />
* {{Bug|123456}} Project Tracking Bug<br />
* Project Timeline<br />
<br />
== Key Deliverable Bugs ==<br />
<br />
* {{Bug|123456}} Project Tracking Bug<br />
<br />
= End of Life Plan =</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Websites/Website_Project_Name&diff=1058925Websites/Website Project Name2015-03-02T10:20:46Z<p>Pfinch: Content Services Site wiki project hub</p>
<hr />
<div>[[Category:Webdev/Processes|Website Template]]<br />
[[Category:Webdev/Templates]]<br />
<br />
This page contains all of the important details for content.mozilla.org.<br />
<br />
= Project Description =<br />
<br />
This project will create a partner-facing Website for Mozilla's Content Services group. It will:<br />
* Cast the value proposition for Tiles products to potential partners<br />
* Generate and automatically collect leads<br />
* Showcase Mozilla Content Services products to industry and community observers<br />
<br />
<br />
= Project Purpose & Details =<br />
<br />
<br />
Content Services is a partner-facing, revenue generating business unit. Our product is seen by 100s of millions of Firefox users, we have existing channels to communicate with these users. We do not have a distinct venue for communicating with potential partners, explaining the benefits of Tiles and being contactable.<br />
<br />
<br />
* Project Brief<br />
<br />
'''Key Objectives'''<br />
Generate, qualify and automate sales leads.<br />
<br />
'''Target Audience'''<br />
Primary audience is our target advertising brand, and these are marketing decision makers at<br />
* Web services<br />
* Web publishers<br />
* eCommerce vendors<br />
<br />
Secondary audience is the ad agency that works on behalf of our target brand<br />
Tertiary audience is the Mozilla community<br />
<br />
'''Market Insights'''<br />
The problem that we are solving for is understanding of the Tiles value proposition and a “what to do” if you are interested in Tiles. That means:<br />
* Why would I want to buy a Tile?<br />
* What is the process and requirements for buying a Tile?<br />
* What is the next step?<br />
<br />
Anyone arriving at the site has awareness of the product. What they lack is a reason to purchase.<br />
<br />
The problems our product solves are:<br />
* Need to reach a large scale audience quickly<br />
* Need to reach a new targeted audience<br />
* Need to re-engage current users<br />
<br />
''NOTE: Market research on these customer problems is ongoing. ''<br />
<br />
<br />
'''Audience think/do/feel'''<br />
Before the customer has visited this site they have awareness of the product - at least of the URL content.mozilla.org. After visiting this site, the customer will know if this product is aimed at them, the effort involved to buy a Tile, and how to proceed.<br />
<br />
'''Tone'''<br />
<br />
The Tone should be in line with Mozilla corporate partner communications:<br />
* https://www.mozilla.org/en-US/firefox/partners/<br />
* https://www.mozilla.org/en-US/about/partnerships/<br />
* https://mobilepartners.mozilla.org/ <br />
* This site will not have a different / distinct voice.<br />
<br />
'''Content Strategy & Requirements'''<br />
<br />
* The site is relatively straightforwards: it does not impact other pages<br />
* It will need to host relatively static content.<br />
* The site should not use Flash, and will conform to all Mozilla privacy requirements.<br />
* The site will require some copy-editing, and should be localised after launch into German and French.<br />
* The site will require at least two video assets. <br />
* The site will require a contact form which should be integrated with or instance of Salesforce.<br />
<br />
'''Other Considerations'''<br />
<br />
This is the start of Content Services go-to-market and we will be both adding social proof and new product in the coming year. The site must, therefore, be relatively easy to update, specially the value proposition and customer success story spaces.<br />
<br />
<br />
* User Stories<br />
''Pending''<br />
<br />
= Project Information =<br />
<br />
* Communications Channel(s): IRC, Basecamp, or other communications method<br />
''TBD in negotiation with project team''<br />
<br />
* Team members (RASCI): <br />
''TBD in negotiation with project team.''<br />
R: TBD<br />
A: Patrick Finch is deemed approver.<br />
S: Content Services product management and BD (Kevin Ghim, Sean Bohan, Justin Terry)<br />
C: Business and legal affairs content owner (Geoff Piper)<br />
I: Content Services, Mozilla non-Content Services BD<br />
<br />
* Notes & Meetings Hub<br />
<br />
* How to contribute <br />
To help test and localise, please contact Patrick Finch<br />
<br />
== Website Information ==<br />
<br />
* Code name: Content.Mozilla.Org<br />
* Prod URL: http://content.mozilla.org<br />
* Dev URL: http://example-dev.allizom.org/<br />
* Stage URL: http://example-stage.allizom.org/<br />
* Code Repo: https://github.com/mozilla/example<br />
* L10N Repo: https://svn.mozilla.org/projects/l10n-misc/trunk/example/locale/<br />
* Code: Language / Framework<br />
<br />
= Team =<br />
<br />
The primary and secondary contacts for each role of this project:<br />
<br />
* Product owner - {Name}<br />
* TPM - {Name}<br />
* Web Project Manager - {Name}<br />
* Developers - {Name}<br />
* L10N - {Name}<br />
* Designer - {Name}<br />
* IT - {Name}<br />
* QA - {Name}<br />
* UX - {Name}<br />
* Security - {Name}<br />
* Legal - {Name}<br />
<br />
<br />
= Project Management =<br />
* {{Bug|123456}} Project Tracking Bug<br />
* Project Timeline<br />
<br />
== Key Deliverable Bugs ==<br />
<br />
* {{Bug|123456}} Project Tracking Bug<br />
<br />
= End of Life Plan =</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Content_services&diff=1057723Content services2015-02-24T00:02:20Z<p>Pfinch: Removed 2014 content, updated vision and mission</p>
<hr />
<div>= Content Services Overview =<br />
<br />
The Content Services Team was formed in late 2013 to explore opportunities that will provide additional value to our users, strongly align with our mission, and over time, generate new sources of diversified revenue.<br />
<br />
The team works to make the web economically and socially sustainable. We want to sustain it economically, to ensure that the Web remains a place of economic opportunity for content creators. And we wish to make is socially sustainable, meaning that we wish to address the "maladies" that the advertising-supported content ecosystem has engendered on the Web, including: <br />
* poor use experience<br />
* widespread use of proprietary technology on the Web<br />
* ad fraud<br />
* lack of user control over data resulting in a loss of privacy<br />
<br />
Our current mission is to provide in-browser promoted content experiences for advertisers who want better, higher-quality relationships with their audience<br />
and who choose Mozilla Content Services in order to have a future-facing, ethical partner with scale.<br />
<br />
<br />
== Product Roadmaps==<br />
<br />
===Directory Tiles===<br />
:Every time a user opens up a new tab in Firefox, the browser displays Tiles. Frequent Firefox users see screenshots of the websites they visit most often in their Tiles. We look to leverage the Tiles on our New Tab pages and make them a source of revenue for Mozilla. There are a few opportunities that we will test in market (first in pre-release channels) within 2014 and the first of which is to provide sponsored content on First-Run-Tiles known as Directory Tiles. This should begin testing in Q2/3 and we will then work on additional Tile enhancements outside of First-Run.<br />
<br />
===[https://intranet.mozilla.org/UP UP/Intent Engine]===<br />
:[https://intranet.mozilla.org/UP UP] is our Intent Engine for across Mozilla that helps us deliver personalization platforms for all of our products and services. Our 2014 strategy is to keep building our UP platform to make it available to the desktop, OS, services, and other products and have the bridges built this year that each product team has the ability to read/write to it. We will do limited tests in Q2/3/4 of this year to test different Intent Engine modules (such as tasks, discovery, personalization, ads). Within UP, we have a particular focus around Intentcasting and VRM.<br />
<br />
<br />
== Content Services Resources==<br />
<br />
Doc Searls' [http://www.amazon.com/The-Intention-Economy-Customers-Charge/dp/1422158527 Intention Economy Book.] <br />
<br />
Check out our [https://blog.mozilla.org/advancingcontent/ Official Content Services Blog.]<br />
<br />
Join our Interest mailing list [https://mail.mozilla.org/listinfo/contentservices-distro ContentServices Distro]<br />
<br />
Reach out on email to [mailto:contentservices@mozilla.com?Subject=Your%20Subject%20Here the Content Services Team]<br />
<br />
Find us on IRC #mozcontent</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Fosdem:2015:Attendees&diff=1050756Fosdem:2015:Attendees2015-01-27T12:26:09Z<p>Pfinch: added pfinch attendance at FOSDEM</p>
<hr />
<div>* Benoit Leseul<br />
* Ziggy Maes<br />
* Monique Brunel<br />
* Flore Allemandou<br />
* Francisco Picolini<br />
* Giannis Konstantinidis<br />
* Stephen John Murphy<br />
* Soumya Kanti Chakraborty<br />
* Sébastien Desvignes<br />
* Christos Bacharakis<br />
* Ioana Chiorean<br />
* Szmozsanszky Istvan (flaki)<br />
* Andrzej Mazur<br />
* Daniel Stenberg<br />
* Loïc Cuguen<br />
* Panagiotis Astithas<br />
* Tim Taubert<br />
* Florian Quèze<br />
* Pierros Papadeas<br />
* Ali Spivak<br />
* Marco Zehe<br />
* Margaret Leibovic<br />
* Jon Coppeard<br />
* Soledad Penadés<br />
* Benjamin Bouvier<br />
* Josh Matthews<br />
* Robert Kaiser<br />
* Brian King<br />
* Elio Qoshi<br />
* Daniele Scasciafratte<br />
* Patrick Finch<br />
<br />
<br />
See also the list of attendees on ReMo: https://reps.mozilla.org/e/fosdem-2015/</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Tiles/Technical_Documentation&diff=1033193Tiles/Technical Documentation2014-11-13T12:57:44Z<p>Pfinch: /* Source Code */ formatting improved</p>
<hr />
<div>== Tiles Technical Documentation ==<br />
<br />
For information about the ''progress and plans'' for [[Tiles]] see the [[Content services]] page.<br />
<br />
For general information about Tiles and the New Tab page see the [[Tiles]] page.<br />
<br />
This is technical information for advanced users or enterprise implementers on how Tiles are stored locally and fetched remotely and how you can change it.<br />
<br />
=== Previously ===<br />
<br />
Default Tiles were originally built into Desktop Firefox for en-US builds in the ''chrome://global/content/directoryLinks.json'' location. This file no longer exists in Firefox as Tiles are now downloaded from a web service. Additionally the preference ( ''browser.newtabpage.directorySource'' ) for Tiles has changed, the current details are listed below.<br />
<br />
=== Preferences ===<br />
<br />
There are two main preferences for Tiles that control fetching and metrics.<br />
<br />
==== Source ====<br />
<br />
This preference tells Firefox where to fetch Tiles from:<br />
<br />
browser.newtabpage.directory.source = https://tiles.services.mozilla.com/v2/links/fetch<br />
<br />
This preference can be set to anything that returns JSON, setting this to an empty JSON object will disable Tiles from showing and fetching new Tiles. With the change below a new user would only see empty Tiles and Firefox could no longer fetch new Tiles.<br />
<br />
browser.newtabpage.directory.source = data:application/json,{}<br />
<br />
==== Ping ====<br />
<br />
This preference tells Firefox where Tiles metrics are reported:<br />
<br />
browser.newtabpage.directory.ping = https://tiles.services.mozilla.com/v2/links/<br />
<br />
Changing or disabling this pref may prevent Firefox from being able to report metrics on Tiles. Do not set this to alternate URLs, setting this to nothing will disable the ping.<br />
<br />
=== Customizing Tiles ===<br />
<br />
If you wanted to have a custom set of Default Tiles, for example in an Enterprise deployment, you could set the source preference to a custom set of local Tiles.<br />
<br />
Here's an example of a custom default tiles ''source'' preference:<br />
<br />
data:application/json,{<br />
"en-US": [<br />
{<br />
"url" : "http://www.mozilla.org/",<br />
"bgColor" : "%234d4e54",<br />
"type": "custom",<br />
"imageURI": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAALQAAABWCAQAAADMSHQwAAAFWklEQVR4AezBgQAAAACAoP2pF6kCAAAAAAAAAABgdu0sNqoyDOP4C1WWgCylKgqKoNRCqaxCiyx2bBGNAVrCJkRkUYFAMEGNVUjYRIIIuAYlBqKAUSBcWEUIBlDCBRU6pKINCAUU0CibbSyL9e%2FNmTdvpudMF2ZGj5nfc%2FcwyZCH6Xd6DlMXTGUbe1jEjYhJMgEK2M5WGiDYZDCJ1QTJRWId4f%2BTDwkpoanT5bKXcgDgEqJpyFrKCJmWGLr2ycNa4rQzQf1OY0RzFdTziaFrn41Yh%2FQTjSqnBaLZA2puYujaZy3Wt06bBepPkhFNIaj5iaFrn4FY0522F3boNohmE6gFiaHrkvmEbNQuw3PoDYlPdP0zmOWsYoRpunkOvT4xdDTj%2F6FpS3vESTo5ZNMBwaYBGeQQIBWJmNsZRB7DybJD1DvN6EE%2BraM0dGdyGct4HiMj3kM3pzdz%2BIzLnEIQ5lJKyC6ynVfdxFJOEPKd52%2Bqk9jNNUIq2MYYBJtxlNSQxc4%2F64t8ykEuAJB63UNns5ojWMdZRqv4DV0IahL7CTcN4UHOEO5rkhBsulOEm13Yn40CalKIICRhdbiOoZOYQRHufqFvvIZeTkgV7t7F3TLEpD%2FeLtIRcTKLmqxz5vk5KkM%2FQxmRXCU5PkPnUF%2BXzGf6VqqI5FeaOK98mer%2BxiqM6tDvUJMV8Rm6J%2BH28T5bwKXfQDHWPYiTHVgvkEZXXsLarJejMdiMJkAp1uyoDi2UgSpiDSvYjPV9fIZOw%2FqS3k6%2FAmunnmU%2Fgsp0uj5YeYiT8Vg9ENf0ohLUbiTKQ%2Fd1Xr2ENO2mgDpHo3gM3RnUAdMPAPWx6T8CNdDlAVAQMTkC9ux1STusq7SK%2BtDCVnbQLqyrJKSClvEYOhXUF6bPBDXd9B9UGzqJS56XyJWgziIuOYyVh8RgaLecJKQ8%2FkPvMn0WqHkeT9UGuJzyTyMm07A6IWFZhbUFifHQN9OF%2B%2BlPFmcJuUCzf3Po%2Fh5Dr6s29ONYwxCTfKyHEGyGYl0gKYZDj2U9pVRS3W808cfQz2IFIkyZj5i0oBJrEBKjoUdxFG9nuMEfQxdEmGsI1mjEZC%2FW60iMhp5HZKdo4I%2Bh50Q4Hh7Bsg88n8MqRWI0dIBwFfzECXOTdBzxx9ATI5zRo7AGYx%2FgWx1jNvRhrJX0ozUNSeEKIUf9MvQDWFMQk5lYd2h%2FGmsWEqOhO2EtNteHKkIO%2B2XoplwGtQgxeRvUSW0%2FwdqH1GvoSlI8hl6g7QisttrfBeqQX4YWPgf1FWJyDNR7TvckVhUpdRg6HdQ1bvG4Y12o7QSslq73oyX%2BGXoIVlePL8F0QxDuxKrkPqQOQ9%2BLlezx93rV4xqRqX17UBf9M7QQBHWeCbSmBeO4Uu3pXXNKsUrIYlhYRpLkOXQbz7vQt0Ad1LYb1iHnVO%2FFfqxh%2Fhk6FbAq%2BAPrvPPtueGA9RfVnaah59DCMaydPOz0U7FKWOt62T3PJnYQ7hyZfhlayMfbZdJqfpWagUQYugALtjl9S8I47zmO2gjGfuh0FD%2BYPtvjrq0QRQ5iEqAMN0G6mCcONWvlDG3dbb43egBcT%2BqJWPCafd4Y8b%2Foyuka%2B6E7UOwkyBrTdze9PQsXEtQ%2F6YnY0IjZFNmDgW94CjEZTHHEBHlTB91u%2BtsQM%2FUbVJj36Gt%2BqoIo1ms%2Fi9NYUEw%2FhNkAQIY%2Fv0DTiVzGMJps2iExSgqPMpknCJBCEmLSh%2FFMZgTpNDJtY%2FJZyga2spFXGKr9SIoYhfwXh%2F6nHToQAQAAAADkb73IbXCjR49u9OhGjx7d6NGNHj260aMbPXp0o0c3evToRo8OZGoOg%2BFHUXQAAAAASUVORK5CYII%3D",<br />
"title": "Mozilla%20Foundation"<br />
}<br />
]<br />
}<br />
<br />
=== JSON Format ===<br />
<br />
The Tile JSON format is a simple object, the top level needs to be a locale that Firefox understands. This object allows you to offer multiple locales in a single JSON file.<br />
<br />
At a high level the data object looks like this:<br />
<br />
{ "LOCALE" : [ ARRAY OF DEFAULT TILE OBJECTS ] }<br />
<br />
You can have many locales in the Tiles dictionary object to support multiple languages.<br />
<br />
For example:<br />
<br />
{ "en-US" : [ ARRAY OF US DEFAULT TILES ], "en-CA" : [ ARRAY OF CA DEFAULT TILES ] }<br />
<br />
Each Default Tile object requires a few attributes, most of which are self explanatory.<br />
<br />
{<br />
"url" : "http://www.mozilla.org/",<br />
"bgColor" : "%234d4e54",<br />
"type": "custom",<br />
"imageURI": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAALQAAABWCAQAAADMSHQwAAAFWklEQVR4AezBgQAAAACAoP2pF6kCAAAAAAAAAABgdu0sNqoyDOP4C1WWgCylKgqKoNRCqaxCiyx2bBGNAVrCJkRkUYFAMEGNVUjYRIIIuAYlBqKAUSBcWEUIBlDCBRU6pKINCAUU0CibbSyL9e%2FNmTdvpudMF2ZGj5nfc%2FcwyZCH6Xd6DlMXTGUbe1jEjYhJMgEK2M5WGiDYZDCJ1QTJRWId4f%2BTDwkpoanT5bKXcgDgEqJpyFrKCJmWGLr2ycNa4rQzQf1OY0RzFdTziaFrn41Yh%2FQTjSqnBaLZA2puYujaZy3Wt06bBepPkhFNIaj5iaFrn4FY0522F3boNohmE6gFiaHrkvmEbNQuw3PoDYlPdP0zmOWsYoRpunkOvT4xdDTj%2F6FpS3vESTo5ZNMBwaYBGeQQIBWJmNsZRB7DybJD1DvN6EE%2BraM0dGdyGct4HiMj3kM3pzdz%2BIzLnEIQ5lJKyC6ynVfdxFJOEPKd52%2Bqk9jNNUIq2MYYBJtxlNSQxc4%2F64t8ykEuAJB63UNns5ojWMdZRqv4DV0IahL7CTcN4UHOEO5rkhBsulOEm13Yn40CalKIICRhdbiOoZOYQRHufqFvvIZeTkgV7t7F3TLEpD%2FeLtIRcTKLmqxz5vk5KkM%2FQxmRXCU5PkPnUF%2BXzGf6VqqI5FeaOK98mer%2BxiqM6tDvUJMV8Rm6J%2BH28T5bwKXfQDHWPYiTHVgvkEZXXsLarJejMdiMJkAp1uyoDi2UgSpiDSvYjPV9fIZOw%2FqS3k6%2FAmunnmU%2Fgsp0uj5YeYiT8Vg9ENf0ohLUbiTKQ%2Fd1Xr2ENO2mgDpHo3gM3RnUAdMPAPWx6T8CNdDlAVAQMTkC9ux1STusq7SK%2BtDCVnbQLqyrJKSClvEYOhXUF6bPBDXd9B9UGzqJS56XyJWgziIuOYyVh8RgaLecJKQ8%2FkPvMn0WqHkeT9UGuJzyTyMm07A6IWFZhbUFifHQN9OF%2B%2BlPFmcJuUCzf3Po%2Fh5Dr6s29ONYwxCTfKyHEGyGYl0gKYZDj2U9pVRS3W808cfQz2IFIkyZj5i0oBJrEBKjoUdxFG9nuMEfQxdEmGsI1mjEZC%2FW60iMhp5HZKdo4I%2Bh50Q4Hh7Bsg88n8MqRWI0dIBwFfzECXOTdBzxx9ATI5zRo7AGYx%2FgWx1jNvRhrJX0ozUNSeEKIUf9MvQDWFMQk5lYd2h%2FGmsWEqOhO2EtNteHKkIO%2B2XoplwGtQgxeRvUSW0%2FwdqH1GvoSlI8hl6g7QisttrfBeqQX4YWPgf1FWJyDNR7TvckVhUpdRg6HdQ1bvG4Y12o7QSslq73oyX%2BGXoIVlePL8F0QxDuxKrkPqQOQ9%2BLlezx93rV4xqRqX17UBf9M7QQBHWeCbSmBeO4Uu3pXXNKsUrIYlhYRpLkOXQbz7vQt0Ad1LYb1iHnVO%2FFfqxh%2Fhk6FbAq%2BAPrvPPtueGA9RfVnaah59DCMaydPOz0U7FKWOt62T3PJnYQ7hyZfhlayMfbZdJqfpWagUQYugALtjl9S8I47zmO2gjGfuh0FD%2BYPtvjrq0QRQ5iEqAMN0G6mCcONWvlDG3dbb43egBcT%2BqJWPCafd4Y8b%2Foyuka%2B6E7UOwkyBrTdze9PQsXEtQ%2F6YnY0IjZFNmDgW94CjEZTHHEBHlTB91u%2BtsQM%2FUbVJj36Gt%2BqoIo1ms%2Fi9NYUEw%2FhNkAQIY%2Fv0DTiVzGMJps2iExSgqPMpknCJBCEmLSh%2FFMZgTpNDJtY%2FJZyga2spFXGKr9SIoYhfwXh%2F6nHToQAQAAAADkb73IbXCjR49u9OhGjx7d6NGNHj260aMbPXp0o0c3evToRo8OZGoOg%2BFHUXQAAAAASUVORK5CYII%3D",<br />
"title": "Mozilla%20Foundation"<br />
}<br />
<br />
'''NOTE''': You need to URL escape all the text, in the bgColor you'll see the # is replaced with %23 and the spaces are replaced with %20 in the title.<br />
<br />
''Default Tiles Object Attributes''<br />
<br />
* '''url''' is the URL you want the Tile to link to<br />
* '''bgColor''' provides a background fill color in case the image doesn't fill the space<br />
* '''type''' isn't needed for custom tiles so please use the 'custom' attribute<br />
* '''imageURI''' provides the full URL to the image you want centered. Images need to be properly sized for the Tiles.<br />
* '''title''' provides the display text that will appear below the Tile and for the link title attribute.<br />
* '''enhancedImageURI''' provides the full URL to the roll over image you want centered. Images need to be properly sized for the Tiles. If included a "Roll Over" image will be the image seen until a user mouses over the Tile, on mouse over the imageURI is then shown.<br />
<br />
==== Source Code ====<br />
<br />
* '''Firefox''' code related to the new tab page that powers Tiles.<br />
**http://mxr.mozilla.org/mozilla-central/source/browser/base/content/newtab/<br />
**https://mxr.mozilla.org/mozilla-central/source/toolkit/modules/NewTabUtils.jsm<br />
<br />
* '''Onyx''' is a link server and engagement metrics aggregator for Firefox Tiles handling the delivery and receiving the metrics of Tiles via 3 data endpoints.<br />
** https://github.com/mozilla/onyx<br />
<br />
* '''Infernyx''' contains the rules to extract the metrics data and handles the immediate data processing of raw received data into aggregate data.<br />
** https://github.com/mozilla/infernyx<br />
<br />
* '''Splice''' is our ingestion, validation, and authoring tool that makes sure tiles are processed, then published to the correct locale and country for Firefox users. It also contains the schemas for the metrics data.<br />
** https://github.com/mozilla/splice</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Tiles/Technical_Documentation&diff=1033192Tiles/Technical Documentation2014-11-13T12:56:07Z<p>Pfinch: Undo revision 1033191 by Pfinch (talk)</p>
<hr />
<div>== Tiles Technical Documentation ==<br />
<br />
For information about the ''progress and plans'' for [[Tiles]] see the [[Content services]] page.<br />
<br />
For general information about Tiles and the New Tab page see the [[Tiles]] page.<br />
<br />
This is technical information for advanced users or enterprise implementers on how Tiles are stored locally and fetched remotely and how you can change it.<br />
<br />
=== Previously ===<br />
<br />
Default Tiles were originally built into Desktop Firefox for en-US builds in the ''chrome://global/content/directoryLinks.json'' location. This file no longer exists in Firefox as Tiles are now downloaded from a web service. Additionally the preference ( ''browser.newtabpage.directorySource'' ) for Tiles has changed, the current details are listed below.<br />
<br />
=== Preferences ===<br />
<br />
There are two main preferences for Tiles that control fetching and metrics.<br />
<br />
==== Source ====<br />
<br />
This preference tells Firefox where to fetch Tiles from:<br />
<br />
browser.newtabpage.directory.source = https://tiles.services.mozilla.com/v2/links/fetch<br />
<br />
This preference can be set to anything that returns JSON, setting this to an empty JSON object will disable Tiles from showing and fetching new Tiles. With the change below a new user would only see empty Tiles and Firefox could no longer fetch new Tiles.<br />
<br />
browser.newtabpage.directory.source = data:application/json,{}<br />
<br />
==== Ping ====<br />
<br />
This preference tells Firefox where Tiles metrics are reported:<br />
<br />
browser.newtabpage.directory.ping = https://tiles.services.mozilla.com/v2/links/<br />
<br />
Changing or disabling this pref may prevent Firefox from being able to report metrics on Tiles. Do not set this to alternate URLs, setting this to nothing will disable the ping.<br />
<br />
=== Customizing Tiles ===<br />
<br />
If you wanted to have a custom set of Default Tiles, for example in an Enterprise deployment, you could set the source preference to a custom set of local Tiles.<br />
<br />
Here's an example of a custom default tiles ''source'' preference:<br />
<br />
data:application/json,{<br />
"en-US": [<br />
{<br />
"url" : "http://www.mozilla.org/",<br />
"bgColor" : "%234d4e54",<br />
"type": "custom",<br />
"imageURI": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAALQAAABWCAQAAADMSHQwAAAFWklEQVR4AezBgQAAAACAoP2pF6kCAAAAAAAAAABgdu0sNqoyDOP4C1WWgCylKgqKoNRCqaxCiyx2bBGNAVrCJkRkUYFAMEGNVUjYRIIIuAYlBqKAUSBcWEUIBlDCBRU6pKINCAUU0CibbSyL9e%2FNmTdvpudMF2ZGj5nfc%2FcwyZCH6Xd6DlMXTGUbe1jEjYhJMgEK2M5WGiDYZDCJ1QTJRWId4f%2BTDwkpoanT5bKXcgDgEqJpyFrKCJmWGLr2ycNa4rQzQf1OY0RzFdTziaFrn41Yh%2FQTjSqnBaLZA2puYujaZy3Wt06bBepPkhFNIaj5iaFrn4FY0522F3boNohmE6gFiaHrkvmEbNQuw3PoDYlPdP0zmOWsYoRpunkOvT4xdDTj%2F6FpS3vESTo5ZNMBwaYBGeQQIBWJmNsZRB7DybJD1DvN6EE%2BraM0dGdyGct4HiMj3kM3pzdz%2BIzLnEIQ5lJKyC6ynVfdxFJOEPKd52%2Bqk9jNNUIq2MYYBJtxlNSQxc4%2F64t8ykEuAJB63UNns5ojWMdZRqv4DV0IahL7CTcN4UHOEO5rkhBsulOEm13Yn40CalKIICRhdbiOoZOYQRHufqFvvIZeTkgV7t7F3TLEpD%2FeLtIRcTKLmqxz5vk5KkM%2FQxmRXCU5PkPnUF%2BXzGf6VqqI5FeaOK98mer%2BxiqM6tDvUJMV8Rm6J%2BH28T5bwKXfQDHWPYiTHVgvkEZXXsLarJejMdiMJkAp1uyoDi2UgSpiDSvYjPV9fIZOw%2FqS3k6%2FAmunnmU%2Fgsp0uj5YeYiT8Vg9ENf0ohLUbiTKQ%2Fd1Xr2ENO2mgDpHo3gM3RnUAdMPAPWx6T8CNdDlAVAQMTkC9ux1STusq7SK%2BtDCVnbQLqyrJKSClvEYOhXUF6bPBDXd9B9UGzqJS56XyJWgziIuOYyVh8RgaLecJKQ8%2FkPvMn0WqHkeT9UGuJzyTyMm07A6IWFZhbUFifHQN9OF%2B%2BlPFmcJuUCzf3Po%2Fh5Dr6s29ONYwxCTfKyHEGyGYl0gKYZDj2U9pVRS3W808cfQz2IFIkyZj5i0oBJrEBKjoUdxFG9nuMEfQxdEmGsI1mjEZC%2FW60iMhp5HZKdo4I%2Bh50Q4Hh7Bsg88n8MqRWI0dIBwFfzECXOTdBzxx9ATI5zRo7AGYx%2FgWx1jNvRhrJX0ozUNSeEKIUf9MvQDWFMQk5lYd2h%2FGmsWEqOhO2EtNteHKkIO%2B2XoplwGtQgxeRvUSW0%2FwdqH1GvoSlI8hl6g7QisttrfBeqQX4YWPgf1FWJyDNR7TvckVhUpdRg6HdQ1bvG4Y12o7QSslq73oyX%2BGXoIVlePL8F0QxDuxKrkPqQOQ9%2BLlezx93rV4xqRqX17UBf9M7QQBHWeCbSmBeO4Uu3pXXNKsUrIYlhYRpLkOXQbz7vQt0Ad1LYb1iHnVO%2FFfqxh%2Fhk6FbAq%2BAPrvPPtueGA9RfVnaah59DCMaydPOz0U7FKWOt62T3PJnYQ7hyZfhlayMfbZdJqfpWagUQYugALtjl9S8I47zmO2gjGfuh0FD%2BYPtvjrq0QRQ5iEqAMN0G6mCcONWvlDG3dbb43egBcT%2BqJWPCafd4Y8b%2Foyuka%2B6E7UOwkyBrTdze9PQsXEtQ%2F6YnY0IjZFNmDgW94CjEZTHHEBHlTB91u%2BtsQM%2FUbVJj36Gt%2BqoIo1ms%2Fi9NYUEw%2FhNkAQIY%2Fv0DTiVzGMJps2iExSgqPMpknCJBCEmLSh%2FFMZgTpNDJtY%2FJZyga2spFXGKr9SIoYhfwXh%2F6nHToQAQAAAADkb73IbXCjR49u9OhGjx7d6NGNHj260aMbPXp0o0c3evToRo8OZGoOg%2BFHUXQAAAAASUVORK5CYII%3D",<br />
"title": "Mozilla%20Foundation"<br />
}<br />
]<br />
}<br />
<br />
=== JSON Format ===<br />
<br />
The Tile JSON format is a simple object, the top level needs to be a locale that Firefox understands. This object allows you to offer multiple locales in a single JSON file.<br />
<br />
At a high level the data object looks like this:<br />
<br />
{ "LOCALE" : [ ARRAY OF DEFAULT TILE OBJECTS ] }<br />
<br />
You can have many locales in the Tiles dictionary object to support multiple languages.<br />
<br />
For example:<br />
<br />
{ "en-US" : [ ARRAY OF US DEFAULT TILES ], "en-CA" : [ ARRAY OF CA DEFAULT TILES ] }<br />
<br />
Each Default Tile object requires a few attributes, most of which are self explanatory.<br />
<br />
{<br />
"url" : "http://www.mozilla.org/",<br />
"bgColor" : "%234d4e54",<br />
"type": "custom",<br />
"imageURI": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAALQAAABWCAQAAADMSHQwAAAFWklEQVR4AezBgQAAAACAoP2pF6kCAAAAAAAAAABgdu0sNqoyDOP4C1WWgCylKgqKoNRCqaxCiyx2bBGNAVrCJkRkUYFAMEGNVUjYRIIIuAYlBqKAUSBcWEUIBlDCBRU6pKINCAUU0CibbSyL9e%2FNmTdvpudMF2ZGj5nfc%2FcwyZCH6Xd6DlMXTGUbe1jEjYhJMgEK2M5WGiDYZDCJ1QTJRWId4f%2BTDwkpoanT5bKXcgDgEqJpyFrKCJmWGLr2ycNa4rQzQf1OY0RzFdTziaFrn41Yh%2FQTjSqnBaLZA2puYujaZy3Wt06bBepPkhFNIaj5iaFrn4FY0522F3boNohmE6gFiaHrkvmEbNQuw3PoDYlPdP0zmOWsYoRpunkOvT4xdDTj%2F6FpS3vESTo5ZNMBwaYBGeQQIBWJmNsZRB7DybJD1DvN6EE%2BraM0dGdyGct4HiMj3kM3pzdz%2BIzLnEIQ5lJKyC6ynVfdxFJOEPKd52%2Bqk9jNNUIq2MYYBJtxlNSQxc4%2F64t8ykEuAJB63UNns5ojWMdZRqv4DV0IahL7CTcN4UHOEO5rkhBsulOEm13Yn40CalKIICRhdbiOoZOYQRHufqFvvIZeTkgV7t7F3TLEpD%2FeLtIRcTKLmqxz5vk5KkM%2FQxmRXCU5PkPnUF%2BXzGf6VqqI5FeaOK98mer%2BxiqM6tDvUJMV8Rm6J%2BH28T5bwKXfQDHWPYiTHVgvkEZXXsLarJejMdiMJkAp1uyoDi2UgSpiDSvYjPV9fIZOw%2FqS3k6%2FAmunnmU%2Fgsp0uj5YeYiT8Vg9ENf0ohLUbiTKQ%2Fd1Xr2ENO2mgDpHo3gM3RnUAdMPAPWx6T8CNdDlAVAQMTkC9ux1STusq7SK%2BtDCVnbQLqyrJKSClvEYOhXUF6bPBDXd9B9UGzqJS56XyJWgziIuOYyVh8RgaLecJKQ8%2FkPvMn0WqHkeT9UGuJzyTyMm07A6IWFZhbUFifHQN9OF%2B%2BlPFmcJuUCzf3Po%2Fh5Dr6s29ONYwxCTfKyHEGyGYl0gKYZDj2U9pVRS3W808cfQz2IFIkyZj5i0oBJrEBKjoUdxFG9nuMEfQxdEmGsI1mjEZC%2FW60iMhp5HZKdo4I%2Bh50Q4Hh7Bsg88n8MqRWI0dIBwFfzECXOTdBzxx9ATI5zRo7AGYx%2FgWx1jNvRhrJX0ozUNSeEKIUf9MvQDWFMQk5lYd2h%2FGmsWEqOhO2EtNteHKkIO%2B2XoplwGtQgxeRvUSW0%2FwdqH1GvoSlI8hl6g7QisttrfBeqQX4YWPgf1FWJyDNR7TvckVhUpdRg6HdQ1bvG4Y12o7QSslq73oyX%2BGXoIVlePL8F0QxDuxKrkPqQOQ9%2BLlezx93rV4xqRqX17UBf9M7QQBHWeCbSmBeO4Uu3pXXNKsUrIYlhYRpLkOXQbz7vQt0Ad1LYb1iHnVO%2FFfqxh%2Fhk6FbAq%2BAPrvPPtueGA9RfVnaah59DCMaydPOz0U7FKWOt62T3PJnYQ7hyZfhlayMfbZdJqfpWagUQYugALtjl9S8I47zmO2gjGfuh0FD%2BYPtvjrq0QRQ5iEqAMN0G6mCcONWvlDG3dbb43egBcT%2BqJWPCafd4Y8b%2Foyuka%2B6E7UOwkyBrTdze9PQsXEtQ%2F6YnY0IjZFNmDgW94CjEZTHHEBHlTB91u%2BtsQM%2FUbVJj36Gt%2BqoIo1ms%2Fi9NYUEw%2FhNkAQIY%2Fv0DTiVzGMJps2iExSgqPMpknCJBCEmLSh%2FFMZgTpNDJtY%2FJZyga2spFXGKr9SIoYhfwXh%2F6nHToQAQAAAADkb73IbXCjR49u9OhGjx7d6NGNHj260aMbPXp0o0c3evToRo8OZGoOg%2BFHUXQAAAAASUVORK5CYII%3D",<br />
"title": "Mozilla%20Foundation"<br />
}<br />
<br />
'''NOTE''': You need to URL escape all the text, in the bgColor you'll see the # is replaced with %23 and the spaces are replaced with %20 in the title.<br />
<br />
''Default Tiles Object Attributes''<br />
<br />
* '''url''' is the URL you want the Tile to link to<br />
* '''bgColor''' provides a background fill color in case the image doesn't fill the space<br />
* '''type''' isn't needed for custom tiles so please use the 'custom' attribute<br />
* '''imageURI''' provides the full URL to the image you want centered. Images need to be properly sized for the Tiles.<br />
* '''title''' provides the display text that will appear below the Tile and for the link title attribute.<br />
* '''enhancedImageURI''' provides the full URL to the roll over image you want centered. Images need to be properly sized for the Tiles. If included a "Roll Over" image will be the image seen until a user mouses over the Tile, on mouse over the imageURI is then shown.<br />
<br />
==== Source Code ====<br />
<br />
*Firefox<br />
**http://mxr.mozilla.org/mozilla-central/source/browser/base/content/newtab/<br />
**https://mxr.mozilla.org/mozilla-central/source/toolkit/modules/NewTabUtils.jsm<br />
Firefox code related to the new tab page that powers Tiles.<br />
<br />
* Onyx<br />
** https://github.com/mozilla/onyx<br />
Onyx is a link server and engagement metrics aggregator for Firefox Tiles handling the delivery and receiving the metrics of Tiles via 3 data endpoints.<br />
<br />
* Infernyx<br />
** https://github.com/mozilla/infernyx<br />
Infernyx contains the rules to extract the metrics data and handles the immediate data processing of raw received data into aggregate data.<br />
<br />
* Splice <br />
** https://github.com/mozilla/splice<br />
Splice is our ingestion, validation, and authoring tool that makes sure tiles are processed, then published to the correct locale and country for Firefox users. It also contains the schemas for the metrics data.</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Tiles/Technical_Documentation&diff=1033191Tiles/Technical Documentation2014-11-13T12:55:12Z<p>Pfinch: /* Source Code */ format improved</p>
<hr />
<div>== Tiles Technical Documentation ==<br />
<br />
For information about the ''progress and plans'' for [[Tiles]] see the [[Content services]] page.<br />
<br />
For general information about Tiles and the New Tab page see the [[Tiles]] page.<br />
<br />
This is technical information for advanced users or enterprise implementers on how Tiles are stored locally and fetched remotely and how you can change it.<br />
<br />
=== Previously ===<br />
<br />
Default Tiles were originally built into Desktop Firefox for en-US builds in the ''chrome://global/content/directoryLinks.json'' location. This file no longer exists in Firefox as Tiles are now downloaded from a web service. Additionally the preference ( ''browser.newtabpage.directorySource'' ) for Tiles has changed, the current details are listed below.<br />
<br />
=== Preferences ===<br />
<br />
There are two main preferences for Tiles that control fetching and metrics.<br />
<br />
==== Source ====<br />
<br />
This preference tells Firefox where to fetch Tiles from:<br />
<br />
browser.newtabpage.directory.source = https://tiles.services.mozilla.com/v2/links/fetch<br />
<br />
This preference can be set to anything that returns JSON, setting this to an empty JSON object will disable Tiles from showing and fetching new Tiles. With the change below a new user would only see empty Tiles and Firefox could no longer fetch new Tiles.<br />
<br />
browser.newtabpage.directory.source = data:application/json,{}<br />
<br />
==== Ping ====<br />
<br />
This preference tells Firefox where Tiles metrics are reported:<br />
<br />
browser.newtabpage.directory.ping = https://tiles.services.mozilla.com/v2/links/<br />
<br />
Changing or disabling this pref may prevent Firefox from being able to report metrics on Tiles. Do not set this to alternate URLs, setting this to nothing will disable the ping.<br />
<br />
=== Customizing Tiles ===<br />
<br />
If you wanted to have a custom set of Default Tiles, for example in an Enterprise deployment, you could set the source preference to a custom set of local Tiles.<br />
<br />
Here's an example of a custom default tiles ''source'' preference:<br />
<br />
data:application/json,{<br />
"en-US": [<br />
{<br />
"url" : "http://www.mozilla.org/",<br />
"bgColor" : "%234d4e54",<br />
"type": "custom",<br />
"imageURI": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAALQAAABWCAQAAADMSHQwAAAFWklEQVR4AezBgQAAAACAoP2pF6kCAAAAAAAAAABgdu0sNqoyDOP4C1WWgCylKgqKoNRCqaxCiyx2bBGNAVrCJkRkUYFAMEGNVUjYRIIIuAYlBqKAUSBcWEUIBlDCBRU6pKINCAUU0CibbSyL9e%2FNmTdvpudMF2ZGj5nfc%2FcwyZCH6Xd6DlMXTGUbe1jEjYhJMgEK2M5WGiDYZDCJ1QTJRWId4f%2BTDwkpoanT5bKXcgDgEqJpyFrKCJmWGLr2ycNa4rQzQf1OY0RzFdTziaFrn41Yh%2FQTjSqnBaLZA2puYujaZy3Wt06bBepPkhFNIaj5iaFrn4FY0522F3boNohmE6gFiaHrkvmEbNQuw3PoDYlPdP0zmOWsYoRpunkOvT4xdDTj%2F6FpS3vESTo5ZNMBwaYBGeQQIBWJmNsZRB7DybJD1DvN6EE%2BraM0dGdyGct4HiMj3kM3pzdz%2BIzLnEIQ5lJKyC6ynVfdxFJOEPKd52%2Bqk9jNNUIq2MYYBJtxlNSQxc4%2F64t8ykEuAJB63UNns5ojWMdZRqv4DV0IahL7CTcN4UHOEO5rkhBsulOEm13Yn40CalKIICRhdbiOoZOYQRHufqFvvIZeTkgV7t7F3TLEpD%2FeLtIRcTKLmqxz5vk5KkM%2FQxmRXCU5PkPnUF%2BXzGf6VqqI5FeaOK98mer%2BxiqM6tDvUJMV8Rm6J%2BH28T5bwKXfQDHWPYiTHVgvkEZXXsLarJejMdiMJkAp1uyoDi2UgSpiDSvYjPV9fIZOw%2FqS3k6%2FAmunnmU%2Fgsp0uj5YeYiT8Vg9ENf0ohLUbiTKQ%2Fd1Xr2ENO2mgDpHo3gM3RnUAdMPAPWx6T8CNdDlAVAQMTkC9ux1STusq7SK%2BtDCVnbQLqyrJKSClvEYOhXUF6bPBDXd9B9UGzqJS56XyJWgziIuOYyVh8RgaLecJKQ8%2FkPvMn0WqHkeT9UGuJzyTyMm07A6IWFZhbUFifHQN9OF%2B%2BlPFmcJuUCzf3Po%2Fh5Dr6s29ONYwxCTfKyHEGyGYl0gKYZDj2U9pVRS3W808cfQz2IFIkyZj5i0oBJrEBKjoUdxFG9nuMEfQxdEmGsI1mjEZC%2FW60iMhp5HZKdo4I%2Bh50Q4Hh7Bsg88n8MqRWI0dIBwFfzECXOTdBzxx9ATI5zRo7AGYx%2FgWx1jNvRhrJX0ozUNSeEKIUf9MvQDWFMQk5lYd2h%2FGmsWEqOhO2EtNteHKkIO%2B2XoplwGtQgxeRvUSW0%2FwdqH1GvoSlI8hl6g7QisttrfBeqQX4YWPgf1FWJyDNR7TvckVhUpdRg6HdQ1bvG4Y12o7QSslq73oyX%2BGXoIVlePL8F0QxDuxKrkPqQOQ9%2BLlezx93rV4xqRqX17UBf9M7QQBHWeCbSmBeO4Uu3pXXNKsUrIYlhYRpLkOXQbz7vQt0Ad1LYb1iHnVO%2FFfqxh%2Fhk6FbAq%2BAPrvPPtueGA9RfVnaah59DCMaydPOz0U7FKWOt62T3PJnYQ7hyZfhlayMfbZdJqfpWagUQYugALtjl9S8I47zmO2gjGfuh0FD%2BYPtvjrq0QRQ5iEqAMN0G6mCcONWvlDG3dbb43egBcT%2BqJWPCafd4Y8b%2Foyuka%2B6E7UOwkyBrTdze9PQsXEtQ%2F6YnY0IjZFNmDgW94CjEZTHHEBHlTB91u%2BtsQM%2FUbVJj36Gt%2BqoIo1ms%2Fi9NYUEw%2FhNkAQIY%2Fv0DTiVzGMJps2iExSgqPMpknCJBCEmLSh%2FFMZgTpNDJtY%2FJZyga2spFXGKr9SIoYhfwXh%2F6nHToQAQAAAADkb73IbXCjR49u9OhGjx7d6NGNHj260aMbPXp0o0c3evToRo8OZGoOg%2BFHUXQAAAAASUVORK5CYII%3D",<br />
"title": "Mozilla%20Foundation"<br />
}<br />
]<br />
}<br />
<br />
=== JSON Format ===<br />
<br />
The Tile JSON format is a simple object, the top level needs to be a locale that Firefox understands. This object allows you to offer multiple locales in a single JSON file.<br />
<br />
At a high level the data object looks like this:<br />
<br />
{ "LOCALE" : [ ARRAY OF DEFAULT TILE OBJECTS ] }<br />
<br />
You can have many locales in the Tiles dictionary object to support multiple languages.<br />
<br />
For example:<br />
<br />
{ "en-US" : [ ARRAY OF US DEFAULT TILES ], "en-CA" : [ ARRAY OF CA DEFAULT TILES ] }<br />
<br />
Each Default Tile object requires a few attributes, most of which are self explanatory.<br />
<br />
{<br />
"url" : "http://www.mozilla.org/",<br />
"bgColor" : "%234d4e54",<br />
"type": "custom",<br />
"imageURI": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAALQAAABWCAQAAADMSHQwAAAFWklEQVR4AezBgQAAAACAoP2pF6kCAAAAAAAAAABgdu0sNqoyDOP4C1WWgCylKgqKoNRCqaxCiyx2bBGNAVrCJkRkUYFAMEGNVUjYRIIIuAYlBqKAUSBcWEUIBlDCBRU6pKINCAUU0CibbSyL9e%2FNmTdvpudMF2ZGj5nfc%2FcwyZCH6Xd6DlMXTGUbe1jEjYhJMgEK2M5WGiDYZDCJ1QTJRWId4f%2BTDwkpoanT5bKXcgDgEqJpyFrKCJmWGLr2ycNa4rQzQf1OY0RzFdTziaFrn41Yh%2FQTjSqnBaLZA2puYujaZy3Wt06bBepPkhFNIaj5iaFrn4FY0522F3boNohmE6gFiaHrkvmEbNQuw3PoDYlPdP0zmOWsYoRpunkOvT4xdDTj%2F6FpS3vESTo5ZNMBwaYBGeQQIBWJmNsZRB7DybJD1DvN6EE%2BraM0dGdyGct4HiMj3kM3pzdz%2BIzLnEIQ5lJKyC6ynVfdxFJOEPKd52%2Bqk9jNNUIq2MYYBJtxlNSQxc4%2F64t8ykEuAJB63UNns5ojWMdZRqv4DV0IahL7CTcN4UHOEO5rkhBsulOEm13Yn40CalKIICRhdbiOoZOYQRHufqFvvIZeTkgV7t7F3TLEpD%2FeLtIRcTKLmqxz5vk5KkM%2FQxmRXCU5PkPnUF%2BXzGf6VqqI5FeaOK98mer%2BxiqM6tDvUJMV8Rm6J%2BH28T5bwKXfQDHWPYiTHVgvkEZXXsLarJejMdiMJkAp1uyoDi2UgSpiDSvYjPV9fIZOw%2FqS3k6%2FAmunnmU%2Fgsp0uj5YeYiT8Vg9ENf0ohLUbiTKQ%2Fd1Xr2ENO2mgDpHo3gM3RnUAdMPAPWx6T8CNdDlAVAQMTkC9ux1STusq7SK%2BtDCVnbQLqyrJKSClvEYOhXUF6bPBDXd9B9UGzqJS56XyJWgziIuOYyVh8RgaLecJKQ8%2FkPvMn0WqHkeT9UGuJzyTyMm07A6IWFZhbUFifHQN9OF%2B%2BlPFmcJuUCzf3Po%2Fh5Dr6s29ONYwxCTfKyHEGyGYl0gKYZDj2U9pVRS3W808cfQz2IFIkyZj5i0oBJrEBKjoUdxFG9nuMEfQxdEmGsI1mjEZC%2FW60iMhp5HZKdo4I%2Bh50Q4Hh7Bsg88n8MqRWI0dIBwFfzECXOTdBzxx9ATI5zRo7AGYx%2FgWx1jNvRhrJX0ozUNSeEKIUf9MvQDWFMQk5lYd2h%2FGmsWEqOhO2EtNteHKkIO%2B2XoplwGtQgxeRvUSW0%2FwdqH1GvoSlI8hl6g7QisttrfBeqQX4YWPgf1FWJyDNR7TvckVhUpdRg6HdQ1bvG4Y12o7QSslq73oyX%2BGXoIVlePL8F0QxDuxKrkPqQOQ9%2BLlezx93rV4xqRqX17UBf9M7QQBHWeCbSmBeO4Uu3pXXNKsUrIYlhYRpLkOXQbz7vQt0Ad1LYb1iHnVO%2FFfqxh%2Fhk6FbAq%2BAPrvPPtueGA9RfVnaah59DCMaydPOz0U7FKWOt62T3PJnYQ7hyZfhlayMfbZdJqfpWagUQYugALtjl9S8I47zmO2gjGfuh0FD%2BYPtvjrq0QRQ5iEqAMN0G6mCcONWvlDG3dbb43egBcT%2BqJWPCafd4Y8b%2Foyuka%2B6E7UOwkyBrTdze9PQsXEtQ%2F6YnY0IjZFNmDgW94CjEZTHHEBHlTB91u%2BtsQM%2FUbVJj36Gt%2BqoIo1ms%2Fi9NYUEw%2FhNkAQIY%2Fv0DTiVzGMJps2iExSgqPMpknCJBCEmLSh%2FFMZgTpNDJtY%2FJZyga2spFXGKr9SIoYhfwXh%2F6nHToQAQAAAADkb73IbXCjR49u9OhGjx7d6NGNHj260aMbPXp0o0c3evToRo8OZGoOg%2BFHUXQAAAAASUVORK5CYII%3D",<br />
"title": "Mozilla%20Foundation"<br />
}<br />
<br />
'''NOTE''': You need to URL escape all the text, in the bgColor you'll see the # is replaced with %23 and the spaces are replaced with %20 in the title.<br />
<br />
''Default Tiles Object Attributes''<br />
<br />
* '''url''' is the URL you want the Tile to link to<br />
* '''bgColor''' provides a background fill color in case the image doesn't fill the space<br />
* '''type''' isn't needed for custom tiles so please use the 'custom' attribute<br />
* '''imageURI''' provides the full URL to the image you want centered. Images need to be properly sized for the Tiles.<br />
* '''title''' provides the display text that will appear below the Tile and for the link title attribute.<br />
* '''enhancedImageURI''' provides the full URL to the roll over image you want centered. Images need to be properly sized for the Tiles. If included a "Roll Over" image will be the image seen until a user mouses over the Tile, on mouse over the imageURI is then shown.<br />
<br />
==== Source Code ====<br />
<br />
* Firefox code related to the new tab page that powers Tiles.<br />
**http://mxr.mozilla.org/mozilla-central/source/browser/base/content/newtab/<br />
**https://mxr.mozilla.org/mozilla-central/source/toolkit/modules/NewTabUtils.jsm<br />
<br />
<br />
* Onyx is a link server and engagement metrics aggregator for Firefox Tiles handling the delivery and receiving the metrics of Tiles via 3 data endpoints.<br />
** https://github.com/mozilla/onyx<br />
<br />
<br />
* Infernyx contains the rules to extract the metrics data and handles the immediate data processing of raw received data into aggregate data.<br />
<br />
** https://github.com/mozilla/infernyx<br />
<br />
* Splice is our ingestion, validation, and authoring tool that makes sure tiles are processed, then published to the correct locale and country for Firefox users. It also contains the schemas for the metrics data.<br />
** https://github.com/mozilla/splice</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Tiles/Technical_Documentation&diff=1033190Tiles/Technical Documentation2014-11-13T12:54:16Z<p>Pfinch: updated with Ingerynx and Spice repos</p>
<hr />
<div>== Tiles Technical Documentation ==<br />
<br />
For information about the ''progress and plans'' for [[Tiles]] see the [[Content services]] page.<br />
<br />
For general information about Tiles and the New Tab page see the [[Tiles]] page.<br />
<br />
This is technical information for advanced users or enterprise implementers on how Tiles are stored locally and fetched remotely and how you can change it.<br />
<br />
=== Previously ===<br />
<br />
Default Tiles were originally built into Desktop Firefox for en-US builds in the ''chrome://global/content/directoryLinks.json'' location. This file no longer exists in Firefox as Tiles are now downloaded from a web service. Additionally the preference ( ''browser.newtabpage.directorySource'' ) for Tiles has changed, the current details are listed below.<br />
<br />
=== Preferences ===<br />
<br />
There are two main preferences for Tiles that control fetching and metrics.<br />
<br />
==== Source ====<br />
<br />
This preference tells Firefox where to fetch Tiles from:<br />
<br />
browser.newtabpage.directory.source = https://tiles.services.mozilla.com/v2/links/fetch<br />
<br />
This preference can be set to anything that returns JSON, setting this to an empty JSON object will disable Tiles from showing and fetching new Tiles. With the change below a new user would only see empty Tiles and Firefox could no longer fetch new Tiles.<br />
<br />
browser.newtabpage.directory.source = data:application/json,{}<br />
<br />
==== Ping ====<br />
<br />
This preference tells Firefox where Tiles metrics are reported:<br />
<br />
browser.newtabpage.directory.ping = https://tiles.services.mozilla.com/v2/links/<br />
<br />
Changing or disabling this pref may prevent Firefox from being able to report metrics on Tiles. Do not set this to alternate URLs, setting this to nothing will disable the ping.<br />
<br />
=== Customizing Tiles ===<br />
<br />
If you wanted to have a custom set of Default Tiles, for example in an Enterprise deployment, you could set the source preference to a custom set of local Tiles.<br />
<br />
Here's an example of a custom default tiles ''source'' preference:<br />
<br />
data:application/json,{<br />
"en-US": [<br />
{<br />
"url" : "http://www.mozilla.org/",<br />
"bgColor" : "%234d4e54",<br />
"type": "custom",<br />
"imageURI": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAALQAAABWCAQAAADMSHQwAAAFWklEQVR4AezBgQAAAACAoP2pF6kCAAAAAAAAAABgdu0sNqoyDOP4C1WWgCylKgqKoNRCqaxCiyx2bBGNAVrCJkRkUYFAMEGNVUjYRIIIuAYlBqKAUSBcWEUIBlDCBRU6pKINCAUU0CibbSyL9e%2FNmTdvpudMF2ZGj5nfc%2FcwyZCH6Xd6DlMXTGUbe1jEjYhJMgEK2M5WGiDYZDCJ1QTJRWId4f%2BTDwkpoanT5bKXcgDgEqJpyFrKCJmWGLr2ycNa4rQzQf1OY0RzFdTziaFrn41Yh%2FQTjSqnBaLZA2puYujaZy3Wt06bBepPkhFNIaj5iaFrn4FY0522F3boNohmE6gFiaHrkvmEbNQuw3PoDYlPdP0zmOWsYoRpunkOvT4xdDTj%2F6FpS3vESTo5ZNMBwaYBGeQQIBWJmNsZRB7DybJD1DvN6EE%2BraM0dGdyGct4HiMj3kM3pzdz%2BIzLnEIQ5lJKyC6ynVfdxFJOEPKd52%2Bqk9jNNUIq2MYYBJtxlNSQxc4%2F64t8ykEuAJB63UNns5ojWMdZRqv4DV0IahL7CTcN4UHOEO5rkhBsulOEm13Yn40CalKIICRhdbiOoZOYQRHufqFvvIZeTkgV7t7F3TLEpD%2FeLtIRcTKLmqxz5vk5KkM%2FQxmRXCU5PkPnUF%2BXzGf6VqqI5FeaOK98mer%2BxiqM6tDvUJMV8Rm6J%2BH28T5bwKXfQDHWPYiTHVgvkEZXXsLarJejMdiMJkAp1uyoDi2UgSpiDSvYjPV9fIZOw%2FqS3k6%2FAmunnmU%2Fgsp0uj5YeYiT8Vg9ENf0ohLUbiTKQ%2Fd1Xr2ENO2mgDpHo3gM3RnUAdMPAPWx6T8CNdDlAVAQMTkC9ux1STusq7SK%2BtDCVnbQLqyrJKSClvEYOhXUF6bPBDXd9B9UGzqJS56XyJWgziIuOYyVh8RgaLecJKQ8%2FkPvMn0WqHkeT9UGuJzyTyMm07A6IWFZhbUFifHQN9OF%2B%2BlPFmcJuUCzf3Po%2Fh5Dr6s29ONYwxCTfKyHEGyGYl0gKYZDj2U9pVRS3W808cfQz2IFIkyZj5i0oBJrEBKjoUdxFG9nuMEfQxdEmGsI1mjEZC%2FW60iMhp5HZKdo4I%2Bh50Q4Hh7Bsg88n8MqRWI0dIBwFfzECXOTdBzxx9ATI5zRo7AGYx%2FgWx1jNvRhrJX0ozUNSeEKIUf9MvQDWFMQk5lYd2h%2FGmsWEqOhO2EtNteHKkIO%2B2XoplwGtQgxeRvUSW0%2FwdqH1GvoSlI8hl6g7QisttrfBeqQX4YWPgf1FWJyDNR7TvckVhUpdRg6HdQ1bvG4Y12o7QSslq73oyX%2BGXoIVlePL8F0QxDuxKrkPqQOQ9%2BLlezx93rV4xqRqX17UBf9M7QQBHWeCbSmBeO4Uu3pXXNKsUrIYlhYRpLkOXQbz7vQt0Ad1LYb1iHnVO%2FFfqxh%2Fhk6FbAq%2BAPrvPPtueGA9RfVnaah59DCMaydPOz0U7FKWOt62T3PJnYQ7hyZfhlayMfbZdJqfpWagUQYugALtjl9S8I47zmO2gjGfuh0FD%2BYPtvjrq0QRQ5iEqAMN0G6mCcONWvlDG3dbb43egBcT%2BqJWPCafd4Y8b%2Foyuka%2B6E7UOwkyBrTdze9PQsXEtQ%2F6YnY0IjZFNmDgW94CjEZTHHEBHlTB91u%2BtsQM%2FUbVJj36Gt%2BqoIo1ms%2Fi9NYUEw%2FhNkAQIY%2Fv0DTiVzGMJps2iExSgqPMpknCJBCEmLSh%2FFMZgTpNDJtY%2FJZyga2spFXGKr9SIoYhfwXh%2F6nHToQAQAAAADkb73IbXCjR49u9OhGjx7d6NGNHj260aMbPXp0o0c3evToRo8OZGoOg%2BFHUXQAAAAASUVORK5CYII%3D",<br />
"title": "Mozilla%20Foundation"<br />
}<br />
]<br />
}<br />
<br />
=== JSON Format ===<br />
<br />
The Tile JSON format is a simple object, the top level needs to be a locale that Firefox understands. This object allows you to offer multiple locales in a single JSON file.<br />
<br />
At a high level the data object looks like this:<br />
<br />
{ "LOCALE" : [ ARRAY OF DEFAULT TILE OBJECTS ] }<br />
<br />
You can have many locales in the Tiles dictionary object to support multiple languages.<br />
<br />
For example:<br />
<br />
{ "en-US" : [ ARRAY OF US DEFAULT TILES ], "en-CA" : [ ARRAY OF CA DEFAULT TILES ] }<br />
<br />
Each Default Tile object requires a few attributes, most of which are self explanatory.<br />
<br />
{<br />
"url" : "http://www.mozilla.org/",<br />
"bgColor" : "%234d4e54",<br />
"type": "custom",<br />
"imageURI": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAALQAAABWCAQAAADMSHQwAAAFWklEQVR4AezBgQAAAACAoP2pF6kCAAAAAAAAAABgdu0sNqoyDOP4C1WWgCylKgqKoNRCqaxCiyx2bBGNAVrCJkRkUYFAMEGNVUjYRIIIuAYlBqKAUSBcWEUIBlDCBRU6pKINCAUU0CibbSyL9e%2FNmTdvpudMF2ZGj5nfc%2FcwyZCH6Xd6DlMXTGUbe1jEjYhJMgEK2M5WGiDYZDCJ1QTJRWId4f%2BTDwkpoanT5bKXcgDgEqJpyFrKCJmWGLr2ycNa4rQzQf1OY0RzFdTziaFrn41Yh%2FQTjSqnBaLZA2puYujaZy3Wt06bBepPkhFNIaj5iaFrn4FY0522F3boNohmE6gFiaHrkvmEbNQuw3PoDYlPdP0zmOWsYoRpunkOvT4xdDTj%2F6FpS3vESTo5ZNMBwaYBGeQQIBWJmNsZRB7DybJD1DvN6EE%2BraM0dGdyGct4HiMj3kM3pzdz%2BIzLnEIQ5lJKyC6ynVfdxFJOEPKd52%2Bqk9jNNUIq2MYYBJtxlNSQxc4%2F64t8ykEuAJB63UNns5ojWMdZRqv4DV0IahL7CTcN4UHOEO5rkhBsulOEm13Yn40CalKIICRhdbiOoZOYQRHufqFvvIZeTkgV7t7F3TLEpD%2FeLtIRcTKLmqxz5vk5KkM%2FQxmRXCU5PkPnUF%2BXzGf6VqqI5FeaOK98mer%2BxiqM6tDvUJMV8Rm6J%2BH28T5bwKXfQDHWPYiTHVgvkEZXXsLarJejMdiMJkAp1uyoDi2UgSpiDSvYjPV9fIZOw%2FqS3k6%2FAmunnmU%2Fgsp0uj5YeYiT8Vg9ENf0ohLUbiTKQ%2Fd1Xr2ENO2mgDpHo3gM3RnUAdMPAPWx6T8CNdDlAVAQMTkC9ux1STusq7SK%2BtDCVnbQLqyrJKSClvEYOhXUF6bPBDXd9B9UGzqJS56XyJWgziIuOYyVh8RgaLecJKQ8%2FkPvMn0WqHkeT9UGuJzyTyMm07A6IWFZhbUFifHQN9OF%2B%2BlPFmcJuUCzf3Po%2Fh5Dr6s29ONYwxCTfKyHEGyGYl0gKYZDj2U9pVRS3W808cfQz2IFIkyZj5i0oBJrEBKjoUdxFG9nuMEfQxdEmGsI1mjEZC%2FW60iMhp5HZKdo4I%2Bh50Q4Hh7Bsg88n8MqRWI0dIBwFfzECXOTdBzxx9ATI5zRo7AGYx%2FgWx1jNvRhrJX0ozUNSeEKIUf9MvQDWFMQk5lYd2h%2FGmsWEqOhO2EtNteHKkIO%2B2XoplwGtQgxeRvUSW0%2FwdqH1GvoSlI8hl6g7QisttrfBeqQX4YWPgf1FWJyDNR7TvckVhUpdRg6HdQ1bvG4Y12o7QSslq73oyX%2BGXoIVlePL8F0QxDuxKrkPqQOQ9%2BLlezx93rV4xqRqX17UBf9M7QQBHWeCbSmBeO4Uu3pXXNKsUrIYlhYRpLkOXQbz7vQt0Ad1LYb1iHnVO%2FFfqxh%2Fhk6FbAq%2BAPrvPPtueGA9RfVnaah59DCMaydPOz0U7FKWOt62T3PJnYQ7hyZfhlayMfbZdJqfpWagUQYugALtjl9S8I47zmO2gjGfuh0FD%2BYPtvjrq0QRQ5iEqAMN0G6mCcONWvlDG3dbb43egBcT%2BqJWPCafd4Y8b%2Foyuka%2B6E7UOwkyBrTdze9PQsXEtQ%2F6YnY0IjZFNmDgW94CjEZTHHEBHlTB91u%2BtsQM%2FUbVJj36Gt%2BqoIo1ms%2Fi9NYUEw%2FhNkAQIY%2Fv0DTiVzGMJps2iExSgqPMpknCJBCEmLSh%2FFMZgTpNDJtY%2FJZyga2spFXGKr9SIoYhfwXh%2F6nHToQAQAAAADkb73IbXCjR49u9OhGjx7d6NGNHj260aMbPXp0o0c3evToRo8OZGoOg%2BFHUXQAAAAASUVORK5CYII%3D",<br />
"title": "Mozilla%20Foundation"<br />
}<br />
<br />
'''NOTE''': You need to URL escape all the text, in the bgColor you'll see the # is replaced with %23 and the spaces are replaced with %20 in the title.<br />
<br />
''Default Tiles Object Attributes''<br />
<br />
* '''url''' is the URL you want the Tile to link to<br />
* '''bgColor''' provides a background fill color in case the image doesn't fill the space<br />
* '''type''' isn't needed for custom tiles so please use the 'custom' attribute<br />
* '''imageURI''' provides the full URL to the image you want centered. Images need to be properly sized for the Tiles.<br />
* '''title''' provides the display text that will appear below the Tile and for the link title attribute.<br />
* '''enhancedImageURI''' provides the full URL to the roll over image you want centered. Images need to be properly sized for the Tiles. If included a "Roll Over" image will be the image seen until a user mouses over the Tile, on mouse over the imageURI is then shown.<br />
<br />
==== Source Code ====<br />
<br />
*Firefox<br />
**http://mxr.mozilla.org/mozilla-central/source/browser/base/content/newtab/<br />
**https://mxr.mozilla.org/mozilla-central/source/toolkit/modules/NewTabUtils.jsm<br />
Firefox code related to the new tab page that powers Tiles.<br />
<br />
* Onyx<br />
** https://github.com/mozilla/onyx<br />
Onyx is a link server and engagement metrics aggregator for Firefox Tiles handling the delivery and receiving the metrics of Tiles via 3 data endpoints.<br />
<br />
* Infernyx<br />
** https://github.com/mozilla/infernyx<br />
Infernyx contains the rules to extract the metrics data and handles the immediate data processing of raw received data into aggregate data.<br />
<br />
* Splice <br />
** https://github.com/mozilla/splice<br />
Splice is our ingestion, validation, and authoring tool that makes sure tiles are processed, then published to the correct locale and country for Firefox users. It also contains the schemas for the metrics data.</div>Pfinchhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2014-01-27&diff=902341WeeklyUpdates/2014-01-272014-01-22T14:42:30Z<p>Pfinch: /* Introducing New Hires */</p>
<hr />
<div><br />
{{WeeklyUpdateNav}}<br />
{{conf|8600}}<br />
<br />
__TOC__<br />
<br />
= All-hands Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live all-hand status meeting.<br />
<br />
== Friends of Mozilla [[Image:Tree.gif|Friends of Mozilla]] ==<br />
* Webmaker community nominates Kim Wilkens, an active Webmaker contributor and the founder of [http://tech-girls.org Tech Girls] for her valuable feedback on the [https://wiki.mozilla.org/Webmaker Webmaker team's 2014 plans].<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===<br />
<br />
=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
== Project Status Updates (voice updates) ==<br />
<br />
=== Firefox Desktop ===<br />
''Speaker Location:''<br />
<br />
=== Firefox Mobile ===<br />
''Speaker Location:'' <br />
<br />
=== Firefox OS ===<br />
''Speaker Location:''<br />
<br />
=== [https://webmaker.org/ Webmaker] ===<br />
''Speaker Location:''<br />
<br />
=== [https://openbadges.org/ Open Badges] ===<br />
''Speaker Location:''<br />
<br />
=== [https://mozillascience.org/ Mozilla Science Lab] ===<br />
''Speaker Location:''<br />
<br />
=== Mozilla Reps ===<br />
''Speaker Location:''<br />
<br />
=== Grow Mozilla ===<br />
''Speaker Location:''<br />
<br />
=== Identity ===<br />
''Speaker Location:''<br />
<br />
=== Services ===<br />
''Speaker Location:''<br />
<br />
=== Firefox Marketplace ===<br />
''Speaker Location:''<br />
<br />
=== IT ===<br />
''Speaker Location:'' <br />
<br />
== Speakers ==<br />
<br />
The limit is 3 minutes per speaker. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week.<br />
<br />
{| class="fullwidth-table"<br />
|-<br />
! Presenter<br />
! Title<br />
! Topic<br />
! Location<br />
! Share?<br />
! Media<br />
! More Details<br />
|-<br />
| Who Are You?<br />
| What Do You Do?<br />
| What are you going to talk about?<br />
| Where are you presenting from? (Moz Space, your house, space)<br />
| Will you be sharing your screen? (yes/no, other info)<br />
| Links to slides or images you want displayed on screen<br />
| Link to where audience can find out more information<br />
|-<br />
|}<br />
<br />
= Roundtable =<br />
<br />
Do you have a question about a Mozilla Project or initiative? Let us know by Friday- we'll do our best to get you an answer.<br />
<br />
Please note that we may not always be able to get to every item on this list, but we will try!<br />
<br />
{| class="fullwidth-table"<br />
|-<br />
! Who are you?<br />
! Area of question<br />
! Question<br />
|-<br />
| ''What's your name? What do you work on?''<br />
| ''Is your question about policy, a product, a Foundation initiative, etc.''<br />
| ''What would you like to know?''<br />
<!-- Insert new rows here --><br />
|-<br />
|}<br />
<br />
= Welcome! =<br />
<br />
Let's say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.<br />
<br />
== Introducing New Volunteers ==<br />
{| class="fullwidth-table"<br />
|-<br />
! New Volunteer(s)<br />
! Introduced by<br />
! Speaker location<br />
! New Volunteer location<br />
! Will be working on<br />
|-<br />
| ''Who is the new volunteer(s)?''<br />
| ''Who will be introducing that person?''<br />
| ''Where is the introducer?''<br />
| ''Where is the new person based?''<br />
| ''What will the new person be doing?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
|}<br />
<br />
== Introducing New Hires ==<br />
{| class="fullwidth-table"<br />
|-<br />
! New Hire<br />
! Introduced by<br />
! Speaker location<br />
! New Hire location<br />
! Will be working on<br />
|-<br />
| ''Who is the new hire?''<br />
| ''Who will be introducing that person?''<br />
| ''Where is the introducer?''<br />
| ''Where will the new person be working from?''<br />
| ''What will the new person be working on?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
| Rina Jensen<br />
| Patrick Finch<br />
| San Francisco<br />
| London Office<br />
| Content Strategist<br />
|-<br />
|}<br />
<br />
== Introducing New Interns ==<br />
{| class="fullwidth-table"<br />
|-<br />
! New Intern<br />
! Introduced by<br />
! Speaker location<br />
! New Hire location<br />
! Will be working on<br />
|-<br />
| ''Who is the new intern?''<br />
| ''Who will be introducing that person?''<br />
| ''Where is the introducer?''<br />
| ''Where will the new person be working from?''<br />
| ''What will the new person be working on?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
|}<br />
<br />
= &lt;meta&gt; =<br />
<br />
Notes and non-voice status updates that aren't part of the live meeting go here.<br />
<br />
== Status Updates By Team (*non-voice* updates) ==<br />
<br />
=== Firefox ===<br />
<br />
=== Platform ===<br />
<br />
=== Services ===<br />
<br />
=== Messaging ===<br />
<br />
=== Mobile ===<br />
<br />
=== IT ===<br />
<br />
=== Release Engineering ===<br />
<br />
=== QA ===<br />
<br />
==== Test Execution ====<br />
<br />
==== WebQA ====<br />
<br />
==== QA Community ====<br />
<br />
=== Automation & Tools ===<br />
<br />
=== Security ===<br />
<br />
=== Engagement ===<br />
<br />
==== PR ====<br />
<br />
==== Events ====<br />
<br />
==== Social Support ====</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Summit2013/Sessions/Saturday&diff=719537Summit2013/Sessions/Saturday2013-10-02T08:39:36Z<p>Pfinch: /* Strategies of industry players and competing effectively */</p>
<hr />
<div>==1:30 - 3:30pm==<br />
<br />
===Practicing Open===<br />
<br />
Location:<br />
:Brussels: Studio 313/315<br />
:Toronto: Windsor West<br />
:Santa Clara: Prospector Suite B<br />
<br />
Track: Purpose and Strategy<br />
<br />
How can "working open" grow community and bring new contributors to our mission? When there's a conflict between openness and bushinesses requirements, how should we, as individuals, navigate that? What resources do we have available for guidance and help?<br />
<br />
Facilitators:<br />
:Toronto: Lawrence Kissuki, David Humphrey, Matthew Thompson<br />
:Brussels: Ioana Chiorean<br />
:Santa Clara: Sakina Groth<br />
<br />
Session Etherpad: http://mzl.la/17ZwUmQ<br />
<br />
===Mozilla: Winning the Next Three Years===<br />
<br />
Location:<br />
:Brussels: Hall 300<br />
:Toronto: Conference B<br />
:Santa Clara: Grand Ballroom Salon AB<br />
<br />
Track: Purpose and Strategy<br />
<br />
What does Mozilla need to be doing right now, to move the web forward, to do right by our users, and what are the most important factors to consider in planning the next three years?<br />
<br />
Facilitators:<br />
:Brussels: David Ascher<br />
:Toronto: Mark Surman, Armen Zambrano<br />
:Santa Clara: Brendan Eich<br />
<br />
Session Etherpad: http://mzl.la/17ZwWuP<br />
<br />
===Building a Framework to enable Mozilla to effectively communicate across our community===<br />
<br />
Location:<br />
:Brussels: The Arc<br />
:Toronto: Willow Room Centre<br />
:Santa Clara: Grand Ballroom Salon CD<br />
<br />
Track: People and Process<br />
<br />
How does Mozilla hold a discussion on a particular topic that allows expression of positives and negatives in a productive way? This session will build the Mozilla Framework for how to invite feedback, manage the conversation and ensure all parties are acknowledged regardless of their view of the issue.<br />
<br />
Facilitators: <br />
:Brussels:[https://mozillians.org/u/gerv/ Gervase Markham]<br />
:Toronto: [https://mozillians.org/en-US/u/LDeCoursy/ Lainie Decoursy], [https://mozillians.org/en-US/u/feer56/ Andrew (feer56)], [https://mozillians.org/en-US/u/Kensie/ Majken Connor] <br />
:Santa Clara: [https://mozillians.org/en-US/u/Mardi/ Mardi Douglass], [https://mozillians.org/en-US/u/echardac/ Emily Chardac], William Quiviger<br />
<br />
Session Etherpad: http://mzl.la/17ZwWeu<br />
<br />
===Defining and Packaging a Mozilla Core experience for onboarding===<br />
<br />
Location:<br />
:Brussels: Studio 201 A+B<br />
:Toronto: Conference C<br />
:Santa Clara: Grand Ballroom Salon E<br />
<br />
Track: People & Process<br />
<br />
How do we create an experience that captures the history of Mozilla, our values, and what makes us unique in a way that we can transfer these items to new Mozillians and even our partners?<br />
<br />
Facilitators:<br />
:Brussels: [https://mozillians.org/u/nukeador/ Rubén Martín [:Nukeador]] (one of the Mozilla Hispano mentors that runs the onboarding process for new contributors), Tobias Leingruber<br />
:Toronto: Amie Tyrrel, Amira Dhalla<br />
:Santa Clara: [https://mozillians.org/en-US/u/ankitgadgil/ Ankit Gadgil] {{NeedCoFacilitator}}<br />
<br />
Session Etherpad: http://mzl.la/17Zx1Pf<br />
<br />
===What would a million Mozillians do?===<br />
<br />
Location:<br />
:Brussels: Studio 311/312<br />
:Toronto: Conference D&E<br />
:Santa Clara: Seattle<br />
<br />
Track: Purpose & Strategy<br />
<br />
Working Narrative: A creative, "blue sky" session to imagine new kinds of contributors<br />
<br />
Facilitators: <br />
:Brussels: [https://mozillians.org/u/kinger/ Brian King] (Community Manager for Europe), [https://mozillians.org/u/henx/ Henrik Mitsch], [https://mozillians.org/u/nethahussain/ Netha Hussain], [https://mozillians.org/u/thornet/ Michelle Thorne], [https://mozillians.org/u/FuzzyFox/ William Duyck]<br />
:Toronto: Marc Lesser, [https://mozillians.org/u/margaretschroeder/ Margaret Schroeder], [https://mozillians.org/en-US/u/MRomaine/ Melissa Romaine] (en Español)<br />
:Santa Clara: [https://mozillians.org/u/davidwboswell/ David Boswell] and [https://mozillians.org/u/williamq/ William Quiviger]<br />
<br />
Session Etherpad:http://mzl.la/1enxmmc<br />
<br />
===Developing empathy for your users===<br />
<br />
Location:<br />
:Brussels: Studio 213/215<br />
:Toronto: Conference G<br />
:Santa Clara: Portland<br />
<br />
Track: Product & Technology<br />
<br />
A workshop where you learn how to easily make sure that the products you make are as appreciated as you think they should be.<br />
<br />
Facilitators:<br />
:Brussels: [https://mozillians.org/en-US/u/lco/ Larissa Co] , Maureen Hanratty<br />
:Toronto: Cori Schauer<br />
:Santa Clara: [https://mozillians.org/en-US/u/lkenzig/ Lindsay Kenzig], Maria Sandberg<br />
<br />
Session Etherpad: http://mzl.la/1enxqlU<br />
<br />
===Understanding the Servo strategy===<br />
<br />
Location:<br />
:Brussels: Studio 211/212<br />
:Toronto: Willow Room East<br />
:Santa Clara: Newport Beach<br />
<br />
Track: Product & Technology <br />
<br />
Web browsers were designed around yesterday's reality of computer hardware. Servo is a rethinking of the architecture of browsers to accommodate the hardware of today and tomorrow: multiple CPU's and powerful GPU's, and with limited power consumption. What's more, Servo is being built in [http://en.wikipedia.org/wiki/Rust_%28programming_language%29 Rust], a new programming language designed to support faster and safer development practices.<br />
<br />
Facilitators:<br />
:Brussels: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]<br />
:Toronto: [https://mozillians.org/en-US/u/metajack/ Jack Moffitt]<br />
:Santa Clara: Patrick Walton<br />
<br />
Session Etherpad: http://mzl.la/17Zx5yz<br />
<br />
===Growing Stakeholders in the Web===<br />
<br />
Cancelled. Will be replaced with an open session.<br />
<br />
==4:00 - 6:00pm==<br />
<br />
===Imagining a Mozilla-Wide Open Badges System + OBI 101===<br />
<br />
Location:<br />
:Brussels: Studio 313/315<br />
:Toronto: Conference F on the Mezzanine Level <br />
:Santa Clara: Prospector B<br />
<br />
Track: Product and Technology<br />
<br />
Working Narrative: <br />
<br />
The Open Badges Infrastructure makes learning and credentialing work like the Web. Through digital badges, we can build an ecosystem of open learning with stackable, information-based credentials. Open Badges can be used for recognizing and communicating skills and achievements, building reputation and community, and finding peers and hires. <br />
<br />
In this session, we'll provide a brief badges 101 and then explore the opportunity for Mozilla badges for the global community of Mozillians. Together we'll ask: What badges would prove compelling to contributors, staff and community members? What needs to be built and provided to support this large, cohesive system? What are immediate next steps for making these badges real and recognizable? Is now the right time for a Mozilla-wide badge system? <br />
<br />
Facilitators:<br />
:Brussels: [https://mozillians.org/en-US/u/timriches Tim Riches], [https://mozillians.org/en-US/u/emgollie// Emily Goligoski]<br />
:Toronto: [https://mozillians.org/en-US/u/megan Meg Cole], [https://mozillians.org/en-US/u/erin/ Erin Knight], [https://mozillians.org/en-US/u/kerri Kerri Lemoie], [https://mozillians.org/en-US/u/Damian Damian Ewens]<br />
:Santa Clara: [https://mozillians.org/en-US/u/threeqube/ Sunny Lee], [https://mozillians.org/en-US/u/carlacasilli/ Carla Casilli]<br />
<br />
Session Etherpad: http://mzl.la/1enyN3W<br />
<br />
===Designing for our users not ourselves===<br />
<br />
Location:<br />
:Brussels: The Arc<br />
:Toronto: Willow Room East<br />
:Santa Clara: Grand Ballroom Salon CD<br />
<br />
Track: Product & Technology<br />
<br />
Introduction to our users - who they are, what they do, what they need, and how Mozilla can do this.<br />
<br />
Facilitators:<br />
:Cori Schauer will be main facilitator for this, and will coordinate the other facilitators. <br />
:Brussels: [https://mozillians.org/en-US/u/gpetrie/ Gemma Petrie] & Madhava Zhenshuo & [https://mozillians.org/en-US/u/dstrohmeier/ Dominik Strohmeier]<br />
:Toronto: Cori Schauer, [https://mozillians.org/en-US/u/clarkbw/ Bryan Clark] (possibly Gregg Lind) <br />
:Santa Clara: Bill Selman<br />
<br />
Session Etherpad: http://mzl.la/1enxtOr<br />
<br />
===Strategies of industry players and competing effectively===<br />
<br />
Location:<br />
:Brussels: Hall 300<br />
:Toronto: Willow Room Centre<br />
:Santa Clara: Grand Ballroom Salon AB<br />
<br />
Track: Product & Technology<br />
<br />
Powerful interests are creating silos of content and private walled gardens on the web. What can Mozilla do to open these silos up or create new more open alternatives? How do we need to understand how these competitors work for markets and consumers?<br />
<br />
Facilitators: <br />
:Brussels: [https://mozillians.org/en-US/u/pfinch/ Patrick Finch] {{NeedCoFacilitator}}<br />
:Toronto: [https://mozillians.org/en-US/u/kev/ Kev Needham], John Jensen<br />
:Santa Clara: Irina Sandu, Ria Joy, Sandip Kamat<br />
<br />
Session Etherpad:http://mzl.la/1enxOko<br />
<br />
===Understanding web developers===<br />
<br />
Location:<br />
:Brussels: Studio 213/215<br />
:Toronto: Conference D&E<br />
:Santa Clara: Santa Barbara<br />
<br />
Track: Product & Technology<br />
<br />
Web developers are a key community for Mozilla. Our competitors are building sophisticated developer tools, API's, and platform technologies. How can we maintain a close and symbiotic relationship with web developers? How do we meet their needs, and how do we get them signed up for Mozilla's mission?<br />
<br />
Facilitators: <br />
:Brussels: Jeff Griffiths<br />
:Toronto: Stormy Peters<br />
:Santa Clara: Christian Heilmann<br />
<br />
Session Etherpad: http://mzl.la/1enxVMI<br />
<br />
===How do we scale up our innovation capacity?===<br />
<br />
Location:<br />
:Brussels: Studio 311/312<br />
:Toronto: Conference C<br />
:Santa Clara: Seattle<br />
<br />
Track: Product and Technology<br />
<br />
If we're to have the kind of massive impact on the internet that we hope to, we have to ask ourselves whether our structure and processes will get us there. If we want to facilitate innovation at the edges and focus on recognizing good ideas rather than having them, how should we relate to web innovators around the world?<br />
<br />
Facilitators:<br />
:Brussels: David Ascher<br />
:Toronto: Simon Wex <br />
:Santa Clara: Robert Richter<br />
<br />
Session Etherpad: http://mzl.la/1enxJ00<br />
<br />
===We're building a global movement of Webmakers: Join us===<br />
<br />
Location:<br />
:Brussels: Studio 201 A+B<br />
:Toronto: Conference B<br />
:Santa Clara: Grand Ballroom Salon E<br />
<br />
Track: Product and Technology<br />
<br />
Webmaker is the brand that we're using to show a new generation of web citizens that the web is theirs to grab, shape and remix. We'll show you what that looks like with an ad hoc maker party. Come learn to build web pages and multimedia with Mozilla's awesome Webmaker tools. Or if you have skills to share, learn to be a Webmaker mentor. <br />
<br />
Facilitators: <br />
<br />
:Brussels: [https://mozillians.org/en-US/u/codekat/ Kat Braybrooke], [https://mozillians.org/u/thornet/ Michelle Thorne]<br />
:Toronto: Chris Lawrence, Amira Dhalla, Matt Thompson<br />
:Santa Clara: Brett Gaylor, [https://mozillians.org/en-US/u/ankitgadgil/ Ankit Gadgil], Jacob Caggiano, Yoe One Ariestya Niovitta <br />
<br />
Session Etherpad:http://mzl.la/1enxYYR</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Summit2013/Sessions&diff=711979Summit2013/Sessions2013-09-19T21:07:14Z<p>Pfinch: /* How people see our markets and how we compete effectively in them */</p>
<hr />
<div>=What are Supporting Sessions?=<br />
<br />
[https://wiki.mozilla.org/Summit2013/FAQ#What_are_.E2.80.9CSupporting_Sessions.E2.80.9D_and_how_did_they_get_on_the_agenda.3F Link to the general FAQ]<br />
<br />
=Call for Facilitators=<br />
<br />
We need facilitators for the supporting sessions! Anyone can be a facilitator. Here is the list of sessions currently on the agenda for the Mozilla Summit 2013, with facilitators at each location. More information on expectations of facilitators can be found on the [https://wiki.mozilla.org/Summit2013/Sessionfacilitators Session Facilitators wiki]. <br />
<br />
Each proposed session has its own etherpad for discussion and description, if you click through to it. Please add to that pad if you want to suggest specific questions to be addressed within the session.<br />
<br />
Also note there will be open sessions on site which can be signed up for when we are at the summit, "Unconference" style. For more information about how to sign-up to host an open session, please see our [https://wiki.mozilla.org/Summit2013/FAQ FAQ].<br />
<br />
=How to Sign-up?=<br />
Please note that the deadline to sign-up has now passed. If you would like to help facilitate a session, please reach out directly to the named session facilitator.<br />
<br />
=Can I Co-facilitate?=<br />
<br />
In general, if you want to Co-facilitate a session, it is frequently possible, reach out to the track owner or to the facilitators themselves.<br />
<br />
=Who are the Track Owners?=<br />
<br />
[[https://wiki.mozilla.org/Summit2013/TrackOwners Track Owners]] for the Summit Are:<br />
<br />
:Mike Hoye (irc: mhoye), People and Process Track, office hours: 2-3 PM Eastern (6-7 PM UTC)<br />
:[[https://mozillians.org/en-US/u/lmandel/ Lawrence Mandel]] (irc: lmandel), Purpose and Strategy Track, office hours: Monday and Tuesday 11-12am Eastern Time.<br />
:[[https://mozillians.org/en-US/u/lshapiro/ Larisa Shapiro]] (irc: lshapiro), Product and Technology Track (and the Innovation Fair) office hours: M-W-F 9-10am Pacific Time<br />
<br />
You can also reach us at:<br />
:IRC: #mozsummit<br />
:Vidyo (during office hours): Summit Track Owners room<br />
<br />
Can't meet during the designated office hours? No problem. Just ping us and we'll set up an alternate time just for you. :)<br />
<br />
Don't know who to reach out to? [https://etherpad.mozilla.org/2013supportingsessions Here] is a list of sessions as they align with the Tracks.<br />
<br />
=Deadline to Sign-up=<br />
<br />
'''Please note that the deadline to sign-up has now passed. If you would like to help facilitate a session, please reach out directly to the named session facilitator.'''<br />
<br />
=Any Questions?=<br />
<br />
If you have any additional questions, please feel free to reach out to a Track Owner or read through our [https://wiki.mozilla.org/Summit2013/FAQ FAQ].<br />
<br />
<br />
<br />
==Friday==<br />
<br />
===Ecosystems in our Image===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
Put practically and short term: how our values show up in the app ecosystem or social network (where the users are now). And, in the long term, how do our values show up in big data, internet of things and other upcoming ecosystems.<br />
What would it look like to build a mobile apps and content ecosystem based literally on the ideas in the Nature of Mozilla? What features and marketing approaches would you include? How would we most effectively balance building, teaching and shaping markets? Where do local communities fit in as part of building this? Can they help build a long tail app ecosystem where we really see local diversity?<br />
<br />
Facilitators:<br />
:Brussels: David Ascher, Bill Maggs<br />
:Toronto: Chris Lawrence, Ben Moskowitz<br />
:Santa Clara: Alina Mierlus, Erika Owens<br />
<br />
Session Etherpad: http://mzl.la/1ent7a9<br />
<br />
===The Web We Want===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
A large, interactive session to explore the web we're championing.What do we mean by "the web"? Is it a technology? A set of values? (also, how is it different from the Internet?) What are the baseline design principles we value most? Privacy? Creativity? User freedom? User Control? Data ownership? Something else? How is the web part of our identity? How do we use our products and our voice to help the broader world--including users--understand the web and become champions with us? <br />
<br />
Facilitators:<br />
:Santa Clara: Asa Dotzler, [[User:Tantek|Tantek Çelik]]<br />
:Brussels: [https://mozillians.org/en-US/u/lco/ Larissa Co], [[User:Aking|Ozten]], [[User:AlisonW|AlisonW]]<br />
:Toronto: Potch, [https://mozillians.org/en-US/u/firetoad/ Mike Collins], Dan Sinker<br />
<br />
Session Etherpad: http://mzl.la/15nyhNz<br />
<br />
Afterwards:<br />
* I've proposed an [[IndieWeb]] Hackspace on the [[Summit2013/Experiences#HackSpaces|Summit2013 Experiences]] wiki page for those that want to actively hack on their own websites and create the web we want by example. - [[User:Tantek|Tantek]] ([[User talk:Tantek|talk]])<br />
<br />
===Building a Web Literate World===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
The Webmaker Community is changing the face of education through collaborative, participatory events, kick ass tools and relevant learning activities for creativity and learning. At the same time, they're building a more Web Literate world by helping people understand that you don't have to be a programmer to understand the technical and social infrastructures of the Web.<br />
<br />
In this session, we'll play games and discuss how building a web literate world is integral to everything we do, not just as Mozilla, but as people. We'll discuss how Mozilla is making this not only possible - but easily accessible through open tools, learning activities, invitations to participate in the discussions, guidance and direction and invention, innovation and inspiration. And we'll prototype ways for you to get involved.<br />
<br />
Facilitators: <br />
*Toronto: Julia Vallera, Emma Irwin<br />
*Santa Clara, Sandraghassen Subbaraya Pillai, Ankit Gadgil, Vineel Reddy Pindi, [https://mozillians.org/en-US/u/Ben/ Benny Chandra], Faye Tandog, Christos Bacharakis, Lawrence Kisuuki<br />
*Brussels: Ibrahima SARR, [https://mozillians.org/en-US/u/LauraHilliger/ Laura Hilliger]<br />
<br />
Session Etherpad: http://mzl.la/17ZwqNo<br />
<br />
===What does "Mozillian" mean?===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
A hands-on session to define the identity of Mozillians, historically and as we evolve. Towards building scope and identity as a community. Consider new domains, like news and science. Do partners count? Who do we count? What are we trying to build? Who are we inviting?<br />
<br />
Facilitators: <br />
:Brussels: [https://mozillians.org/u/gerv/ Gervase Markham], Ioana Chiorean<br />
:Toronto: Guillermo Movia, [https://mozillians.org/en-US/u/feer56/ Andrew (feer56)- Will do second session @2:45]<br />
:Santa Clara: Sujith Reddy (would like co facilitator), Alex Lakatos<br />
<br />
Session Etherpad: http://mzl.la/15nymAM<br />
<br />
===Firefox OS in 2014 and Beyond===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Product and Technology<br />
<br />
The strategy and vision for what Firefox OS is trying to accomplish, what markets it's heading for, as well as showcasing the technology and features.<br />
<br />
Facilitators:<br />
:Brussels: Chris Lee, Bill Maggs <br />
:Toronto: [https://mozillians.org/en-US/u/pdolanjski/ Peter Dolanjski], Vik Iya<br />
:Santa Clara: Sandip Kamat, Christian Heilmann<br />
<br />
Session Etherpad: http://mzl.la/17Zws7Y<br />
<br />
===Privacy, Security, and Data: Pragmatic Innovations for Users and the Web===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Product and Technology<br />
<br />
A discussion on how we combine our desire for excellent products, services and UX with leading privacy and security characteristics that advance trust, sustainability and safety for people.<br />
<br />
Facilitators:<br />
:Brussels: Stacy Martin / Garrett Robinson / Simon Bennetts<br />
:Toronto: Alex Fowler / Monica Chew / Yvan Boily<br />
:Santa Clara: Alina Hua / Sid Stamm / Joe Stevenson<br />
<br />
Session Etherpad: http://mzl.la/17Zwvki<br />
<br />
===Building through Brand===<br />
<br />
Friday, 1:00 - 2:15pm, 2:45 - 4:00pm<br />
<br />
Track: Purpose and Strategy<br />
<br />
NEED DESCRIPTION<br />
<br />
Facilitators (Pete Scanlon to coordinate):<br />
:Brussels: Ioana Chiorean, {{NeedCoFacilitator}}<br />
:Toronto: Winston Bowden and Michaela Thayer<br />
:Santa Clara: Sakina Groth, Alex Lakatos<br />
<br />
Session Etherpad: http://mzl.la/17ZwzR0<br />
<br />
==Saturday==<br />
<br />
===Practicing Open===<br />
<br />
Saturday, 1:30-3:30 pm<br />
<br />
Track: Purpose and Strategy<br />
<br />
When there's a conflict between openness and bushinesses requirements, how should we, as individuals, navigate that? What resources do we have available for guidance and help?<br />
<br />
Facilitators:<br />
:Toronto: Lawrence Kissuki, David Humphrey, Matthew Thompson<br />
:Brussels: Ioana Chiorean<br />
:Santa Clara: Sakina Groth<br />
<br />
Session Etherpad: http://mzl.la/17ZwUmQ<br />
<br />
===Mozilla: Winning the Next Three Years===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer, co-facilitators encouraged) <br />
<br />
Track: Purpose and Strategy<br />
<br />
What does Mozilla need to be doing right now, to move the web forward, to do right by our users, and what are the most important factors to consider in planning the next three years?<br />
<br />
Facilitators:<br />
:Brussels: David Ascher<br />
:Toronto: Mark Surman, Armen Zambrano<br />
:Santa Clara: Brendan Eich<br />
<br />
Session Etherpad: http://mzl.la/17ZwWuP<br />
<br />
===Building a Framework to enable Mozilla to effectively communicate across our community===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer, co-facilitators encouraged)<br />
<br />
Track: People and Process<br />
<br />
How does Mozilla hold a discussion on a particular topic that allows expression of positives and negatives in a productive way? This session will build the Mozilla Framework for how to invite feedback, manage the conversation and ensure all parties are acknowledged regardless of their view of the issue.<br />
<br />
Facilitators: <br />
:Brussels:[https://mozillians.org/u/gerv/ Gervase Markham]<br />
:Toronto: Lainie Delcoursy,[https://mozillians.org/en-US/u/feer56/ Andrew (feer56)], [https://mozillians.org/en-US/u/Kensie/ Majken Connor] <br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Etherpad: http://mzl.la/17ZwWeu<br />
<br />
===Defining and Packaging a Mozilla Core experience for onboarding===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer)<br />
<br />
Track: People & Process<br />
<br />
How do we create an experience that captures the history of Mozilla, our values, and what makes us unique in a way that we can transfer these items to new Mozillians and even our partners?<br />
<br />
Facilitators:<br />
:Brussels: Rubén Martín [:Nukeador] (one of the Mozilla Hispano mentors that runs the onboarding process for new contributors), Tobias Leingruber<br />
:Toronto: Amie Tyrrel, Amira Dhalla, Lainie DeCoursy<br />
:Santa Clara: Ankit Gadgil {{NeedCoFacilitator}}<br />
<br />
Session Etherpad: http://mzl.la/17Zx1Pf<br />
<br />
===What would a million Mozillians do?===<br />
<br />
Saturday, 1:30-3:30pm (yes, this is a longer session)<br />
<br />
Track: Purpose & Strategy<br />
<br />
Working Narrative: A creative, "blue sky" session to imagine new kinds of contributors<br />
<br />
Facilitators: <br />
:Brussels: [https://mozillians.org/u/kinger/ Brian King] (Community Manager for Europe), [https://mozillians.org/u/henx/ Henrik Mitsch], [https://mozillians.org/u/nethahussain/ Netha Hussain], [https://mozillians.org/u/thornet/ Michelle Thorne], [https://mozillians.org/u/FuzzyFox/ William Duyck]<br />
:Toronto: Marc Lesser, Margaret Schroeder<br />
:Santa Clara: David Boswell and William Quiviger<br />
<br />
Session Etherpad:http://mzl.la/1enxmmc<br />
<br />
===Developing empathy for your users===<br />
<br />
Saturday, 1:30-3:30 (yes, this one is longer)<br />
<br />
Track: Product & Technology<br />
<br />
A workshop where you learn how to easily make sure that the products you make are as appreciated as you think they should be.<br />
<br />
Facilitators:<br />
:Brussels: [https://mozillians.org/en-US/u/lco/ Larissa Co] , Maureen Hanratty<br />
:Toronto: Cori Schauer<br />
:Santa Clara: Lindsay Kenzig, Maria Sandberg<br />
<br />
Session Etherpad: http://mzl.la/1enxqlU<br />
<br />
===Understanding the Servo strategy===<br />
<br />
Saturday, 1:30 - 3:30pm <br />
<br />
Track: Product & Technology <br />
<br />
Web browsers were designed around yesterday's reality of computer hardware. Servo is a rethinking of the architecture of browsers to accommodate the hardware of today and tomorrow: multiple CPU's and powerful GPU's, and with limited power consumption. What's more, Servo is being built in [http://en.wikipedia.org/wiki/Rust_%28programming_language%29 Rust], a new programming language designed to support faster and safer development practices.<br />
<br />
Facilitators:<br />
:Brussels: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]<br />
:Toronto: Jack Moffitt<br />
:Santa Clara: Patrick Walton<br />
<br />
Session Etherpad: http://mzl.la/17Zx5yz<br />
<br />
===Growing Stakeholders in the Web===<br />
<br />
Saturday, 1:30 - 3:30pm<br />
<br />
Track: Product & Technology<br />
<br />
The success of the internet depends on commercial activity as well as individual self-expression. To make that work means that we need to understand the perspectives of different stakeholders, from phone manufacturers, to phone companies, to media companies, to consumers. <br />
<br />
Facilitators: <br />
:Brussels: Kat Braybrooke, <br />
:Toronto: Marc Lesser<br />
:Santa Clara: Geoffrey MacDougall, Need Co-Facilitator: Irina Sandu?<br />
<br />
Session Etherpad: http://mzl.la/1enxPVs<br />
<br />
===Who are our users in 2018 and where are they?===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology <br />
<br />
Alternate title: What's not going to change in 2018? What motivations our users will still hold in 10-15 years?<br />
<br />
The world is changing, and we need to build products that work for the next billion users. Who are they, and what are they like?<br />
<br />
Facilitators:<br />
:Brussels: Yuan Wang, Mary Trombley<br />
:Toronto: Cori Schauer<br />
:Santa Clara: Jinghua Zhang<br />
<br />
Session Etherpad: http://mzl.la/1enxKkH<br />
<br />
===Designing for our users not ourselves===<br />
<br />
Saturday, 4:00 - 6:00pm (yes, this one is longer) <br />
<br />
Track: Product & Technology<br />
<br />
Introduction to our users - who they are, what they do, what they need, and how Mozilla can do this.<br />
<br />
Facilitators:<br />
:Cori Schauer will be main facilitator for this, and will coordinate the other facilitators. <br />
:Brussels: Gemma & Madhava Zhenshuo & Dominik?<br />
:Toronto: Cori & Bryan Clark (possibly Gregg Lind) <br />
:Santa Clara: Bill Selman<br />
<br />
Session Etherpad: http://mzl.la/1enxtOr<br />
<br />
===Strategies of industry players and competing effectively===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
Powerful interests are creating silos of content and private walled gardens on the web. What can Mozilla do to open these silos up or create new more open alternatives? How do we need to understand how these competitors work for markets and consumers?<br />
<br />
Facilitators: <br />
:Brussels: Patrick Finch {{NeedCoFacilitator}}<br />
:Toronto: Kev Needham, John Jensen<br />
:Santa Clara: Irina Sandu, Ria Joy, Sandip Kamat<br />
<br />
Session Etherpad:http://mzl.la/1enxOko<br />
<br />
===Understanding web developers===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
Web developers are a key community for Mozilla. Our competitors are building sophisticated developer tools, API's, and platform technologies. How can we maintain a close and symbiotic relationship with web developers? How do we meet their needs, and how do we get them signed up for Mozilla's mission?<br />
<br />
Facilitators: <br />
:Brussels: Jeff Griffiths<br />
:Toronto: Stormy Peters<br />
:Santa Clara: Christian Heilmann<br />
<br />
Session Etherpad: http://mzl.la/1enxVMI<br />
<br />
===The Petri Dish required by scaling innovation===<br />
<br />
Saturday, 4-6pm<br />
<br />
Track: Product and Technology<br />
<br />
If we're to have the kind of massive impact on the internet that we hope to, we have to ask ourselves whether our structure and processes will get us there. If we want to facilitate innovation at the edges and focus on recognizing good ideas rather than having them, how should we relate to web innovators around the world?<br />
<br />
Facilitators:<br />
:Brussels: David Ascher<br />
:Toronto: Simon Wex <br />
:Santa Clara: Robert Richter<br />
<br />
Session Etherpad: http://mzl.la/1enxJ00<br />
<br />
===WebMaker: Getting People to Take Back The Web===<br />
<br />
Saturday, 4-6 pm<br />
<br />
Track: Product and Technology<br />
<br />
Webmaker is the brand that we're using to tell a new generation of web citizens that the web is theirs to grab, shape and remix. We'll show you what that looks like, and get you activated to help in that effort!<br />
<br />
Facilitators: <br />
<br />
:Brussels: Kat Braybrooke, Henrik Mitsch, Michelle Thorne<br />
:Toronto: Chris Lawrence, Amira Dhalla, Lyre Calliope, Matt Thompson<br />
:Santa Clara: Brett Gaylor, Ankit Gadgil, Jacob Caggiano, Yoe One Ariestya Niovitta <br />
<br />
Session Etherpad:http://mzl.la/1enxYYR<br />
<br />
==Sunday==<br />
<br />
===Distributed Leadership and decision making===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Purpose and Strategy<br />
<br />
A well-facilitated inquiry and skillshare on distributed leadership. Skills Learned: Leadership, Conflict Resolution, Facilitating distributed meetings/planning/group actions. Potential Outline of Session:<br />
# Nature of Mozilla -- one pillar is human capability; more mozillians moving the mission forward<br />
# history of the huge chunks of mozilla that people made up on on their own and we incorporated into the centralized piece<br />
# Some issues with distributed decision-mkaing: risk, mistakes, surprise, messiness<br />
# What do we do now: how we build more APIs to the centralized part of mozilla? <br />
<br />
Facilitators:<br />
:Brussels: Laura Thomson, Ioana Chiorean<br />
:Toronto: [https://mozillians.org/en-US/u/regnard/ Regnard Raquedan], Lukas Blakk<br />
:Santa Clara: Alina Mierlus, Vineel Reddy Pindi<br />
<br />
Session Etherpad: http://mzl.la/17Zxktf<br />
<br />
===Ideas into Action: Next steps for me and my team===<br />
<br />
Sunday, 1:15-2:30<br />
<br />
Track: Purpose and Strategy<br />
<br />
Four breakout sessions with a joint shareback round. Determine what winning looks like as measured by Mozilla's four pillars of activity. Tools, roadmap and things you can do when you return home. How you can adapt the 3-year plan to your local context and the projects you care about. How you can multiply the mission. Skills Learned: Metrics, Building Open into your Project, How to Identify the NoM in your ideas & highlight/promote/grow those<br />
<br />
Facilitators:<br />
:Brussels: Karen Rudnitski<br />
:Toronto: Larissa Shapiro, Selena Deckelmann<br />
:Santa Clara: [https://mozillians.org/u/ernestchiang/ Ernest Chiang]<br />
<br />
Session Etherpad: http://mzl.la/1enyki5<br />
<br />
===Designing your project for participation===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
Nearly all projects will benefit from community involvement; however, there are different approaches and best practices that can better enable a project for wider contributions. This session will capture best practices and challenges to build a project with community involvement.<br />
<br />
Facilitators:<br />
:Brussels: [https://mozillians.org/en-US/u/LauraHilliger/ Laura Hilliger] (working with Mozilla Reps to help them deliver #teachtheweb professional development content)<br />
:Toronto: David Eaves (creator of the community building workshops that includes a 'Designing your project for participation' module) or Emma Irwin (One of the Mozilla Reps who will be delivering the community building workshop content), Jess Klein <br />
:Santa Clara: Benjamin Kerensa (One of the Mozilla Reps who will be delivering the community building workshop content) and Soumya Deb (Leader in Mozilla India)<br />
<br />
Session Etherpad: http://mzl.la/17Zxm4A<br />
<br />
===Community tools - what do we currently have===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
The topic of tooling seems to be a frequent one. Let's discuss the needs of the various members of the community and determine if there are shared tools in which we as a community should invest.<br />
<br />
Facilitators:<br />
:Brussels: [https://mozillians.org/u/jdm/ Josh Matthews], [https://mozillians.org/u/williamr/ William Reynolds] (members of the Community Building Systems Working Group)<br />
:Toronto: [https://mozillians.org/u/mhoye/ Michael Hoye], [https://mozillians.org/u/r1cky/ Ricky Rosario] (members of the Community Building Systems Working Group)<br />
:Santa Clara: [https://mozillians.org/u/pierros/ Pierros Papadeas] (members of the Community Building Systems Working Group)<br />
<br />
Session Etherpad: http://mzl.la/1enyrua<br />
<br />
===Working with corporate (closed) partners===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
How to stay open at Mozilla while meeting our needs: Creating a shared understanding of how Mozilla can work in a closed environment and a roadmap for introducing open concepts to our partners.<br />
<br />
Facilitators:<br />
*Toronto: Lawrence Mandel, Lukas Blakk, Bhavana Bajaj<br />
*Brussels: Dietrich Ayala, [https://mozillians.org/en-US/u/mcote/ Mark Côté], Chris Lee<br />
*Santa Clara: [https://mozillians.org/en-US/u/cpeterson/ Chris Peterson], Alex Keybl<br />
<br />
Session Etherpad: http://mzl.la/1enywhl<br />
<br />
===Workshop on Contributor recognition guide===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
Workshop to share tips and tricks for how recognize contributors to your project that would cover badges, swag, events and more. Also hack on the draft Recognition Guide at https://wiki.mozilla.org/Contribute/Recognition<br />
<br />
Facilitator:<br />
:Brussels: Michelle Marovich (Lead Recruiter) and Lizz Noonan (Brand Campaign Coordinator/Creative Contribute Community Co-manager)<br />
:Toronto: Jeff Beatty (Community Building for l10n)<br />
:Santa Clara: Rosana Ardila (Community Builder for SUMO)<br />
<br />
Session Etherpad: http://mzl.la/17ZxsJo<br />
<br />
===Moderated discussion on how we will think about product opportunities in the cloud===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
Mozilla has a proud history of championing user control of data, but there are both huge user benefits and competitive pressures to having some cloud-enabled data and services. How should Mozilla approach this problem in a way that pushes the mission forward while being pragmatic to the needs of the market?<br />
<br />
Facilitators: <br />
:Brussels: Lloyd Hilaiel<br />
:Toronto: John Jensen<br />
:Santa Clara: Toby Elliott<br />
<br />
Session Etherpad: http://mzl.la/17ZxrFk<br />
<br />
===The future of web gaming===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
The web is poised to become a platform for games, which opens up opportunities for new markets and independent developers. With WebGL, asm.js, and key web API's like Pointer Lock, Audio, and Video, Mozilla is making the future of web gaming a reality. Find out where we are and join us thinking about where to go from here.<br />
<br />
Facilitators:<br />
:Brussels: Vlad Vukicevic<br />
:Toronto: Martin Best<br />
:Santa Clara: Marco Mucci<br />
<br />
Session Etherpad: http://mzl.la/17Zxu3U<br />
<br />
===Open Badges: How to Encourage Engagement===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
Working Narrative: With OpenBadges, Mozilla has a combination of technology and market-shaping partners which could shift how people engage, get recognized for their skills and contributions, and unlock new opportunities. Learn about OpenBadges and what it's shooting for.<br />
<br />
Facilitators:<br />
:Brussels: Tim Riches, Emily Goligoski<br />
:Toronto: Meg Cole, Kerrie Lemoie, Damian Ewens<br />
:Santa Clara: Sunny Lee, Carla Casilli<br />
<br />
Session Etherpad:http://mzl.la/1enyN3W</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Summit2013/Sessions&diff=711977Summit2013/Sessions2013-09-19T21:06:14Z<p>Pfinch: /* Growing Stakeholders in the Web */</p>
<hr />
<div>=What are Supporting Sessions?=<br />
<br />
[https://wiki.mozilla.org/Summit2013/FAQ#What_are_.E2.80.9CSupporting_Sessions.E2.80.9D_and_how_did_they_get_on_the_agenda.3F Link to the general FAQ]<br />
<br />
=Call for Facilitators=<br />
<br />
We need facilitators for the supporting sessions! Anyone can be a facilitator. Here is the list of sessions currently on the agenda for the Mozilla Summit 2013, with facilitators at each location. More information on expectations of facilitators can be found on the [https://wiki.mozilla.org/Summit2013/Sessionfacilitators Session Facilitators wiki]. <br />
<br />
Each proposed session has its own etherpad for discussion and description, if you click through to it. Please add to that pad if you want to suggest specific questions to be addressed within the session.<br />
<br />
Also note there will be open sessions on site which can be signed up for when we are at the summit, "Unconference" style. For more information about how to sign-up to host an open session, please see our [https://wiki.mozilla.org/Summit2013/FAQ FAQ].<br />
<br />
=How to Sign-up?=<br />
Please note that the deadline to sign-up has now passed. If you would like to help facilitate a session, please reach out directly to the named session facilitator.<br />
<br />
=Can I Co-facilitate?=<br />
<br />
In general, if you want to Co-facilitate a session, it is frequently possible, reach out to the track owner or to the facilitators themselves.<br />
<br />
=Who are the Track Owners?=<br />
<br />
[[https://wiki.mozilla.org/Summit2013/TrackOwners Track Owners]] for the Summit Are:<br />
<br />
:Mike Hoye (irc: mhoye), People and Process Track, office hours: 2-3 PM Eastern (6-7 PM UTC)<br />
:[[https://mozillians.org/en-US/u/lmandel/ Lawrence Mandel]] (irc: lmandel), Purpose and Strategy Track, office hours: Monday and Tuesday 11-12am Eastern Time.<br />
:[[https://mozillians.org/en-US/u/lshapiro/ Larisa Shapiro]] (irc: lshapiro), Product and Technology Track (and the Innovation Fair) office hours: M-W-F 9-10am Pacific Time<br />
<br />
You can also reach us at:<br />
:IRC: #mozsummit<br />
:Vidyo (during office hours): Summit Track Owners room<br />
<br />
Can't meet during the designated office hours? No problem. Just ping us and we'll set up an alternate time just for you. :)<br />
<br />
Don't know who to reach out to? [https://etherpad.mozilla.org/2013supportingsessions Here] is a list of sessions as they align with the Tracks.<br />
<br />
=Deadline to Sign-up=<br />
<br />
'''Please note that the deadline to sign-up has now passed. If you would like to help facilitate a session, please reach out directly to the named session facilitator.'''<br />
<br />
=Any Questions?=<br />
<br />
If you have any additional questions, please feel free to reach out to a Track Owner or read through our [https://wiki.mozilla.org/Summit2013/FAQ FAQ].<br />
<br />
<br />
<br />
==Friday==<br />
<br />
===Ecosystems in our Image===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
Put practically and short term: how our values show up in the app ecosystem or social network (where the users are now). And, in the long term, how do our values show up in big data, internet of things and other upcoming ecosystems.<br />
What would it look like to build a mobile apps and content ecosystem based literally on the ideas in the Nature of Mozilla? What features and marketing approaches would you include? How would we most effectively balance building, teaching and shaping markets? Where do local communities fit in as part of building this? Can they help build a long tail app ecosystem where we really see local diversity?<br />
<br />
Facilitators:<br />
:Brussels: David Ascher, Bill Maggs<br />
:Toronto: Chris Lawrence, Ben Moskowitz<br />
:Santa Clara: Alina Mierlus, Erika Owens<br />
<br />
Session Etherpad: http://mzl.la/1ent7a9<br />
<br />
===The Web We Want===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
A large, interactive session to explore the web we're championing.What do we mean by "the web"? Is it a technology? A set of values? (also, how is it different from the Internet?) What are the baseline design principles we value most? Privacy? Creativity? User freedom? User Control? Data ownership? Something else? How is the web part of our identity? How do we use our products and our voice to help the broader world--including users--understand the web and become champions with us? <br />
<br />
Facilitators:<br />
:Santa Clara: Asa Dotzler, [[User:Tantek|Tantek Çelik]]<br />
:Brussels: [https://mozillians.org/en-US/u/lco/ Larissa Co], [[User:Aking|Ozten]], [[User:AlisonW|AlisonW]]<br />
:Toronto: Potch, [https://mozillians.org/en-US/u/firetoad/ Mike Collins], Dan Sinker<br />
<br />
Session Etherpad: http://mzl.la/15nyhNz<br />
<br />
Afterwards:<br />
* I've proposed an [[IndieWeb]] Hackspace on the [[Summit2013/Experiences#HackSpaces|Summit2013 Experiences]] wiki page for those that want to actively hack on their own websites and create the web we want by example. - [[User:Tantek|Tantek]] ([[User talk:Tantek|talk]])<br />
<br />
===Building a Web Literate World===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
The Webmaker Community is changing the face of education through collaborative, participatory events, kick ass tools and relevant learning activities for creativity and learning. At the same time, they're building a more Web Literate world by helping people understand that you don't have to be a programmer to understand the technical and social infrastructures of the Web.<br />
<br />
In this session, we'll play games and discuss how building a web literate world is integral to everything we do, not just as Mozilla, but as people. We'll discuss how Mozilla is making this not only possible - but easily accessible through open tools, learning activities, invitations to participate in the discussions, guidance and direction and invention, innovation and inspiration. And we'll prototype ways for you to get involved.<br />
<br />
Facilitators: <br />
*Toronto: Julia Vallera, Emma Irwin<br />
*Santa Clara, Sandraghassen Subbaraya Pillai, Ankit Gadgil, Vineel Reddy Pindi, [https://mozillians.org/en-US/u/Ben/ Benny Chandra], Faye Tandog, Christos Bacharakis, Lawrence Kisuuki<br />
*Brussels: Ibrahima SARR, [https://mozillians.org/en-US/u/LauraHilliger/ Laura Hilliger]<br />
<br />
Session Etherpad: http://mzl.la/17ZwqNo<br />
<br />
===What does "Mozillian" mean?===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
A hands-on session to define the identity of Mozillians, historically and as we evolve. Towards building scope and identity as a community. Consider new domains, like news and science. Do partners count? Who do we count? What are we trying to build? Who are we inviting?<br />
<br />
Facilitators: <br />
:Brussels: [https://mozillians.org/u/gerv/ Gervase Markham], Ioana Chiorean<br />
:Toronto: Guillermo Movia, [https://mozillians.org/en-US/u/feer56/ Andrew (feer56)- Will do second session @2:45]<br />
:Santa Clara: Sujith Reddy (would like co facilitator), Alex Lakatos<br />
<br />
Session Etherpad: http://mzl.la/15nymAM<br />
<br />
===Firefox OS in 2014 and Beyond===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Product and Technology<br />
<br />
The strategy and vision for what Firefox OS is trying to accomplish, what markets it's heading for, as well as showcasing the technology and features.<br />
<br />
Facilitators:<br />
:Brussels: Chris Lee, Bill Maggs <br />
:Toronto: [https://mozillians.org/en-US/u/pdolanjski/ Peter Dolanjski], Vik Iya<br />
:Santa Clara: Sandip Kamat, Christian Heilmann<br />
<br />
Session Etherpad: http://mzl.la/17Zws7Y<br />
<br />
===Privacy, Security, and Data: Pragmatic Innovations for Users and the Web===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Product and Technology<br />
<br />
A discussion on how we combine our desire for excellent products, services and UX with leading privacy and security characteristics that advance trust, sustainability and safety for people.<br />
<br />
Facilitators:<br />
:Brussels: Stacy Martin / Garrett Robinson / Simon Bennetts<br />
:Toronto: Alex Fowler / Monica Chew / Yvan Boily<br />
:Santa Clara: Alina Hua / Sid Stamm / Joe Stevenson<br />
<br />
Session Etherpad: http://mzl.la/17Zwvki<br />
<br />
===Building through Brand===<br />
<br />
Friday, 1:00 - 2:15pm, 2:45 - 4:00pm<br />
<br />
Track: Purpose and Strategy<br />
<br />
NEED DESCRIPTION<br />
<br />
Facilitators (Pete Scanlon to coordinate):<br />
:Brussels: Ioana Chiorean, {{NeedCoFacilitator}}<br />
:Toronto: Winston Bowden and Michaela Thayer<br />
:Santa Clara: Sakina Groth, Alex Lakatos<br />
<br />
Session Etherpad: http://mzl.la/17ZwzR0<br />
<br />
==Saturday==<br />
<br />
===Practicing Open===<br />
<br />
Saturday, 1:30-3:30 pm<br />
<br />
Track: Purpose and Strategy<br />
<br />
When there's a conflict between openness and bushinesses requirements, how should we, as individuals, navigate that? What resources do we have available for guidance and help?<br />
<br />
Facilitators:<br />
:Toronto: Lawrence Kissuki, David Humphrey, Matthew Thompson<br />
:Brussels: Ioana Chiorean<br />
:Santa Clara: Sakina Groth<br />
<br />
Session Etherpad: http://mzl.la/17ZwUmQ<br />
<br />
===Mozilla: Winning the Next Three Years===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer, co-facilitators encouraged) <br />
<br />
Track: Purpose and Strategy<br />
<br />
What does Mozilla need to be doing right now, to move the web forward, to do right by our users, and what are the most important factors to consider in planning the next three years?<br />
<br />
Facilitators:<br />
:Brussels: David Ascher<br />
:Toronto: Mark Surman, Armen Zambrano<br />
:Santa Clara: Brendan Eich<br />
<br />
Session Etherpad: http://mzl.la/17ZwWuP<br />
<br />
===Building a Framework to enable Mozilla to effectively communicate across our community===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer, co-facilitators encouraged)<br />
<br />
Track: People and Process<br />
<br />
How does Mozilla hold a discussion on a particular topic that allows expression of positives and negatives in a productive way? This session will build the Mozilla Framework for how to invite feedback, manage the conversation and ensure all parties are acknowledged regardless of their view of the issue.<br />
<br />
Facilitators: <br />
:Brussels:[https://mozillians.org/u/gerv/ Gervase Markham]<br />
:Toronto: Lainie Delcoursy,[https://mozillians.org/en-US/u/feer56/ Andrew (feer56)], [https://mozillians.org/en-US/u/Kensie/ Majken Connor] <br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Etherpad: http://mzl.la/17ZwWeu<br />
<br />
===Defining and Packaging a Mozilla Core experience for onboarding===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer)<br />
<br />
Track: People & Process<br />
<br />
How do we create an experience that captures the history of Mozilla, our values, and what makes us unique in a way that we can transfer these items to new Mozillians and even our partners?<br />
<br />
Facilitators:<br />
:Brussels: Rubén Martín [:Nukeador] (one of the Mozilla Hispano mentors that runs the onboarding process for new contributors), Tobias Leingruber<br />
:Toronto: Amie Tyrrel, Amira Dhalla, Lainie DeCoursy<br />
:Santa Clara: Ankit Gadgil {{NeedCoFacilitator}}<br />
<br />
Session Etherpad: http://mzl.la/17Zx1Pf<br />
<br />
===What would a million Mozillians do?===<br />
<br />
Saturday, 1:30-3:30pm (yes, this is a longer session)<br />
<br />
Track: Purpose & Strategy<br />
<br />
Working Narrative: A creative, "blue sky" session to imagine new kinds of contributors<br />
<br />
Facilitators: <br />
:Brussels: [https://mozillians.org/u/kinger/ Brian King] (Community Manager for Europe), [https://mozillians.org/u/henx/ Henrik Mitsch], [https://mozillians.org/u/nethahussain/ Netha Hussain], [https://mozillians.org/u/thornet/ Michelle Thorne], [https://mozillians.org/u/FuzzyFox/ William Duyck]<br />
:Toronto: Marc Lesser, Margaret Schroeder<br />
:Santa Clara: David Boswell and William Quiviger<br />
<br />
Session Etherpad:http://mzl.la/1enxmmc<br />
<br />
===Developing empathy for your users===<br />
<br />
Saturday, 1:30-3:30 (yes, this one is longer)<br />
<br />
Track: Product & Technology<br />
<br />
A workshop where you learn how to easily make sure that the products you make are as appreciated as you think they should be.<br />
<br />
Facilitators:<br />
:Brussels: [https://mozillians.org/en-US/u/lco/ Larissa Co] , Maureen Hanratty<br />
:Toronto: Cori Schauer<br />
:Santa Clara: Lindsay Kenzig, Maria Sandberg<br />
<br />
Session Etherpad: http://mzl.la/1enxqlU<br />
<br />
===Understanding the Servo strategy===<br />
<br />
Saturday, 1:30 - 3:30pm <br />
<br />
Track: Product & Technology <br />
<br />
Web browsers were designed around yesterday's reality of computer hardware. Servo is a rethinking of the architecture of browsers to accommodate the hardware of today and tomorrow: multiple CPU's and powerful GPU's, and with limited power consumption. What's more, Servo is being built in [http://en.wikipedia.org/wiki/Rust_%28programming_language%29 Rust], a new programming language designed to support faster and safer development practices.<br />
<br />
Facilitators:<br />
:Brussels: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]<br />
:Toronto: Jack Moffitt<br />
:Santa Clara: Patrick Walton<br />
<br />
Session Etherpad: http://mzl.la/17Zx5yz<br />
<br />
===Growing Stakeholders in the Web===<br />
<br />
Saturday, 1:30 - 3:30pm<br />
<br />
Track: Product & Technology<br />
<br />
The success of the internet depends on commercial activity as well as individual self-expression. To make that work means that we need to understand the perspectives of different stakeholders, from phone manufacturers, to phone companies, to media companies, to consumers. <br />
<br />
Facilitators: <br />
:Brussels: Kat Braybrooke, <br />
:Toronto: Marc Lesser<br />
:Santa Clara: Geoffrey MacDougall, Need Co-Facilitator: Irina Sandu?<br />
<br />
Session Etherpad: http://mzl.la/1enxPVs<br />
<br />
===Who are our users in 2018 and where are they?===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology <br />
<br />
Alternate title: What's not going to change in 2018? What motivations our users will still hold in 10-15 years?<br />
<br />
The world is changing, and we need to build products that work for the next billion users. Who are they, and what are they like?<br />
<br />
Facilitators:<br />
:Brussels: Yuan Wang, Mary Trombley<br />
:Toronto: Cori Schauer<br />
:Santa Clara: Jinghua Zhang<br />
<br />
Session Etherpad: http://mzl.la/1enxKkH<br />
<br />
===Designing for our users not ourselves===<br />
<br />
Saturday, 4:00 - 6:00pm (yes, this one is longer) <br />
<br />
Track: Product & Technology<br />
<br />
Introduction to our users - who they are, what they do, what they need, and how Mozilla can do this.<br />
<br />
Facilitators:<br />
:Cori Schauer will be main facilitator for this, and will coordinate the other facilitators. <br />
:Brussels: Gemma & Madhava Zhenshuo & Dominik?<br />
:Toronto: Cori & Bryan Clark (possibly Gregg Lind) <br />
:Santa Clara: Bill Selman<br />
<br />
Session Etherpad: http://mzl.la/1enxtOr<br />
<br />
===How people see our markets and how we compete effectively in them===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
Powerful interests are creating silos of content and private walled gardens on the web. What can Mozilla do to open these silos up or create new more open alternatives? How do we need to understand how these competitors work for markets and consumers?<br />
<br />
Facilitators: <br />
:Brussels: Patrick Finch {{NeedCoFacilitator}}<br />
:Toronto: Kev Needham, John Jensen<br />
:Santa Clara: Irina Sandu, Sandip Kamat<br />
<br />
Session Etherpad:http://mzl.la/1enxOko<br />
<br />
===Understanding web developers===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
Web developers are a key community for Mozilla. Our competitors are building sophisticated developer tools, API's, and platform technologies. How can we maintain a close and symbiotic relationship with web developers? How do we meet their needs, and how do we get them signed up for Mozilla's mission?<br />
<br />
Facilitators: <br />
:Brussels: Jeff Griffiths<br />
:Toronto: Stormy Peters<br />
:Santa Clara: Christian Heilmann<br />
<br />
Session Etherpad: http://mzl.la/1enxVMI<br />
<br />
===The Petri Dish required by scaling innovation===<br />
<br />
Saturday, 4-6pm<br />
<br />
Track: Product and Technology<br />
<br />
If we're to have the kind of massive impact on the internet that we hope to, we have to ask ourselves whether our structure and processes will get us there. If we want to facilitate innovation at the edges and focus on recognizing good ideas rather than having them, how should we relate to web innovators around the world?<br />
<br />
Facilitators:<br />
:Brussels: David Ascher<br />
:Toronto: Simon Wex <br />
:Santa Clara: Robert Richter<br />
<br />
Session Etherpad: http://mzl.la/1enxJ00<br />
<br />
===WebMaker: Getting People to Take Back The Web===<br />
<br />
Saturday, 4-6 pm<br />
<br />
Track: Product and Technology<br />
<br />
Webmaker is the brand that we're using to tell a new generation of web citizens that the web is theirs to grab, shape and remix. We'll show you what that looks like, and get you activated to help in that effort!<br />
<br />
Facilitators: <br />
<br />
:Brussels: Kat Braybrooke, Henrik Mitsch, Michelle Thorne<br />
:Toronto: Chris Lawrence, Amira Dhalla, Lyre Calliope, Matt Thompson<br />
:Santa Clara: Brett Gaylor, Ankit Gadgil, Jacob Caggiano, Yoe One Ariestya Niovitta <br />
<br />
Session Etherpad:http://mzl.la/1enxYYR<br />
<br />
==Sunday==<br />
<br />
===Distributed Leadership and decision making===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Purpose and Strategy<br />
<br />
A well-facilitated inquiry and skillshare on distributed leadership. Skills Learned: Leadership, Conflict Resolution, Facilitating distributed meetings/planning/group actions. Potential Outline of Session:<br />
# Nature of Mozilla -- one pillar is human capability; more mozillians moving the mission forward<br />
# history of the huge chunks of mozilla that people made up on on their own and we incorporated into the centralized piece<br />
# Some issues with distributed decision-mkaing: risk, mistakes, surprise, messiness<br />
# What do we do now: how we build more APIs to the centralized part of mozilla? <br />
<br />
Facilitators:<br />
:Brussels: Laura Thomson, Ioana Chiorean<br />
:Toronto: [https://mozillians.org/en-US/u/regnard/ Regnard Raquedan], Lukas Blakk<br />
:Santa Clara: Alina Mierlus, Vineel Reddy Pindi<br />
<br />
Session Etherpad: http://mzl.la/17Zxktf<br />
<br />
===Ideas into Action: Next steps for me and my team===<br />
<br />
Sunday, 1:15-2:30<br />
<br />
Track: Purpose and Strategy<br />
<br />
Four breakout sessions with a joint shareback round. Determine what winning looks like as measured by Mozilla's four pillars of activity. Tools, roadmap and things you can do when you return home. How you can adapt the 3-year plan to your local context and the projects you care about. How you can multiply the mission. Skills Learned: Metrics, Building Open into your Project, How to Identify the NoM in your ideas & highlight/promote/grow those<br />
<br />
Facilitators:<br />
:Brussels: Karen Rudnitski<br />
:Toronto: Larissa Shapiro, Selena Deckelmann<br />
:Santa Clara: [https://mozillians.org/u/ernestchiang/ Ernest Chiang]<br />
<br />
Session Etherpad: http://mzl.la/1enyki5<br />
<br />
===Designing your project for participation===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
Nearly all projects will benefit from community involvement; however, there are different approaches and best practices that can better enable a project for wider contributions. This session will capture best practices and challenges to build a project with community involvement.<br />
<br />
Facilitators:<br />
:Brussels: [https://mozillians.org/en-US/u/LauraHilliger/ Laura Hilliger] (working with Mozilla Reps to help them deliver #teachtheweb professional development content)<br />
:Toronto: David Eaves (creator of the community building workshops that includes a 'Designing your project for participation' module) or Emma Irwin (One of the Mozilla Reps who will be delivering the community building workshop content), Jess Klein <br />
:Santa Clara: Benjamin Kerensa (One of the Mozilla Reps who will be delivering the community building workshop content) and Soumya Deb (Leader in Mozilla India)<br />
<br />
Session Etherpad: http://mzl.la/17Zxm4A<br />
<br />
===Community tools - what do we currently have===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
The topic of tooling seems to be a frequent one. Let's discuss the needs of the various members of the community and determine if there are shared tools in which we as a community should invest.<br />
<br />
Facilitators:<br />
:Brussels: [https://mozillians.org/u/jdm/ Josh Matthews], [https://mozillians.org/u/williamr/ William Reynolds] (members of the Community Building Systems Working Group)<br />
:Toronto: [https://mozillians.org/u/mhoye/ Michael Hoye], [https://mozillians.org/u/r1cky/ Ricky Rosario] (members of the Community Building Systems Working Group)<br />
:Santa Clara: [https://mozillians.org/u/pierros/ Pierros Papadeas] (members of the Community Building Systems Working Group)<br />
<br />
Session Etherpad: http://mzl.la/1enyrua<br />
<br />
===Working with corporate (closed) partners===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
How to stay open at Mozilla while meeting our needs: Creating a shared understanding of how Mozilla can work in a closed environment and a roadmap for introducing open concepts to our partners.<br />
<br />
Facilitators:<br />
*Toronto: Lawrence Mandel, Lukas Blakk, Bhavana Bajaj<br />
*Brussels: Dietrich Ayala, [https://mozillians.org/en-US/u/mcote/ Mark Côté], Chris Lee<br />
*Santa Clara: [https://mozillians.org/en-US/u/cpeterson/ Chris Peterson], Alex Keybl<br />
<br />
Session Etherpad: http://mzl.la/1enywhl<br />
<br />
===Workshop on Contributor recognition guide===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
Workshop to share tips and tricks for how recognize contributors to your project that would cover badges, swag, events and more. Also hack on the draft Recognition Guide at https://wiki.mozilla.org/Contribute/Recognition<br />
<br />
Facilitator:<br />
:Brussels: Michelle Marovich (Lead Recruiter) and Lizz Noonan (Brand Campaign Coordinator/Creative Contribute Community Co-manager)<br />
:Toronto: Jeff Beatty (Community Building for l10n)<br />
:Santa Clara: Rosana Ardila (Community Builder for SUMO)<br />
<br />
Session Etherpad: http://mzl.la/17ZxsJo<br />
<br />
===Moderated discussion on how we will think about product opportunities in the cloud===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
Mozilla has a proud history of championing user control of data, but there are both huge user benefits and competitive pressures to having some cloud-enabled data and services. How should Mozilla approach this problem in a way that pushes the mission forward while being pragmatic to the needs of the market?<br />
<br />
Facilitators: <br />
:Brussels: Lloyd Hilaiel<br />
:Toronto: John Jensen<br />
:Santa Clara: Toby Elliott<br />
<br />
Session Etherpad: http://mzl.la/17ZxrFk<br />
<br />
===The future of web gaming===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
The web is poised to become a platform for games, which opens up opportunities for new markets and independent developers. With WebGL, asm.js, and key web API's like Pointer Lock, Audio, and Video, Mozilla is making the future of web gaming a reality. Find out where we are and join us thinking about where to go from here.<br />
<br />
Facilitators:<br />
:Brussels: Vlad Vukicevic<br />
:Toronto: Martin Best<br />
:Santa Clara: Marco Mucci<br />
<br />
Session Etherpad: http://mzl.la/17Zxu3U<br />
<br />
===Open Badges: How to Encourage Engagement===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
Working Narrative: With OpenBadges, Mozilla has a combination of technology and market-shaping partners which could shift how people engage, get recognized for their skills and contributions, and unlock new opportunities. Learn about OpenBadges and what it's shooting for.<br />
<br />
Facilitators:<br />
:Brussels: Tim Riches, Emily Goligoski<br />
:Toronto: Meg Cole, Kerrie Lemoie, Damian Ewens<br />
:Santa Clara: Sunny Lee, Carla Casilli<br />
<br />
Session Etherpad:http://mzl.la/1enyN3W</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Summit2013/Sessions&diff=706458Summit2013/Sessions2013-09-11T16:20:48Z<p>Pfinch: /* Growing Stakeholders in the Web */</p>
<hr />
<div>=What are Supporting Sessions?=<br />
<br />
[https://wiki.mozilla.org/Summit2013/FAQ#What_are_.E2.80.9CSupporting_Sessions.E2.80.9D_and_how_did_they_get_on_the_agenda.3F Link to the general FAQ]<br />
<br />
=Call for Facilitators=<br />
<br />
We need facilitators for the supporting sessions! Anyone can be a facilitator. Here is the list of sessions currently on the agenda for the Mozilla Summit 2013, with facilitators at each location. More information on expectations of facilitators can be found on the [https://wiki.mozilla.org/Summit2013/Sessionfacilitators Session Facilitators wiki]. <br />
<br />
Each proposed session has its own etherpad for discussion and description, if you click through to it. Please add to that pad if you want to suggest specific questions to be addressed within the session.<br />
<br />
Also note there will be open sessions on site which can be signed up for when we are at the summit, "Unconference" style. For more information about how to sign-up to host an open session, please see our [https://wiki.mozilla.org/Summit2013/FAQ FAQ].<br />
<br />
=How to Sign-up?=<br />
<br />
See a session that you would like to facilitate? If so, please '''place your name by the appropriate location next to the session (listed below) on this wiki page.'''<br />
<br />
=Can I Co-facilitate?=<br />
<br />
In general, if you want to Co-facilitate a session, it is frequently possible, reach out to the track owner or to the facilitators themselves.<br />
<br />
=Who are the Track Owners?=<br />
<br />
[[https://wiki.mozilla.org/Summit2013/TrackOwners Track Owners]] for the Summit Are:<br />
<br />
:Mike Hoye (irc: mhoye), People and Process Track, office hours: 2-3 PM Eastern (6-7 PM UTC)<br />
:[[https://mozillians.org/en-US/u/lmandel/ Lawrence Mandel]] (irc: lmandel), Purpose and Strategy Track, office hours: Monday and Tuesday 11-12am Eastern Time.<br />
:[[https://mozillians.org/en-US/u/lshapiro/ Larisa Shapiro]] (irc: lshapiro), Product and Technology Track (and the Innovation Fair) office hours: M-W-F 9-10am Pacific Time<br />
<br />
You can also reach us at:<br />
:IRC: #mozsummit<br />
:Vidyo (during office hours): Summit Track Owners room<br />
<br />
Can't meet during the designated office hours? No problem. Just ping us and we'll set up an alternate time just for you. :)<br />
<br />
Don't know who to reach out to? [https://etherpad.mozilla.org/2013supportingsessions Here] is a list of sessions as they align with the Tracks.<br />
<br />
=Deadline to Sign-up=<br />
<br />
'''The deadline has now been extended - you can add yourself to a session until 12pm Pacific September 11, 2013. Please sign up!'''<br />
<br />
'''After this time, those sessions that do not have a designated facilitator will become open sessions.'''<br />
<br />
=Any Questions?=<br />
<br />
If you have any additional questions, please feel free to reach out to a Track Owner or read through our [https://wiki.mozilla.org/Summit2013/FAQ FAQ].<br />
<br />
=Sessions that need Facilitators=<br />
<br />
*Please note that those sessions that already have facilitators are not included on this list. If you are interested in co-facilitating a session that already has a facilitator, please reach out to them directly. <br />
<br />
==Friday==<br />
<br />
===Ecosystems in our Image===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-ecosystemsinourimage<br />
Put practically and short term: how our values show up in the app ecosystem or social network (where the users are now). And, in the long term, how do our values show up in big data, internet of things and other upcoming ecosystems.<br />
What would it look like to build a mobile apps and content ecosystem based literally on the ideas in the Nature of Mozilla? What features and marketing approaches would you include? How would we most effectively balance building, teaching and shaping markets? Where do local communities fit in as part of building this? Can they help build a long tail app ecosystem where we really see local diversity?<br />
<br />
Facilitators:<br />
:Brussels: {{NeedFacilitator}}, {{NeedCoFacilitator}}<br />
:Toronto: Chris Lawrence, Dan Sinker<br />
:Santa Clara: Alina Mierlus, {{NeedCoFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===The Web We Want===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-thewebwewant<br />
A large, interactive session to explore the web we're championing.What do we mean by "the web"? Is it a technology? A set of values? (also, how is it different from the Internet?) What are the baseline design principles we value most? Privacy? Creativity? User freedom? User Control? Data ownership? Something else? How is the web part of our identity? How do we use our products and our voice to help the broader world--including users--understand the web and become champions with us? <br />
<br />
Facilitators:<br />
:Santa Clara: Asa Dotzler, [[User:Tantek|Tantek Çelik]]<br />
:Brussels: Larissa Co, [[User:Aking|Ozten]]<br />
:Toronto: Potch, [[User:Mcollins|Mike Collins]]<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara: <br />
<br />
Afterwards:<br />
* I've proposed an [[IndieWeb]] Hackspace on the [[Summit2013/Experiences#HackSpaces|Summit2013 Experiences]] wiki page for those that want to actively hack on their own websites and create the web we want by example. - [[User:Tantek|Tantek]] ([[User talk:Tantek|talk]])<br />
<br />
===Building a Web Literate World===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-buildingawebliterateworld<br />
Why the large majority of people on the web should understand how the web works and how are we going to empower them to make it. How we can teach the everyday internet users more skills to improve their online experience and understand how the web works.<br />
<br />
Facilitators: <br />
:Toronto: Marc Lesser, MOUSE, Julia Vallera, Lyre Calliope<br />
:Santa Clara, Sandraghassen Subbaraya Pillai, Ankit Gadgil<br />
:Brussels: Christos Bacharakis, Michael Köhler, Ibrahima SARR<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===What does "Mozillian" mean?===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-meaningofmozillian<br />
A hands-on session to define the identity of Mozillians, historically and as we evolve. Towards building scope and identity as a community. Consider new domains, like news and science. Do partners count? Who do we count? What are we trying to build? Who are we inviting?<br />
<br />
Facilitators: <br />
:Brussels: Gervase Markham, Wilson Guaraca, Ioana Chiorean<br />
:Toronto: Guillermo Movia, Andrew (feer56)- Will do second session @2:45<br />
:Santa Clara: Sujith Reddy (would like co facilitator), {{NeedCoFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===How FxOS could change the net in 10 years===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Product and Technology<br />
<br />
https://etherpad.mozilla.org/summit-sessions-friday-fxosin2014<br />
<br />
The strategy and vision for what Firefox OS is trying to accomplish, what markets it's heading for, as well as showcasing the technology and features.<br />
<br />
Facilitators:<br />
:Brussels: Chris Lee, Bill Maggs <br />
:Toronto: Peter Dolanjski, {{NeedCoFacilitator}}<br />
:Santa Clara: Sandip Kamat, Christian Heilmann<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Privacy, Security, and Data: Pragmatic Innovations for Users and the Web===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-privacysecuritydata<br />
A discussion on how we combine our desire for excellent products, services and UX with leading privacy and security characteristics that advance trust, sustainability and safety for people.<br />
<br />
Facilitators:<br />
:Brussels: Stacy Martin / Garrett Robinson or Brian Smith / [Coates' team rep]<br />
:Toronto: Alex Fowler / Camilo Viecco or Monica Chew / [Coates' team rep]<br />
:Santa Clara: Alina Hua / Sid Stamm / [Coates' team rep]<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
==Saturday==<br />
<br />
===Building through Brand===<br />
<br />
Saturday, 1:30-3:30<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-buildingthroughbrand<br />
NEED DESCRIPTION<br />
<br />
Facilitators (Pete Scanlon to coordinate):<br />
:Brussels: Ioana Chiorean, {{NeedCoFacilitator}}<br />
:Toronto: {{NeedFacilitator}}, {{NeedCoFacilitator}}<br />
:Santa Clara: Sakina Groth, {{NeedCoFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Practicing Open===<br />
<br />
Saturday, 1:30-3:30 pm<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-practicingopen<br />
When there's a conflict between openness and businses requirements, how should we, as individuals, navigate that? What resources do we have available for guidance and help?<br />
<br />
Facilitators:<br />
:Toronto: Emma Irwin, Lawrence Kissuki, David Humphrey<br />
:Brussels: Ioana Chiorean, Gervase Markham<br />
:Santa Clara: Sakina Groth<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Mozilla: Winning the Next Three Years===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer, co-facilitators encouraged) <br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-winningnext3years<br />
What does Mozilla need to be doing right now, to move the web forward, to do right by our users, and what are the most important factors to consider in planning the next three years?<br />
<br />
Facilitators:<br />
:Brussels: {{NeedFacilitator}}<br />
:Toronto: Mark Surman<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Winning through Product: Applying the Lessons of Firefox Today===<br />
<br />
Saturday, 1:30 - 3:30pm<br />
<br />
Track: Purpose & Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-winningthroughproduct<br />
NEED DESCRIPTION<br />
<br />
Facilitators:<br />
:Brussels: {{NeedFacilitator}}<br />
:Toronto: Armen Zambrano<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Building a Framework to enable Mozilla to effectively communicate across our community===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer, co-facilitators encouraged)<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-frameworktocommunicate<br />
How does Mozilla hold a discussion on a particular topic that allows expression of positives and negatives in a productive way? This session will build the Mozilla Framework for how to invite feedback, manage the conversation and ensure all parties are acknowledged regardless of their view of the issue.<br />
<br />
Facilitators: <br />
:Brussels: {{NeedFacilitator}}<br />
:Toronto: Lainie Delcoursy<br />
:Santa Clara: Kathryn Meisner<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Defining and Packaging a Mozilla Core experience for onboarding===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer)<br />
<br />
Track: People & Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-mozillacoreforonboarding<br />
How do we create an experience that captures the history of Mozilla, our values, and what makes us unique in a way that we can transfer these items to new Mozillians and even our partners?<br />
<br />
Facilitators:<br />
:Brussels: Rubén Martín [:Nukeador] (one of the Mozilla Hispano mentors that runs the onboarding process for new contributors)<br />
:Toronto: Amie Tyrrel, Amira Dhalla<br />
:Santa Clara: Ankit Gadgil<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===What would a million Mozillians do?===<br />
<br />
Saturday, 1:30-3:30pm (yes, this is a longer session)<br />
<br />
Track: Purpose & Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-whatwould1millmozilliansdo<br />
Working Narrative: A creative, "blue sky" session to imagine new kinds of contributors<br />
<br />
Facilitators: <br />
:Brussels: Brian King (Community Manager for Europe)<br />
:Toronto: Liz Henry (Community Builder for Automation team)<br />
:Santa Clara: David Boswell (currently looking into pilot projects to create new functional and regional communities, such as Mozilla Utah and Mozilla knitters)<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Developing empathy for your users===<br />
<br />
Saturday, 1:30-3:30 (yes, this one is longer)<br />
<br />
Track:<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-empathyforusers <br />
A workshop where you learn how to easily make sure that the products you make are as appreciated as you think they should be.<br />
<br />
Facilitators:<br />
:Brussels: Larissa Co, Maureen Hanratty<br />
:Toronto: Cori Schauer<br />
:Santa Clara: Bill Selman<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Designing for our users not ourselves===<br />
<br />
Saturday, 1:30-3:30 (yes, this one is longer) <br />
<br />
Track: Product & Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-designingforusers<br />
Introduction to our users - who they are, what they do, what they need, and how Mozilla can do this.<br />
<br />
Facilitators:<br />
:Cori Schauer will be main facilitator for this, and will coordinate the other facilitators. <br />
:Brussels: Gemma & Madhava Zhenshuo & Dominik?<br />
:Toronto: Cori & Bryan Clark (possibly Gregg Lind) <br />
:Santa Clara: Bill Selman & Lindsay Kenzig<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Understanding the Servo strategy===<br />
<br />
Saturday, 1:30 - 3:30pm <br />
<br />
Track: Product & Technology <br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-understandingservo <br />
Web browsers were designed around yesterday's reality of computer hardware. Servo is a rethinking of the architecture of browsers to accommodate the hardware of today and tomorrow: multiple CPU's and powerful GPU's, and with limited power consumption. What's more, Servo is being built in [http://en.wikipedia.org/wiki/Rust_%28programming_language%29 Rust], a new programming language designed to support faster and safer development practices.<br />
<br />
Facilitators:<br />
:Brussels: Josh Matthews<br />
:Toronto: Jack Moffitt<br />
:Santa Clara: Patrick Walton<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Who are our users in 2018 and where are they?===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology <br />
<br />
https://etherpad.mozilla.org/summit-sessions-saturday-usersin2018 <br />
<br />
Alternate title: What's not going to change in 2018? What motivations our users will still hold in 10-15 years?<br />
<br />
The world is changing, and we need to build products that work for the next billion users. Who are they, and what are they like?<br />
<br />
Facilitators:<br />
:Brussels: Yuan Wang, Mary Trombley<br />
:Toronto: Cori Schauer<br />
:Santa Clara: Jinghua Zhang, Bill Selman, Lindsay Kenzig,<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Understanding the product strategies of our competition in the eyes of consumers and working through how to compete intelligently===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
https://etherpad.mozilla.org/summit-sessions-saturday-productstrategythroughconsumerseyes<br />
<br />
Powerful interests are creating silos of content and private walled gardens on the web. What can Mozilla do to open these silos up or create new more open alternatives? How do we need to understand how these competitors work for markets and consumers?<br />
<br />
Facilitators: <br />
:Brussels: Patrick Finch {{NeedCoFacilitator}}<br />
:Toronto: Kev Needham {{NeedCoFacilitator}}<br />
:Santa Clara: Irina Sandu {{NeedCoFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Understanding web developers===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
Web developers are a key community for Mozilla. Our competitors are building sophisticated developer tools, API's, and platform technologies. How can we maintain a close and symbiotic relationship with web developers? How do we meet their needs, and how do we get them signed up for Mozilla's mission?<br />
<br />
https://etherpad.mozilla.org/summit-sessions-saturday-understandingdevelopers<br />
<br />
Facilitators: <br />
:Brussels: Jeff Griffiths<br />
:Toronto: Stormy Peters<br />
:Santa Clara: Christian Heilmann<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Growing Stakeholders in the Web===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
The success of the internet depends on commercial activity as well as individual self-expression. To make that work means that we need to understand the perspectives of different stakeholders, from phone manufacturers, to phone companies, to media companies, to consumers. <br />
<br />
https://etherpad.mozilla.org/summit-sessions-saturday-growingstakeholders<br />
<br />
Facilitators: <br />
:Brussels: Kat Braybrooke, Patrick Finch can co-facilitate<br />
:Toronto: Marc Lesser, Geoffrey MacDougall<br />
:Santa Clara: {{NeedFacilitator}} Irina Sandu can co-facilitate at minimum<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===The Petri Dish required by scaling innovation===<br />
<br />
Saturday, 4-6pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-petridish <br />
If we're to have the kind of massive impact on the internet that we hope to, we have to ask ourselves whether our structure and processes will get us there. If we want to facilitate innovation at the edges and focus on recognizing good ideas rather than having them, how should we relate to web innovators around the world?<br />
<br />
Facilitators:<br />
:Brussels: David Ascher<br />
:Toronto: Simon Wex <br />
:Santa Clara: Robert Richter<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===WebMaker: Getting People to Take Back The Web===<br />
<br />
Saturday, 4-6 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-takebacktheweb<br />
<br />
Webmaker is the brand that we're using to tell a new generation of web citizens that the web is theirs to grab, shape and remix. We'll show you what that looks like, and get you activated to help in that effort!<br />
<br />
Facilitators: <br />
:Brussels: Kat Braybrooke, Henrik Mitsch<br />
:Toronto: Amira Dhalla, Chris Lawrence, Matt Thompson <br />
:Santa Clara: Brett Gaylor<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
==Sunday==<br />
<br />
===Distributed Leadership and decision making===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-distributedleadership<br />
A well-facilitated inquiry and skillshare on distributed leadership. Skills Learned: Leadership, Conflict Resolution, Facilitating distributed meetings/planning/group actions. Potential Outline of Session:<br />
# Nature of Mozilla -- one pillar is human capability; more mozillians moving the mission forward<br />
# history of the huge chunks of mozilla that people made up on on their own and we incorporated into the centralized piece<br />
# Some issues with distributed decision-mkaing: risk, mistakes, surprise, messiness<br />
# What do we do now: how we build more APIs to the centralized part of mozilla? <br />
<br />
Facilitators:<br />
:Brussels: Laura Thomson<br />
:Toronto: Regnard Raquedan<br />
:Santa Clara: Alina Mierlus<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Ideas into Action: Next steps for me and my team===<br />
<br />
Sunday, 1:15-2:30<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-ideasintoaction<br />
Four breakout sessions with a joint shareback round. Determine what winning looks like as measured by Mozilla's four pillars of activity. Tools, roadmap and things you can do when you return home. How you can adapt the 3-year plan to your local context and the projects you care about. How you can multiply the mission. Skills Learned: Metrics, Building Open into your Project, How to Identify the NoM in your ideas & highlight/promote/grow those<br />
<br />
Facilitators:<br />
:Brussels: Karen Rudnitski<br />
:Toronto: Larissa Shapiro<br />
:Santa Clara: Ernest Chiang<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Decisions, discussions and debate===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-decisionsdiscussionsdebate<br />
A structure for Mozilla to engage our community and reach decisions. Collaboratively building a framework that enables Mozilla to reach decisions in a distributed decentralized organization. This session will determine an agreed upon best practice framework for inviting discussion, acknowledging user input, and reaching a decision amidst a variety of feedback.<br />
<br />
Facilitators:<br />
:Brussels: Gervase Markham, {{NeedCoFacilitator}}<br />
:Toronto: Andrew (feer56) - This is a maybe as my flight leaves at 6:30 PM. {{NeedCoFacilitator)}<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Designing your project for participation===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-designingforparticipation<br />
Nearly all projects will benefit from community involvement; however, there are different approaches and best practices that can better enable a project for wider contributions. This session will capture best practices and challenges to build a project with community involvement.<br />
<br />
Facilitators:<br />
:Brussels: Laura Hilliger or Michelle Thorne (working with Mozilla Reps to help them deliver the community building workshop content)<br />
:Toronto: David Eaves (creator of the community building workshops that includes a 'Designing your project for participation' module) or Emma Irwin (One of the Mozilla Reps who will be delivering the community building workshop content)<br />
:Santa Clara: Benjamin Kerensa (One of the Mozilla Reps who will be delivering the community building workshop content)<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Community tools - what do we currently have===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-communitytools<br />
The topic of tooling seems to be a frequent one. Let's discuss the needs of the various members of the community and determine if there are shared tools in which we as a community should invest.<br />
<br />
Facilitators:<br />
:Brussels: Josh Matthews, William Reynolds (members of the Community Building Systems Working Group)<br />
:Toronto: Michael Hoye (members of the Community Building Systems Working Group)<br />
:Santa Clara: Pierros Papadeas (members of the Community Building Systems Working Group)<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Working with corporate (closed) partners===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-workingwithpartners<br />
How to stay open at Mozilla while meeting our needs: Creating a shared understanding of how Mozilla can work in a closed environment and a roadmap for introducing open concepts to our partners.<br />
<br />
Facilitators:<br />
:Santa Clara {{NeedFacilitator}}<br />
:Brussels: Dietrich Ayala, Mark C&ocirc;t&eacute;<br />
:Toronto: Lawrence Mandel, Lukas Blakk, Bhavana Bajaj<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Workshop on Contributor recognition guide===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-contributorrecognitionguide<br />
Workshop to share tips and tricks for how recognize contributors to your project that would cover badges, swag, events and more. Also hack on the draft Recognition Guide at https://wiki.mozilla.org/Contribute/Recognition<br />
<br />
Facilitator:<br />
:Brussels: Janet Swisher (Community Builder for MDN)<br />
:Toronto: Jeff Beatty (Community Building for l10n)<br />
:Santa Clara: Rosana Ardila (Community Builder for SUMO)<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===The Web in the Mobile Age===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-webinmobileage<br />
What will it take to make the experience of the mobile Web better? How will we make apps and UI's more usable, to make payments smoother, to make the Web as compelling a platform in the mobile world as native apps?<br />
<br />
Facilitator<br />
:Brussels: Tony Santos<br />
:Toronto: {{NeedFacilitator}}<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Moderated discussion on how we will think about product opportunities in the cloud===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-productincloud<br />
Mozilla has a proud history of championing user control of data, but there are both huge user benefits and competitive pressures to having some cloud-enabled data and services. How should Mozilla approach this problem in a way that pushes the mission forward while being pragmatic to the needs of the market?<br />
<br />
Facilitators: <br />
:Brussels: Lloyd Hilaiel<br />
:Toronto: {{NeedFacilitator}}<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===The future of web gaming===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-futureofwebgaming<br />
The web is poised to become a platform for games, which opens up opportunities for new markets and independent developers. With WebGL, asm.js, and key web API's like Pointer Lock, audio, and video, Mozilla is making the future of web gaming a reality, and creating an open alternative to proprietary technologies like Google's NaCl and Chrome.<br />
<br />
Facilitators:<br />
:Brussels: Vlad Vukicevic<br />
:Toronto: Martin Best<br />
:Santa Clara: Marco Mucci<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Badges and how they can help rethink education===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-badgesrethinkeducation<br />
Working Narrative: With OpenBadges, Mozilla has a combination of technology and market-shaping partners which could shift how people learn, get recognized for their skills, and level up in the game of life. Learn about the OpenBadges project and what it's shooting for.<br />
<br />
Facilitators:<br />
:Brussels: Tim Riches, Emily Goligoski<br />
:Toronto: Jess Klein, Meg Cole, Kerrie Lemoie<br />
:Santa Clara: Sunny Lee, Carla Casilli<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Summit2013/Sessions&diff=706313Summit2013/Sessions2013-09-11T12:40:41Z<p>Pfinch: /* Understanding the product strategies of our competition in the eyes of consumers and working through how to compete intelligently */</p>
<hr />
<div>=What are Supporting Sessions?=<br />
<br />
[https://wiki.mozilla.org/Summit2013/FAQ#What_are_.E2.80.9CSupporting_Sessions.E2.80.9D_and_how_did_they_get_on_the_agenda.3F Link to the general FAQ]<br />
<br />
=Call for Facilitators=<br />
<br />
We need facilitators for the supporting sessions! Anyone can be a facilitator. Here is the list of sessions currently on the agenda for the Mozilla Summit 2013, with facilitators at each location. More information on expectations of facilitators can be found on the [https://wiki.mozilla.org/Summit2013/Sessionfacilitators Session Facilitators wiki]. <br />
<br />
Each proposed session has its own etherpad for discussion and description, if you click through to it. Please add to that pad if you want to suggest specific questions to be addressed within the session.<br />
<br />
Also note there will be open sessions on site which can be signed up for when we are at the summit, "Unconference" style. For more information about how to sign-up to host an open session, please see our [https://wiki.mozilla.org/Summit2013/FAQ FAQ].<br />
<br />
=How to Sign-up?=<br />
<br />
See a session that you would like to facilitate? If so, please '''place your name by the appropriate location next to the session (listed below) on this wiki page.'''<br />
<br />
=Can I Co-facilitate?=<br />
<br />
In general, if you want to Co-facilitate a session, it is frequently possible, reach out to the track owner or to the facilitators themselves.<br />
<br />
=Who are the Track Owners?=<br />
<br />
[[https://wiki.mozilla.org/Summit2013/TrackOwners Track Owners]] for the Summit Are:<br />
<br />
:Mike Hoye (irc: mhoye), People and Process Track, office hours: 2-3 PM Eastern (6-7 PM UTC)<br />
:[[https://mozillians.org/en-US/u/lmandel/ Lawrence Mandel]] (irc: lmandel), Purpose and Strategy Track, office hours: Monday and Tuesday 11-12am Eastern Time.<br />
:[[https://mozillians.org/en-US/u/lshapiro/ Larisa Shapiro]] (irc: lshapiro), Product and Technology Track (and the Innovation Fair) office hours: M-W-F 9-10am Pacific Time<br />
<br />
You can also reach us at:<br />
:IRC: #mozsummit<br />
:Vidyo (during office hours): Summit Track Owners room<br />
<br />
Can't meet during the designated office hours? No problem. Just ping us and we'll set up an alternate time just for you. :)<br />
<br />
Don't know who to reach out to? [https://etherpad.mozilla.org/2013supportingsessions Here] is a list of sessions as they align with the Tracks.<br />
<br />
=Deadline to Sign-up=<br />
<br />
'''The deadline has now been extended - you can add yourself to a session until 12pm Pacific September 11, 2013. Please sign up!'''<br />
<br />
'''After this time, those sessions that do not have a designated facilitator will become open sessions.'''<br />
<br />
=Any Questions?=<br />
<br />
If you have any additional questions, please feel free to reach out to a Track Owner or read through our [https://wiki.mozilla.org/Summit2013/FAQ FAQ].<br />
<br />
=Sessions that need Facilitators=<br />
<br />
*Please note that those sessions that already have facilitators are not included on this list. If you are interested in co-facilitating a session that already has a facilitator, please reach out to them directly. <br />
<br />
==Friday==<br />
<br />
===Ecosystems in our Image===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-ecosystemsinourimage<br />
Put practically and short term: how our values show up in the app ecosystem or social network (where the users are now). And, in the long term, how do our values show up in big data, internet of things and other upcoming ecosystems.<br />
What would it look like to build a mobile apps and content ecosystem based literally on the ideas in the Nature of Mozilla? What features and marketing approaches would you include? How would we most effectively balance building, teaching and shaping markets? Where do local communities fit in as part of building this? Can they help build a long tail app ecosystem where we really see local diversity?<br />
<br />
Facilitators:<br />
:Brussels: {{NeedFacilitator}}, {{NeedCoFacilitator}}<br />
:Toronto: Chris Lawrence, Dan Sinker<br />
:Santa Clara: Alina Mierlus, {{NeedCoFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===The Web We Want===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-thewebwewant<br />
A large, interactive session to explore the web we're championing.What do we mean by "the web"? Is it a technology? A set of values? (also, how is it different from the Internet?) What are the baseline design principles we value most? Privacy? Creativity? User freedom? User Control? Data ownership? Something else? How is the web part of our identity? How do we use our products and our voice to help the broader world--including users--understand the web and become champions with us? <br />
<br />
Facilitators:<br />
:Santa Clara: Asa Dotzler, [[User:Tantek|Tantek Çelik]]<br />
:Brussels: Larissa Co, [[User:Aking|Ozten]]<br />
:Toronto: Potch, [[User:Mcollins|Mike Collins]]<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara: <br />
<br />
Afterwards:<br />
* I've proposed an [[IndieWeb]] Hackspace on the [[Summit2013/Experiences#HackSpaces|Summit2013 Experiences]] wiki page for those that want to actively hack on their own websites and create the web we want by example. - [[User:Tantek|Tantek]] ([[User talk:Tantek|talk]])<br />
<br />
===Building a Web Literate World===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-buildingawebliterateworld<br />
Why the large majority of people on the web should understand how the web works and how are we going to empower them to make it. How we can teach the everyday internet users more skills to improve their online experience and understand how the web works.<br />
<br />
Facilitators: <br />
:Toronto: Marc Lesser, MOUSE, Julia Vallera, Lyre Calliope<br />
:Santa Clara, Sandraghassen Subbaraya Pillai, Ankit Gadgil<br />
:Brussels: Christos Bacharakis, Michael Köhler, Ibrahima SARR<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===What does "Mozillian" mean?===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-meaningofmozillian<br />
A hands-on session to define the identity of Mozillians, historically and as we evolve. Towards building scope and identity as a community. Consider new domains, like news and science. Do partners count? Who do we count? What are we trying to build? Who are we inviting?<br />
<br />
Facilitators: <br />
:Brussels: Gervase Markham, Wilson Guaraca<br />
:Toronto: Guillermo Movia, Andrew (feer56)- Will do second session @2:45<br />
:Santa Clara: Sujith Reddy (would like co facilitator), {{NeedCoFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===How FxOS could change the net in 10 years===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Product and Technology<br />
<br />
https://etherpad.mozilla.org/summit-sessions-friday-fxosin2014<br />
<br />
The strategy and vision for what Firefox OS is trying to accomplish, what markets it's heading for, as well as showcasing the technology and features.<br />
<br />
Facilitators:<br />
:Brussels: Chris Lee, Bill Maggs <br />
:Toronto: Peter Dolanjski, {{NeedCoFacilitator}}<br />
:Santa Clara: Sandip Kamat, Christian Heilmann<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Privacy, Security, and Data: Pragmatic Innovations for Users and the Web===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-privacysecuritydata<br />
A discussion on how we combine our desire for excellent products, services and UX with leading privacy and security characteristics that advance trust, sustainability and safety for people.<br />
<br />
Facilitators:<br />
:Brussels: Stacy Martin / Garrett Robinson or Brian Smith / [Coates' team rep]<br />
:Toronto: Alex Fowler / Camilo Viecco or Monica Chew / [Coates' team rep]<br />
:Santa Clara: Alina Hua / Sid Stamm / [Coates' team rep]<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
==Saturday==<br />
<br />
===Building through Brand===<br />
<br />
Saturday, 1:30-3:30<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-buildingthroughbrand<br />
NEED DESCRIPTION<br />
<br />
Facilitators (Pete Scanlon to coordinate):<br />
:Brussels: {{NeedFacilitator}}, {{NeedCoFacilitator}}<br />
:Toronto: {{NeedFacilitator}}, {{NeedCoFacilitator}}<br />
:Santa Clara: {{NeedFacilitator}}, {{NeedCoFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Practicing Open===<br />
<br />
Saturday, 1:30-3:30 pm<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-practicingopen<br />
When there's a conflict between openness and businses requirements, how should we, as individuals, navigate that? What resources do we have available for guidance and help?<br />
<br />
Facilitators:<br />
:Toronto: Emma Irwin, Lawrence Kissuki, David Humphrey<br />
:Brussels: Stefania, IoanaChiorean, Gervase Markham<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Mozilla: Winning the Next Three Years===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer, co-facilitators encouraged) <br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-winningnext3years<br />
What does Mozilla need to be doing right now, to move the web forward, to do right by our users, and what are the most important factors to consider in planning the next three years?<br />
<br />
Facilitators:<br />
:Brussels: {{NeedFacilitator}}<br />
:Toronto: Mark Surman<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Winning through Product: Applying the Lessons of Firefox Today===<br />
<br />
Saturday, 1:30 - 3:30pm<br />
<br />
Track: Purpose & Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-winningthroughproduct<br />
NEED DESCRIPTION<br />
<br />
Facilitators:<br />
:Brussels: {{NeedFacilitator}}<br />
:Toronto: Armen Zambrano<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Building a Framework to enable Mozilla to effectively communicate across our community===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer, co-facilitators encouraged)<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-frameworktocommunicate<br />
How does Mozilla hold a discussion on a particular topic that allows expression of positives and negatives in a productive way? This session will build the Mozilla Framework for how to invite feedback, manage the conversation and ensure all parties are acknowledged regardless of their view of the issue.<br />
<br />
Facilitators: <br />
:Brussels: {{NeedFacilitator}}<br />
:Toronto: Lainie Delcoursy<br />
:Santa Clara: Kathryn Meisner<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Defining and Packaging a Mozilla Core experience for onboarding===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer)<br />
<br />
Track: People & Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-mozillacoreforonboarding<br />
How do we create an experience that captures the history of Mozilla, our values, and what makes us unique in a way that we can transfer these items to new Mozillians and even our partners?<br />
<br />
Facilitators:<br />
:Brussels: Rubén Martín [:Nukeador] (one of the Mozilla Hispano mentors that runs the onboarding process for new contributors)<br />
:Toronto: Amie Tyrrel, Amira Dhalla<br />
:Santa Clara: Ankit Gadgil<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===What would a million Mozillians do?===<br />
<br />
Saturday, 1:30-3:30pm (yes, this is a longer session)<br />
<br />
Track: Purpose & Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-whatwould1millmozilliansdo<br />
Working Narrative: A creative, "blue sky" session to imagine new kinds of contributors<br />
<br />
Facilitators: <br />
:Brussels: Brian King (Community Manager for Europe)<br />
:Toronto: Liz Henry (Community Builder for Automation team)<br />
:Santa Clara: David Boswell (currently looking into pilot projects to create new functional and regional communities, such as Mozilla Utah and Mozilla knitters)<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Developing empathy for your users===<br />
<br />
Saturday, 1:30-3:30 (yes, this one is longer)<br />
<br />
Track:<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-empathyforusers <br />
A workshop where you learn how to easily make sure that the products you make are as appreciated as you think they should be.<br />
<br />
Facilitators:<br />
:Brussels: Larissa Co, Maureen Hanratty<br />
:Toronto: Cori Schauer<br />
:Santa Clara: Bill Selman<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Designing for our users not ourselves===<br />
<br />
Saturday, 1:30-3:30 (yes, this one is longer) <br />
<br />
Track: Product & Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-designingforusers<br />
Introduction to our users - who they are, what they do, what they need, and how Mozilla can do this.<br />
<br />
Facilitators:<br />
:Cori Schauer will be main facilitator for this, and will coordinate the other facilitators. <br />
:Brussels: Gemma & Madhava Zhenshuo & Dominik?<br />
:Toronto: Cori & Bryan Clark (possibly Gregg Lind) <br />
:Santa Clara: Bill Selman & Lindsay Kenzig<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Understanding the Servo strategy===<br />
<br />
Saturday, 1:30 - 3:30pm <br />
<br />
Track: Product & Technology <br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-understandingservo <br />
Web browsers were designed around yesterday's reality of computer hardware. Servo is a rethinking of the architecture of browsers to accommodate the hardware of today and tomorrow: multiple CPU's and powerful GPU's, and with limited power consumption. What's more, Servo is being built in [http://en.wikipedia.org/wiki/Rust_%28programming_language%29 Rust], a new programming language designed to support faster and safer development practices.<br />
<br />
Facilitators:<br />
:Brussels: Josh Matthews<br />
:Toronto: Jack Moffitt<br />
:Santa Clara: Patrick Walton<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Who are our users in 2018 and where are they?===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology <br />
<br />
https://etherpad.mozilla.org/summit-sessions-saturday-usersin2018 <br />
<br />
Alternate title: What's not going to change in 2018? What motivations our users will still hold in 10-15 years?<br />
<br />
The world is changing, and we need to build products that work for the next billion users. Who are they, and what are they like?<br />
<br />
Facilitators:<br />
:Brussels: Yuan Wang, Mary Trombley<br />
:Toronto: Cori Schauer<br />
:Santa Clara: Jinghua Zhang, Bill Selman, Lindsay Kenzig,<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Understanding the product strategies of our competition in the eyes of consumers and working through how to compete intelligently===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
https://etherpad.mozilla.org/summit-sessions-saturday-productstrategythroughconsumerseyes<br />
<br />
Powerful interests are creating silos of content and private walled gardens on the web. What can Mozilla do to open these silos up or create new more open alternatives? How do we need to understand how these competitors work for markets and consumers?<br />
<br />
Facilitators: <br />
:Brussels: Patrick Finch {{NeedCoFacilitator}}<br />
:Toronto:{{NeedFacilitator}}<br />
:Santa Clara:{{NeedFacilitator}} Irina Sandu can co-facilitate at a minimum<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Understanding web developers===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
Web developers are a key community for Mozilla. Our competitors are building sophisticated developer tools, API's, and platform technologies. How can we maintain a close and symbiotic relationship with web developers? How do we meet their needs, and how do we get them signed up for Mozilla's mission?<br />
<br />
https://etherpad.mozilla.org/summit-sessions-saturday-understandingdevelopers<br />
<br />
Facilitators: <br />
:Brussels: Jeff Griffiths<br />
:Toronto: Stormy Peters<br />
:Santa Clara: Christian Heilmann<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Growing Stakeholders in the Web===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
The success of the internet depends on commercial activity as well as individual self-expression. To make that work means that we need to understand the perspectives of different stakeholders, from phone manufacturers, to phone companies, to media companies, to consumers. <br />
<br />
Facilitators: <br />
:Brussels: Kat Braybrooke<br />
:Toronto: Marc Lesser, Geoffrey MacDougall<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===The Petri Dish required by scaling innovation===<br />
<br />
Saturday, 4-6pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-petridish <br />
If we're to have the kind of massive impact on the internet that we hope to, we have to ask ourselves whether our structure and processes will get us there. If we want to facilitate innovation at the edges and focus on recognizing good ideas rather than having them, how should we relate to web innovators around the world?<br />
<br />
Facilitators:<br />
:Brussels: David Ascher<br />
:Toronto: Simon Wex <br />
:Santa Clara: Robert Richter<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===WebMaker: Getting People to Take Back The Web===<br />
<br />
Saturday, 4-6 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-takebacktheweb<br />
<br />
Webmaker is the brand that we're using to tell a new generation of web citizens that the web is theirs to grab, shape and remix. We'll show you what that looks like, and get you activated to help in that effort!<br />
<br />
Facilitators: <br />
:Brussels: Kat Braybrooke, Henrik Mitsch<br />
:Toronto: Amira Dhalla, Chris Lawrence, Matt Thompson <br />
:Santa Clara: Brett Gaylor<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
==Sunday==<br />
<br />
===Distributed Leadership and decision making===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-distributedleadership<br />
A well-facilitated inquiry and skillshare on distributed leadership. Skills Learned: Leadership, Conflict Resolution, Facilitating distributed meetings/planning/group actions. Potential Outline of Session:<br />
# Nature of Mozilla -- one pillar is human capability; more mozillians moving the mission forward<br />
# history of the huge chunks of mozilla that people made up on on their own and we incorporated into the centralized piece<br />
# Some issues with distributed decision-mkaing: risk, mistakes, surprise, messiness<br />
# What do we do now: how we build more APIs to the centralized part of mozilla? <br />
<br />
Facilitators:<br />
:Brussels: Laura Thomson<br />
:Toronto: Regnard Raquedan<br />
:Santa Clara: Alina Mierlus<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Ideas into Action: Next steps for me and my team===<br />
<br />
Sunday, 1:15-2:30<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-ideasintoaction<br />
Four breakout sessions with a joint shareback round. Determine what winning looks like as measured by Mozilla's four pillars of activity. Tools, roadmap and things you can do when you return home. How you can adapt the 3-year plan to your local context and the projects you care about. How you can multiply the mission. Skills Learned: Metrics, Building Open into your Project, How to Identify the NoM in your ideas & highlight/promote/grow those<br />
<br />
Facilitators:<br />
:Brussels: Karen Rudnitski<br />
:Toronto: Larissa Shapiro<br />
:Santa Clara: Ernest Chiang<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Decisions, discussions and debate===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-decisionsdiscussionsdebate<br />
A structure for Mozilla to engage our community and reach decisions. Collaboratively building a framework that enables Mozilla to reach decisions in a distributed decentralized organization. This session will determine an agreed upon best practice framework for inviting discussion, acknowledging user input, and reaching a decision amidst a variety of feedback.<br />
<br />
Facilitators:<br />
:Brussels: Gervase Markham, {{NeedCoFacilitator}}<br />
:Toronto: {{NeedFacilitator}}<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Designing your project for participation===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-designingforparticipation<br />
Nearly all projects will benefit from community involvement; however, there are different approaches and best practices that can better enable a project for wider contributions. This session will capture best practices and challenges to build a project with community involvement.<br />
<br />
Facilitators:<br />
:Brussels: Laura Hilliger or Michelle Thorne (working with Mozilla Reps to help them deliver the community building workshop content)<br />
:Toronto: David Eaves (creator of the community building workshops that includes a 'Designing your project for participation' module) or Emma Irwin (One of the Mozilla Reps who will be delivering the community building workshop content)<br />
:Santa Clara: Benjamin Kerensa (One of the Mozilla Reps who will be delivering the community building workshop content)<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Community tools - what do we currently have===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-communitytools<br />
The topic of tooling seems to be a frequent one. Let's discuss the needs of the various members of the community and determine if there are shared tools in which we as a community should invest.<br />
<br />
Facilitators:<br />
:Brussels: Josh Matthews, William Reynolds (members of the Community Building Systems Working Group)<br />
:Toronto: Michael Hoye (members of the Community Building Systems Working Group)<br />
:Santa Clara: Pierros Papadeas (members of the Community Building Systems Working Group)<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Working with corporate (closed) partners===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-workingwithpartners<br />
How to stay open at Mozilla while meeting our needs: Creating a shared understanding of how Mozilla can work in a closed environment and a roadmap for introducing open concepts to our partners.<br />
<br />
Facilitators:<br />
:Santa Clara {{NeedFacilitator}}<br />
:Brussels: Dietrich Ayala, Mark C&ocirc;t&eacute;<br />
:Toronto: Lawrence Mandel, Lukas Blakk, Bhavana Bajaj<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Workshop on Contributor recognition guide===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-contributorrecognitionguide<br />
Workshop to share tips and tricks for how recognize contributors to your project that would cover badges, swag, events and more. Also hack on the draft Recognition Guide at https://wiki.mozilla.org/Contribute/Recognition<br />
<br />
Facilitator:<br />
:Brussels: Janet Swisher (Community Builder for MDN)<br />
:Toronto: Jeff Beatty (Community Building for l10n)<br />
:Santa Clara: Rosana Ardila (Community Builder for SUMO)<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===The Web in the Mobile Age===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-webinmobileage<br />
What will it take to make the experience of the mobile Web better? How will we make apps and UI's more usable, to make payments smoother, to make the Web as compelling a platform in the mobile world as native apps?<br />
<br />
Facilitator<br />
:Brussels: Tony Santos<br />
:Toronto: {{NeedFacilitator}}<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Moderated discussion on how we will think about product opportunities in the cloud===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-productincloud<br />
Mozilla has a proud history of championing user control of data, but there are both huge user benefits and competitive pressures to having some cloud-enabled data and services. How should Mozilla approach this problem in a way that pushes the mission forward while being pragmatic to the needs of the market?<br />
<br />
Facilitators: <br />
:Brussels: {{NeedFacilitator}}<br />
:Toronto: {{NeedFacilitator}}<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===The future of web gaming===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-futureofwebgaming<br />
The web is poised to become a platform for games, which opens up opportunities for new markets and independent developers. With WebGL, asm.js, and key web API's like Pointer Lock, audio, and video, Mozilla is making the future of web gaming a reality, and creating an open alternative to proprietary technologies like Google's NaCl and Chrome.<br />
<br />
Facilitators:<br />
:Brussels: Vlad Vukicevic<br />
:Toronto: Martin Best<br />
:Santa Clara: Marco Mucci<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Badges and how they can help rethink education===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-badgesrethinkeducation<br />
Working Narrative: With OpenBadges, Mozilla has a combination of technology and market-shaping partners which could shift how people learn, get recognized for their skills, and level up in the game of life. Learn about the OpenBadges project and what it's shooting for.<br />
<br />
Facilitators:<br />
:Brussels: Tim Riches, Emily Goligoski<br />
:Toronto: Jess Klein, Meg Cole, Kerrie Lemoie<br />
:Santa Clara: Sunny Lee, Carla Casilli<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:</div>Pfinchhttps://wiki.mozilla.org/index.php?title=Summit2013/Sessions&diff=706237Summit2013/Sessions2013-09-11T09:03:00Z<p>Pfinch: </p>
<hr />
<div>=What are Supporting Sessions?=<br />
<br />
[https://wiki.mozilla.org/Summit2013/FAQ#What_are_.E2.80.9CSupporting_Sessions.E2.80.9D_and_how_did_they_get_on_the_agenda.3F Link to the general FAQ]<br />
<br />
=Call for Facilitators=<br />
<br />
We need facilitators for the supporting sessions! Anyone can be a facilitator. Here is the list of sessions currently on the agenda for the Mozilla Summit 2013, with facilitators at each location. More information on expectations of facilitators can be found on the [https://wiki.mozilla.org/Summit2013/Sessionfacilitators Session Facilitators wiki]. <br />
<br />
Each proposed session has its own etherpad for discussion and description, if you click through to it. Please add to that pad if you want to suggest specific questions to be addressed within the session.<br />
<br />
Also note there will be open sessions on site which can be signed up for when we are at the summit, "Unconference" style. For more information about how to sign-up to host an open session, please see our [https://wiki.mozilla.org/Summit2013/FAQ FAQ].<br />
<br />
=How to Sign-up?=<br />
<br />
See a session that you would like to facilitate? If so, please '''place your name by the appropriate location next to the session (listed below) on this wiki page.'''<br />
<br />
=Can I Co-facilitate?=<br />
<br />
In general, if you want to Co-facilitate a session, it is frequently possible, reach out to the track owner or to the facilitators themselves.<br />
<br />
=Who are the Track Owners?=<br />
<br />
[[https://wiki.mozilla.org/Summit2013/TrackOwners Track Owners]] for the Summit Are:<br />
<br />
:Mike Hoye (irc: mhoye), People and Process Track, office hours: 2-3 PM Eastern (6-7 PM UTC)<br />
:[[https://mozillians.org/en-US/u/lmandel/ Lawrence Mandel]] (irc: lmandel), Purpose and Strategy Track, office hours: Monday and Tuesday 11-12am Eastern Time.<br />
:[[https://mozillians.org/en-US/u/lshapiro/ Larisa Shapiro]] (irc: lshapiro), Product and Technology Track (and the Innovation Fair) office hours: M-W-F 9-10am Pacific Time<br />
<br />
You can also reach us at:<br />
:IRC: #mozsummit<br />
:Vidyo (during office hours): Summit Track Owners room<br />
<br />
Can't meet during the designated office hours? No problem. Just ping us and we'll set up an alternate time just for you. :)<br />
<br />
Don't know who to reach out to? [https://etherpad.mozilla.org/2013supportingsessions Here] is a list of sessions as they align with the Tracks.<br />
<br />
=Deadline to Sign-up=<br />
<br />
'''The deadline has now been extended - you can add yourself to a session until 12pm Pacific September 11, 2013. Please sign up!'''<br />
<br />
'''After this time, those sessions that do not have a designated facilitator will become open sessions.'''<br />
<br />
=Any Questions?=<br />
<br />
If you have any additional questions, please feel free to reach out to a Track Owner or read through our [https://wiki.mozilla.org/Summit2013/FAQ FAQ].<br />
<br />
=Sessions that need Facilitators=<br />
<br />
*Please note that those sessions that already have facilitators are not included on this list. If you are interested in co-facilitating a session that already has a facilitator, please reach out to them directly. <br />
<br />
==Friday==<br />
<br />
===Ecosystems in our Image===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-ecosystemsinourimage<br />
Put practically and short term: how our values show up in the app ecosystem or social network (where the users are now). And, in the long term, how do our values show up in big data, internet of things and other upcoming ecosystems.<br />
What would it look like to build a mobile apps and content ecosystem based literally on the ideas in the Nature of Mozilla? What features and marketing approaches would you include? How would we most effectively balance building, teaching and shaping markets? Where do local communities fit in as part of building this? Can they help build a long tail app ecosystem where we really see local diversity?<br />
<br />
Facilitators:<br />
:Brussels: {{NeedFacilitator}}, {{NeedCoFacilitator}}<br />
:Toronto: Chris Lawrence, Dan Sinker<br />
:Santa Clara: Alina Mierlus, {{NeedCoFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===The Web We Want===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-thewebwewant<br />
A large, interactive session to explore the web we're championing.What do we mean by "the web"? Is it a technology? A set of values? (also, how is it different from the Internet?) What are the baseline design principles we value most? Privacy? Creativity? User freedom? User Control? Data ownership? Something else? How is the web part of our identity? How do we use our products and our voice to help the broader world--including users--understand the web and become champions with us? <br />
<br />
Facilitators:<br />
:Santa Clara: Asa Dotzler, [[User:Tantek|Tantek Çelik]]<br />
:Brussels: Larissa Co, [[User:Aking|Ozten]]<br />
:Toronto: Potch, [[User:Mcollins|Mike Collins]]<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara: <br />
<br />
Afterwards:<br />
* I've proposed an [[IndieWeb]] Hackspace on the [[Summit2013/Experiences#HackSpaces|Summit2013 Experiences]] wiki page for those that want to actively hack on their own websites and create the web we want by example. - [[User:Tantek|Tantek]] ([[User talk:Tantek|talk]])<br />
<br />
===Building a Web Literate World===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-buildingawebliterateworld<br />
Why the large majority of people on the web should understand how the web works and how are we going to empower them to make it. How we can teach the everyday internet users more skills to improve their online experience and understand how the web works.<br />
<br />
Facilitators: <br />
:Toronto: Marc Lesser, MOUSE, Julia Vallera, Lyre Calliope<br />
:Santa Clara, Sandraghassen Subbaraya Pillai, Ankit Gadgil<br />
:Brussels: Christos Bacharakis, Michael Köhler, Ibrahima SARR<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===What does "Mozillian" mean?===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-meaningofmozillian<br />
A hands-on session to define the identity of Mozillians, historically and as we evolve. Towards building scope and identity as a community. Consider new domains, like news and science. Do partners count? Who do we count? What are we trying to build? Who are we inviting?<br />
<br />
Facilitators: <br />
:Brussels: Gervase Markham, Wilson Guaraca<br />
:Toronto: Guillermo Movia, Andrew (feer56)- Will do second session @2:45<br />
:Santa Clara: Sujith Reddy (would like co facilitator), {{NeedCoFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===How FxOS could change the net in 10 years===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Product and Technology<br />
<br />
https://etherpad.mozilla.org/summit-sessions-friday-fxosin2014<br />
<br />
The strategy and vision for what Firefox OS is trying to accomplish, what markets it's heading for, as well as showcasing the technology and features.<br />
<br />
Facilitators:<br />
:Brussels: Chris Lee, Bill Maggs <br />
:Toronto: Peter Dolanjski, {{NeedCoFacilitator}}<br />
:Santa Clara: Sandip Kamat, Christian Heilmann<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Privacy, Security, and Data: Pragmatic Innovations for Users and the Web===<br />
<br />
Friday, 1-2:15, 2:45-4:00 (please note these sessions are run twice, therefore co-facilitation is recommended)<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-privacysecuritydata<br />
A discussion on how we combine our desire for excellent products, services and UX with leading privacy and security characteristics that advance trust, sustainability and safety for people.<br />
<br />
Facilitators:<br />
:Brussels: Stacy Martin / Garrett Robinson or Brian Smith / [Coates' team rep]<br />
:Toronto: Alex Fowler / Camilo Viecco or Monica Chew / [Coates' team rep]<br />
:Santa Clara: Alina Hua / Sid Stamm / [Coates' team rep]<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
==Saturday==<br />
<br />
===Building through Brand===<br />
<br />
Saturday, 1:00-2:15<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-friday-buildingthroughbrand<br />
NEED DESCRIPTION<br />
<br />
Facilitators (Pete Scanlon to coordinate):<br />
:Brussels: {{NeedFacilitator}}, {{NeedCoFacilitator}}<br />
:Toronto: {{NeedFacilitator}}, {{NeedCoFacilitator}}<br />
:Santa Clara: {{NeedFacilitator}}, {{NeedCoFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Practicing Open===<br />
<br />
Saturday, 1:30-3:30 pm<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-practicingopen<br />
When there's a conflict between openness and businses requirements, how should we, as individuals, navigate that? What resources do we have available for guidance and help?<br />
<br />
Facilitators:<br />
:Toronto: Emma Irwin, Lawrence Kissuki, David Humphrey<br />
:Brussels: Stefania, IoanaChiorean, Gervase Markham<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Mozilla: Winning the Next Three Years===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer, co-facilitators encouraged) <br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-winningnext3years<br />
What does Mozilla need to be doing right now, to move the web forward, to do right by our users, and what are the most important factors to consider in planning the next three years?<br />
<br />
Facilitators:<br />
:Brussels: {{NeedFacilitator}}<br />
:Toronto: Mark Surman<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Winning through Product: Applying the Lessons of Firefox Today===<br />
<br />
Saturday, 1:30 - 3:30pm<br />
<br />
Track: Purpose & Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-winningthroughproduct<br />
NEED DESCRIPTION<br />
<br />
Facilitators:<br />
:Brussels: {{NeedFacilitator}}<br />
:Toronto: Armen Zambrano<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Building a Framework to enable Mozilla to effectively communicate across our community===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer, co-facilitators encouraged)<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-frameworktocommunicate<br />
How does Mozilla hold a discussion on a particular topic that allows expression of positives and negatives in a productive way? This session will build the Mozilla Framework for how to invite feedback, manage the conversation and ensure all parties are acknowledged regardless of their view of the issue.<br />
<br />
Facilitators: <br />
:Brussels: {{NeedFacilitator}}<br />
:Toronto: Lainie Delcoursy<br />
:Santa Clara: Kathryn Meisner<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Defining and Packaging a Mozilla Core experience for onboarding===<br />
<br />
Saturday, 1:30-3:30pm (yes, this one is longer)<br />
<br />
Track: People & Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-mozillacoreforonboarding<br />
How do we create an experience that captures the history of Mozilla, our values, and what makes us unique in a way that we can transfer these items to new Mozillians and even our partners?<br />
<br />
Facilitators:<br />
:Brussels: Rubén Martín [:Nukeador] (one of the Mozilla Hispano mentors that runs the onboarding process for new contributors)<br />
:Toronto: Amie Tyrrel, Amira Dhalla<br />
:Santa Clara: Ankit Gadgil<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===What would a million Mozillians do?===<br />
<br />
Saturday, 1:30-3:30pm (yes, this is a longer session)<br />
<br />
Track: Purpose & Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-whatwould1millmozilliansdo<br />
Working Narrative: A creative, "blue sky" session to imagine new kinds of contributors<br />
<br />
Facilitators: <br />
:Brussels: Brian King (Community Manager for Europe)<br />
:Toronto: Liz Henry (Community Builder for Automation team)<br />
:Santa Clara: David Boswell (currently looking into pilot projects to create new functional and regional communities, such as Mozilla Utah and Mozilla knitters)<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Developing empathy for your users===<br />
<br />
Saturday, 1:30-3:30 (yes, this one is longer)<br />
<br />
Track:<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-empathyforusers <br />
A workshop where you learn how to easily make sure that the products you make are as appreciated as you think they should be.<br />
<br />
Facilitators:<br />
:Brussels: Larissa Co, Maureen Hanratty<br />
:Toronto: Cori Schauer<br />
:Santa Clara: Bill Selman<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Designing for our users not ourselves===<br />
<br />
Saturday, 1:30-3:30 (yes, this one is longer) <br />
<br />
Track: Product & Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-designingforusers<br />
Introduction to our users - who they are, what they do, what they need, and how Mozilla can do this.<br />
<br />
Facilitators:<br />
:Cori Schauer will be main facilitator for this, and will coordinate the other facilitators. <br />
:Brussels: Gemma & Madhava Zhenshuo & Dominik?<br />
:Toronto: Cori & Bryan Clark (possibly Gregg Lind) <br />
:Santa Clara: Bill Selman & Lindsay Kenzig<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Understanding the Servo strategy===<br />
<br />
Saturday, 1:30 - 3:30pm <br />
<br />
Track: Product & Technology <br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-understandingservo <br />
Web browsers were designed around yesterday's reality of computer hardware. Servo is a rethinking of the architecture of browsers to accommodate the hardware of today and tomorrow: multiple CPU's and powerful GPU's, and with limited power consumption. What's more, Servo is being built in [http://en.wikipedia.org/wiki/Rust_%28programming_language%29 Rust], a new programming language designed to support faster and safer development practices.<br />
<br />
Facilitators:<br />
:Brussels: Josh Matthews<br />
:Toronto: Jack Moffitt<br />
:Santa Clara: Patrick Walton<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Who are our users in 2018 and where are they?===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology <br />
<br />
https://etherpad.mozilla.org/summit-sessions-saturday-usersin2018 <br />
<br />
Alternate title: What's not going to change in 2018? What motivations our users will still hold in 10-15 years?<br />
<br />
The world is changing, and we need to build products that work for the next billion users. Who are they, and what are they like?<br />
<br />
Facilitators:<br />
:Brussels: Yuan Wang, Mary Trombley<br />
:Toronto: Cori Schauer<br />
:Santa Clara: Jinghua Zhang, Bill Selman, Lindsay Kenzig,<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Understanding the product strategies of our competition in the eyes of consumers and working through how to compete intelligently===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
https://etherpad.mozilla.org/summit-sessions-saturday-productstrategythroughconsumerseyes<br />
<br />
Powerful interests are creating silos of content and private walled gardens on the web. What can Mozilla do to open these silos up or create new more open alternatives? How do we need to understand how these competitors work for markets and consumers?<br />
<br />
Facilitators: <br />
:Brussels: Patrick Finch {{NeedCoFacilitator}}<br />
:Toronto:{{NeedFacilitator}}<br />
:Santa Clara:{{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Understanding web developers===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
Web developers are a key community for Mozilla. Our competitors are building sophisticated developer tools, API's, and platform technologies. How can we maintain a close and symbiotic relationship with web developers? How do we meet their needs, and how do we get them signed up for Mozilla's mission?<br />
<br />
https://etherpad.mozilla.org/summit-sessions-saturday-understandingdevelopers<br />
<br />
Facilitators: <br />
:Brussels: Jeff Griffiths<br />
:Toronto: Stormy Peters<br />
:Santa Clara: Christian Heilmann<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Growing Stakeholders in the Web===<br />
<br />
Saturday, 4:00 - 6:00pm<br />
<br />
Track: Product & Technology<br />
<br />
The success of the internet depends on commercial activity as well as individual self-expression. To make that work means that we need to understand the perspectives of different stakeholders, from phone manufacturers, to phone companies, to media companies, to consumers. <br />
<br />
Facilitators: <br />
:Brussels: Kat Braybrooke<br />
:Toronto: Marc Lesser, Geoffrey MacDougall<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===The Petri Dish required by scaling innovation===<br />
<br />
Saturday, 4-6pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-petridish <br />
If we're to have the kind of massive impact on the internet that we hope to, we have to ask ourselves whether our structure and processes will get us there. If we want to facilitate innovation at the edges and focus on recognizing good ideas rather than having them, how should we relate to web innovators around the world?<br />
<br />
Facilitators:<br />
:Brussels: David Ascher<br />
:Toronto: Simon Wex <br />
:Santa Clara: Robert Richter<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===WebMaker: Getting People to Take Back The Web===<br />
<br />
Saturday, 4-6 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-saturday-takebacktheweb<br />
<br />
Webmaker is the brand that we're using to tell a new generation of web citizens that the web is theirs to grab, shape and remix. We'll show you what that looks like, and get you activated to help in that effort!<br />
<br />
Facilitators: <br />
:Brussels: Kat Braybrooke, Henrik Mitsch<br />
:Toronto: Amira Dhalla, Chris Lawrence, Matt Thompson <br />
:Santa Clara: Brett Gaylor<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
==Sunday==<br />
<br />
===Distributed Leadership and decision making===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-distributedleadership<br />
A well-facilitated inquiry and skillshare on distributed leadership. Skills Learned: Leadership, Conflict Resolution, Facilitating distributed meetings/planning/group actions. Potential Outline of Session:<br />
# Nature of Mozilla -- one pillar is human capability; more mozillians moving the mission forward<br />
# history of the huge chunks of mozilla that people made up on on their own and we incorporated into the centralized piece<br />
# Some issues with distributed decision-mkaing: risk, mistakes, surprise, messiness<br />
# What do we do now: how we build more APIs to the centralized part of mozilla? <br />
<br />
Facilitators:<br />
:Brussels: Laura Thomson<br />
:Toronto: Regnard Raquedan<br />
:Santa Clara: Alina Mierlus<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Ideas into Action: Next steps for me and my team===<br />
<br />
Sunday, 1:15-2:30<br />
<br />
Track: Purpose and Strategy<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-ideasintoaction<br />
Four breakout sessions with a joint shareback round. Determine what winning looks like as measured by Mozilla's four pillars of activity. Tools, roadmap and things you can do when you return home. How you can adapt the 3-year plan to your local context and the projects you care about. How you can multiply the mission. Skills Learned: Metrics, Building Open into your Project, How to Identify the NoM in your ideas & highlight/promote/grow those<br />
<br />
Facilitators:<br />
:Brussels: Karen Rudnitski<br />
:Toronto: Larissa Shapiro<br />
:Santa Clara: Ernest Chiang<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Decisions, discussions and debate===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-decisionsdiscussionsdebate<br />
A structure for Mozilla to engage our community and reach decisions. Collaboratively building a framework that enables Mozilla to reach decisions in a distributed decentralized organization. This session will determine an agreed upon best practice framework for inviting discussion, acknowledging user input, and reaching a decision amidst a variety of feedback.<br />
<br />
Facilitators:<br />
:Brussels: Gervase Markham, {{NeedCoFacilitator}}<br />
:Toronto: {{NeedFacilitator}}<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Designing your project for participation===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-designingforparticipation<br />
Nearly all projects will benefit from community involvement; however, there are different approaches and best practices that can better enable a project for wider contributions. This session will capture best practices and challenges to build a project with community involvement.<br />
<br />
Facilitators:<br />
:Brussels: Laura Hilliger or Michelle Thorne (working with Mozilla Reps to help them deliver the community building workshop content)<br />
:Toronto: David Eaves (creator of the community building workshops that includes a 'Designing your project for participation' module) or Emma Irwin (One of the Mozilla Reps who will be delivering the community building workshop content)<br />
:Santa Clara: Benjamin Kerensa (One of the Mozilla Reps who will be delivering the community building workshop content)<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Community tools - what do we currently have===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-communitytools<br />
The topic of tooling seems to be a frequent one. Let's discuss the needs of the various members of the community and determine if there are shared tools in which we as a community should invest.<br />
<br />
Facilitators:<br />
:Brussels: Josh Matthews, William Reynolds (members of the Community Building Systems Working Group)<br />
:Toronto: Michael Hoye (members of the Community Building Systems Working Group)<br />
:Santa Clara: Pierros Papadeas (members of the Community Building Systems Working Group)<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Working with corporate (closed) partners===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-workingwithpartners<br />
How to stay open at Mozilla while meeting our needs: Creating a shared understanding of how Mozilla can work in a closed environment and a roadmap for introducing open concepts to our partners.<br />
<br />
Facilitators:<br />
:Santa Clara {{NeedFacilitator}}<br />
:Brussels: Dietrich Ayala, Mark C&ocirc;t&eacute;<br />
:Toronto: Lawrence Mandel, Lukas Blakk, Bhavana Bajaj<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Workshop on Contributor recognition guide===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: People and Process<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-contributorrecognitionguide<br />
Workshop to share tips and tricks for how recognize contributors to your project that would cover badges, swag, events and more. Also hack on the draft Recognition Guide at https://wiki.mozilla.org/Contribute/Recognition<br />
<br />
Facilitator:<br />
:Brussels: Janet Swisher (Community Builder for MDN)<br />
:Toronto: Jeff Beatty (Community Building for l10n)<br />
:Santa Clara: Rosana Ardila (Community Builder for SUMO)<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===The Web in the Mobile Age===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-webinmobileage<br />
What will it take to make the experience of the mobile Web better? How will we make apps and UI's more usable, to make payments smoother, to make the Web as compelling a platform in the mobile world as native apps?<br />
<br />
Facilitator<br />
:Brussels: Tony Santos<br />
:Toronto: {{NeedFacilitator}}<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Moderated discussion on how we will think about product opportunities in the cloud===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-productincloud<br />
Mozilla has a proud history of championing user control of data, but there are both huge user benefits and competitive pressures to having some cloud-enabled data and services. How should Mozilla approach this problem in a way that pushes the mission forward while being pragmatic to the needs of the market?<br />
<br />
Facilitators: <br />
:Brussels: {{NeedFacilitator}}<br />
:Toronto: {{NeedFacilitator}}<br />
:Santa Clara: {{NeedFacilitator}}<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===The future of web gaming===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-futureofwebgaming<br />
The web is poised to become a platform for games, which opens up opportunities for new markets and independent developers. With WebGL, asm.js, and key web API's like Pointer Lock, audio, and video, Mozilla is making the future of web gaming a reality, and creating an open alternative to proprietary technologies like Google's NaCl and Chrome.<br />
<br />
Facilitators:<br />
:Brussels: Vlad Vukicevic<br />
:Toronto: Martin Best<br />
:Santa Clara: Marco Mucci<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:<br />
<br />
===Badges and how they can help rethink education===<br />
<br />
Sunday, 1:15-2:30 pm<br />
<br />
Track: Product and Technology<br />
<br />
*https://etherpad.mozilla.org/summit-sessions-sunday-badgesrethinkeducation<br />
Working Narrative: With OpenBadges, Mozilla has a combination of technology and market-shaping partners which could shift how people learn, get recognized for their skills, and level up in the game of life. Learn about the OpenBadges project and what it's shooting for.<br />
<br />
Facilitators:<br />
:Brussels: Tim Riches, Emily Goligoski<br />
:Toronto: Jess Klein, Meg Cole, Kerrie Lemoie<br />
:Santa Clara: Sunny Lee, Carla Casilli<br />
<br />
Session Wiki Pages:<br />
:Brussels: <br />
:Toronto: <br />
:Santa Clara:</div>Pfinchhttps://wiki.mozilla.org/index.php?title=MozCampEU2012/Buddyprogram/PatrickFinch&diff=466392MozCampEU2012/Buddyprogram/PatrickFinch2012-08-31T17:53:11Z<p>Pfinch: /* Link to My Mozillians/Reps/Twitter Accounts */</p>
<hr />
<div>=Name=<br />
Patrick Finch<br />
=Link to My Mozillians/Reps/Twitter Accounts=<br />
[http://twitter.com/patrickf Twitter: @patrickf] [https://mozillians.org/en-US/pfinch Mozillians: pfinch]<br />
<br />
==What is the overall goal I want to accomplish by attending MozCamp Europe==<br />
At MozCamp Europe 2012 I'm hoping to find people who want to help work on strategy for Firefox on the desktop, and who can help me quantify user needs, and who have big ideas for Fennec, Firefox OS and the Marketplace. If you have ideas in this direction, or data, or an interest in getting data, give me a shout.<br />
<br />
<br />
[[Category:MozCampEU2012Buddy]]</div>Pfinchhttps://wiki.mozilla.org/index.php?title=MozCampEU2012/Buddyprogram/PatrickFinch&diff=466385MozCampEU2012/Buddyprogram/PatrickFinch2012-08-31T17:46:11Z<p>Pfinch: /* Link to My Mozillians/Reps/Twitter Accounts */</p>
<hr />
<div>=Name=<br />
Patrick Finch<br />
=Link to My Mozillians/Reps/Twitter Accounts=<br />
[http://twitter.com/patrickf @patrickf] [https://mozillians.org/en-US/pfinch pfinch on Mozillians]<br />
<br />
==What is the overall goal I want to accomplish by attending MozCamp Europe==<br />
At MozCamp Europe 2012 I'm hoping to find people who want to help work on strategy for Firefox on the desktop, and who can help me quantify user needs, and who have big ideas for Fennec, Firefox OS and the Marketplace. If you have ideas in this direction, or data, or an interest in getting data, give me a shout.<br />
<br />
<br />
[[Category:MozCampEU2012Buddy]]</div>Pfinchhttps://wiki.mozilla.org/index.php?title=MozCampEU2012/Buddyprogram/PatrickFinch&diff=466383MozCampEU2012/Buddyprogram/PatrickFinch2012-08-31T17:45:00Z<p>Pfinch: </p>
<hr />
<div>=Name=<br />
Patrick Finch<br />
=Link to My Mozillians/Reps/Twitter Accounts=<br />
[http://twitter.com/patrickf @patrickf]<br />
<br />
==What is the overall goal I want to accomplish by attending MozCamp Europe==<br />
At MozCamp Europe 2012 I'm hoping to find people who want to help work on strategy for Firefox on the desktop, and who can help me quantify user needs, and who have big ideas for Fennec, Firefox OS and the Marketplace. If you have ideas in this direction, or data, or an interest in getting data, give me a shout.<br />
<br />
<br />
[[Category:MozCampEU2012Buddy]]</div>Pfinchhttps://wiki.mozilla.org/index.php?title=MozCampEU2012/Buddyprogram/PatrickFinch&diff=466372MozCampEU2012/Buddyprogram/PatrickFinch2012-08-31T17:36:12Z<p>Pfinch: Created page with "<h1>[Patrick Finch https://mozillians.org/en-US/pfinch]</h1> <h1></h1> <h1>At MozCamp Europe 2012 I'm hoping to find people who want to help work on strategy for Firefox on the d..."</p>
<hr />
<div><h1>[Patrick Finch https://mozillians.org/en-US/pfinch]</h1><br />
<h1></h1><br />
<h1>At MozCamp Europe 2012 I'm hoping to find people who want to help work on strategy for Firefox on the desktop, and who can help me quantify user needs, and who have big ideas for Fennec, Firefox OS and the Marketplace.</h1><br />
<br />
[[Category:MozCampEU2012Buddy]]</div>Pfinchhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2012-04-30&diff=425556WeeklyUpdates/2012-04-302012-04-30T14:28:53Z<p>Pfinch: /* Introducing New Hires */</p>
<hr />
<div><small>[[WeeklyUpdates/{{#time:Y-m-d|{{SUBPAGENAME}} -1 week}}|« previous week]] | [[WeeklyUpdates|index]] | [[WeeklyUpdates/{{#time:Y-m-d|{{SUBPAGENAME}} +1 week}}|next week »]]</small><br />
<br />
{{conf|8600}}<br />
<br />
__TOC__<br />
<br />
= All-hands Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live all-hand status meeting.<br />
<br />
== Friends of the Tree [[Image:Tree.gif|Friends of the Tree]] ==<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
<br />
Privacy Friends Meeting, 1pm in San Francisco (7N) and Mountain View (Kung Fu) - Vidyo in to 7N. Contact Stacy Martin for more info.<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
*Thor Muller, Author of [http://getluckythebook.com "Get Lucky: How to Put Planned Serendipity to Work for You"] will be talking about his book.<br><br />
**noon-1pm PT 10FWD and air mozilla<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
* [[Grow/Meeting_05_03_12|Grow Mozilla meeting]] at 10 pacific - a forum to discuss ideas and ask questions about community building.<br />
* [http://www.portigal.com Steve Portigal] - Rethink Your Research Approach & Synthesize Your Findings Faster - part of UX Lecture Series.<br><br />
**noon-1pm PT 10FWD and air mozilla<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
== Product Status Updates (voice updates) ==<br />
<br />
=== Firefox Future (12, 13, 14) ===<br />
''Speaker Location:''<br />
<br />
=== Firefox Current ===<br />
''Speaker Location:''<br />
<br />
=== Mobile Firefox ===<br />
''Speaker Location:'' <br />
<br />
=== Thunderbird ===<br />
''Speaker Location:'' <br />
<br />
=== Older Branch Work ===<br />
''Speaker Location:'' <br />
<br />
=== Drumbeat ===<br />
''Speaker Location:''<br />
<br />
=== Identity ===<br />
''Speaker Location:''<br />
<br />
=== Services ===<br />
''Speaker Location:''<br />
<br />
== Speakers ==<br />
<br />
The limit is 3 minutes per speaker. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation.<br />
<br />
{| class="fullwidth-table"<br />
|-<br />
! Title<br />
! Presenter<br />
! Topic<br />
! Media<br />
! More Details<br />
|-<br />
| Inside the Root Shell<br />
| Brandon Burton, via Vidyo<br />
| A new weekly interview series with Mozilla IT, starting May 7th.<br />
| N/A<br />
| Email insidetherootshell@mozilla.com with questions you'd like to know about Mozilla IT folks.<br />
|-<br />
|}<br />
<br />
== Introducing New Hires ==<br />
{| class="fullwidth-table"<br />
|-<br />
! New Hire<br />
! Introduced by<br />
! Speaker location<br />
! Will be working on<br />
|-<br />
| ''Who is the new hire?''<br />
| ''Who will be introducing that person?''<br />
| ''From which office will that introduction be transmitted?''<br />
| ''What will the new person be working on?''<br />
|-<br />
| Diana Livits<br />
| Dave Slater<br />
| Mountain View<br />
| Partner Relationships for Mozilla Marketplace<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
|}<br />
<br />
== Introducing New Interns ==<br />
{| class="fullwidth-table"<br />
|-<br />
! New Intern<br />
! Introduced by<br />
! Speaker location<br />
! Will be working on<br />
|-<br />
| ''Who is the new intern?''<br />
| ''Who will be introducing that person?''<br />
| ''From which office will that introduction be transmitted?''<br />
| ''What will the new person be working on?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
|}<br />
<br />
== Roundtable ==<br />
<br />
= &lt;meta&gt; =<br />
<br />
Notes and non-voice status updates that aren't part of the live meeting go here.<br />
<br />
== Status Updates By Team (*non-voice* updates) ==<br />
<br />
=== IT ===<br />
* '''''developer.mozilla.org will be down on Tuesday, May 8th for a move to the new data center'''''<br />
* moved cvs.mozilla.org to SCL3 - file any issues under mozilla.org - Server Operations : Developer Services<br />
* prep new product distribution environment in SCL3, plan to move this week<br />
* work on moving MXR out of SJC1, see post to mozilla.dev.planning for details and how to help test<br />
* begin work on a multi-homed AMO/Marketplace environment by extending the db master to a M-M setup between Phoenix and Santa Clara<br />
* dealt with more load balancer issues in Phoenix, came up with a combination of Zeus and Myricom 10g NICs that appears to work well<br />
<br />
=== Firefox ===<br />
<br />
=== Platform ===<br />
<br />
=== Services ===<br />
<br />
=== Messaging ===<br />
<br />
=== Mobile ===<br />
<br />
=== Release Engineering ===<br />
<br />
=== QA ===<br />
<br />
==== Test Execution ====<br />
<br />
==== WebQA ====<br />
<br />
==== QA Community ====<br />
<br />
==== Automation Services ====<br />
<br />
=== Automation & Tools ===<br />
<br />
=== Security ===<br />
<br />
=== Engagement ===<br />
<br />
==== PR ====<br />
<br />
==== Events ====<br />
<br />
==== Creative Team ====<br />
<br />
==== Community Marketing ====<br />
<br />
=== Support ===<br />
<br />
=== Metrics ===<br />
<br />
=== Evangelism ===<br />
<br />
=== Labs ===<br />
<br />
=== Apps ===<br />
<br />
=== Developer Tools ===<br />
<br />
=== Add-ons ===<br />
<br />
=== Webdev ===<br />
<br />
=== L10n ===<br />
<br />
=== People Team ===<br />
<br />
=== WebFWD ===<br />
Learn more about our teams when they are in town in mid-May! <br />
<br />
1) On Saturday May 12 we'll be having an "open workday" allowing anyone to contribute to our teams - in-person in Mountain View or remotely via AirMozilla & IRC. Details at http://webfwdopenworkday.eventbrite.com/<br />
<br />
2) On Monday May 14 our teams will present brief lightning talks at the All-Hands Meeting.<br />
<br />
== Foundation Updates ==</div>Pfinchhttps://wiki.mozilla.org/index.php?title=RapidRelease/ImpactAssessment&diff=376796RapidRelease/ImpactAssessment2011-12-07T23:26:31Z<p>Pfinch: /* Market/Product Impacts */</p>
<hr />
<div>= Preamble =<br />
<br />
We've made the change to a regular schedule of releases. This is a massive win for our ability to compete. We can deliver new features and fixes to users much more quickly. We can upgrade the web on a continuous basis and respond to changes we see with agility. We can execute better on our mission.<br />
<br />
The central benefits of our release schedule aren't the subject of this review. We are keen, though, to ensure we've identified any challenges that this process has introduced. In some cases, we are already well underway on addressing them. In others, we may decide no change is needed at this time. In still others, we may not know the problem exists until someone tells us.<br />
<br />
Please help us fully understand the impact of our new process so that we can make smart adjustments where appropriate. If you have concerns you don't see addressed below, please add them, or email and I'll add them.<br />
<br />
The owner of this document is Johnathan Nightingale.<br />
<br />
= Market/Product Impacts =<br />
<br />
The most important drivers of change in our process should be the impacts our process has on our users and the web.<br />
<br />
== User Experience ==<br />
=== Update Pain ===<br />
'''Impact''': Firefox updates result in several kinds of distracting interactions that bother our users. These include Firefox internal prompts, ecosystem impacts like add-on compatibility, and OS level interference from things like the Windows UAC security system. Some of these are specific to the major version increments in the new process, some of them have happened all along, even for minor releases. The net effect is a terrible user experience, distraction for our users, and a resistance to apply updates which harms our ability to deliver great software.<br />
<br />
'''Resolution''': There are several pieces of work needed to address this impact:<br />
* Eliminating or adjusting our own prompts. This work is largely complete or in progress.<br />
* Add-on compatibility is an area of considerable investment, described below<br />
* Eliminating OS-level interruptions. This work is underway and targeted at early 2012 release. It goes well beyond reducing our level of update annoyance to FF4 levels, in many cases silencing 100% of the interruptions that updates represent (something Firefox has never been capable of previously).<br />
<br />
=== Update Frequency ===<br />
'''Impact:''' We currently ship a release every 6 weeks, barring exceptional circumstance, but it is not clear whether this is the optimum schedule.<br />
<br />
* An accelerated schedule (e.g. every 4-5 weeks) would reduce the amount of change that each release represents, likely resulting in better risk management. It would also shorten the time to market for new features. However a shorter cycle would amplify many of the impacts discussed in this document.<br />
<br />
* A longer release cycle (e.g. 8-10 weeks) would, by contrast, likely dampen the effect of many of the impacts documented here. Each release would have a larger set of features for users and web developers, albeit with greater associated code and integration risk.<br />
<br />
* A significantly longer release cycle (e.g. 3 months) would require us to build an alternate mechanism for delivering security updates, in addition to the costs outlined above. One suggestion has been to syncopate, with security-only releases interwoven with "feature" releases, however these proposals have thus far lacked a clear plan for how testing would accommodate the two streams (particularly since the feature releases would now have twice as much change to test within the same time frame).<br />
<br />
* Right now our development, stabilization, and beta testing phases are of equal length. Moving to a shorter or longer cycle may work better for some phases and worse for others. If, f.e. we moved to 10 weeks of dev, would we also need 10 weeks of stabilization and 10 weeks of beta? <br />
<br />
'''Unresolved''': This topic requires specific discussion and planning, as the various options have a complex set of costs and benefits.<br />
<br />
=== Channel Confusion ===<br />
'''Impact''': The current model has four channels: Nightly, Aurora, Beta and Release. This many channels may be a source of confusion for users. This is particularly true for mobile, where Release and Beta are in the android market, but Nightly and Aurora are available only through sideloading/direct download.<br />
* Are our channels providing us the coverage we need?<br />
* Are our channels providing users the right offer to attract the coverage we need?<br />
* Would three channels work as well as four and carry less confusion?<br />
* Are we capable of differentiating and sustaining four channels?<br />
<br />
'''Unresolved''': This may not be an issue, or may be an issue only on mobile, but in any case requires a more detailed discussion.<br />
* As a "non-urgent" topic, differentiating and growing these distinct channels has not had much focused investment to date.<br />
* Product Marketing is developing and pushing an Aurora program to strengthen that channel, and work with SUMO to build a support community around Aurora.<br />
<br />
== Firefox Ecosystem ==<br />
=== Add-on Compatibility ===<br />
'''Impact''': Firefox add-ons check compatibility based on version number, and our new release process changes version numbers frequently, resulting in significant problems with compatibility. Our add-on ecosystem is a central competitive advantage for Mozilla, and something we value highly, as do our users. Concerns about add-on compatibility occur frequently in feedback about upgrades. (It's not just about the version revs, it's that we actually rev XUL "API"s a lot more frequently too.) <br />
<br />
'''Resolution''': We are addressing this issue in several ways:<br />
* Automated compatibility checking for AMO hosted add-ons. This is complete, and results in very high compatibility rates from one version of Firefox to the next.<br />
* Third party add-on opt-in. In Firefox 8 we shipped support for informing users when a third party installs add ons and asks for explicit consent. We believe that a significant portion of incompatible, non-AMO add-ons are installed without our users' understanding. Making this choice explicit for users will allow them to disable addons they don't want, removing them from the list of add-ons that will warn about compatibility.<br />
* Changing Firefox's code to treat addons as compatible by default. This work is largely complete, but not yet enabled in shipping Firefox builds and it's not clear what level of compatibility among "dark matter" add-ons that this will get us. <br />
<br />
'''Unresolved''':<br />
* We have not yet articulated a clear strategy for add-ons with binary components, who will not be helped by the compatible-by-default work mentioned above.<br />
* We haven't resolved how we're going to ensure the best possible blacklist or mitigation for when the blacklist misses a bad add-on.<br />
<br />
=== Enterprise ===<br />
'''Impact''': Enterprise practices for qualifying software deployments require significantly longer windows than our release cycle accommodates. As a result, they have expressed significant concern about their ability to continue supporting Firefox. This loses us goodwill, but also means we are failing to serve a significant number of users.<br />
<br />
'''Resolution''': Kev Needham is driving the creation of an Extended Support Release version of Firefox, in consultation with our community and the revived Enterprise Working Group. The proposal is near completion, and EWG participants seem supportive.<br />
<br />
'''Unresolved''': While the handful of EWG participants seem supportive, we have no real data on whether this will be an effective program -- especially for education and public sectors which are not well represented on the EWG and may have different requirements.<br />
<br />
<br />
=== Market Support for Deprecated Fx Versions ===<br />
'''Impact''': Some site operators, notable [http://gmailblog.blogspot.com/2011/06/our-plans-to-support-modern-browsers.html Google] may adopt a policy of only supporting current and previous major versions of browsers, meaning that Firefox users on relatively recent browser may find themselves shut out of certain web services even though their browser is technically capable of supporting them.<br />
<br />
'''Resolution''': Ultimate resolution is to deliver silent updates and then work with the user base to migrate them to that train. This will likely be an iterative process, with a final push after silent updates to Firefox ship. In some respects, there is an opportunity to work with site operators to migrate the Firefox user base to latest versions. <br />
<br />
'''Unresolved''': Impact is currently theoretical, and resolution should come in 2012.<br />
<br />
<br />
== Perceptions of the Project ==<br />
<br />
=== Version Number Inflation ===<br />
'''Impact''': Some industry followers, and especially web developers and site owners, have expressed concerns about Firefox's major numbering convention. The merits of major version numbering by default, (allowing for the possibility of new features in every release) do not necessarily communicate themselves, and with Chrome and IE both iterating their version numbers more quickly than they have in the past, a sense lingers in some parts that version numbers are being iterated for user-facing "marketing purposes", and that the project is placing the most superficial of concerns above the needs of users and developers.<br />
<br />
'''Resolution''': A concerted communication about this topic seems unlikely to generate much more understanding as the topic is a nuanced one. The market will gradually adapt to the Firefox and Chrome schemas, but this will only be resolved once the wisdom of updating version numbers is proven.<br />
<br />
'''Unresolved''': Evangelism and online engagement can only do so much; but likely our efforts have not been concentrated on addressing this misconception. This should be addressed over time as new features ship and the differences between versions become more meaningful for developers and less meaningful for users.<br />
<br />
= Internal/Project Impacts =<br />
<br />
Second to user impact, but still important, are the challenges our process presents for our own ability to build, ship, and communicate about Firefox.<br />
<br />
== Localization ==<br />
=== Potential Missed Cycles ===<br />
'''Impact''': While recent feedback shows a slight majority (55%) of localizers prefer the new process, some smaller locales worry that they might miss a cycle and leave users stranded.<br />
<br />
'''Resolution''': This concern can be mitigated in some cases by shipping the locale with the new strings untranslated. We have done this already in a few cases where the newly added strings were in low-visibility parts of the product, like the about:permissions prototype.<br />
<br />
=== Per-Release Overhead ===<br />
'''Impact:''' There is a fixed cost associated with spinning up each new release's translation work. This administrative cost is incurred regardless of the number of strings needing translation. This gives localizers the sense that they are burning more time on tiresome administration instead of actual localization.<br />
<br />
'''Unresolved''': This issue has not been resolved, though it suggests finding ways to reduce the administrative burden where possible.<br />
<br />
== Product Management ==<br />
* Delivering collections of features in a single release is more difficult with shorter cycles than longer cycles. This isn't important for all features, but some collections are bigger than the sum of their parts.<br />
* If all features must ride the trains, that's a minimum of 3 months of the feature being in public builds which may allow competitors to scoop us on features. This isn't important for all features, but could matter for some.<br />
<br />
== Product Marketing ==<br />
=== Focused Communications and Messaging around Feature Collections ===<br />
'''Impact''': The strength of our outward communications has been greatly challenged by the new release process. This is an issue because Mozilla is much more reliant upon earned media (PR/news) rather than paid media (advertising). So, when things happen, we have to capitalize. As Product notes, it is very difficult to deliver a collection or set of themed features in a single release. This in turn, makes it very hard to articulate product narrative or theme with each update. As a result, we're forced to lean on "laundry list" approach to messaging which greatly dilutes the outward communication's strength and positioning. <br />
<br />
'''Resolution''': This concern will be addressed when we move to silent updates. Having silent updates will allow us the flexibility to to wait for a set of features to land and to create messaging around certainthemes instead of having a release define the themes for us. This should enable us to have stronger, more targeted messages that will strengthen<br />
positioning in the market. To be clear, we will still make lots of noise when major features land, but this model allows us to have clearer, more concise messaging and to pick and choose what features we talk about. Until silent updates land, we will continue with our current messaging and communications approach. <br />
<br />
=== Building Development Channels ===<br />
'''Impact''': As noted above, there is a lot of discussion around the development channels, especially the value add of Aurora and Beta. We have an opportunity with release channels to grow a new brand to target influencers. Having a much more precise relationship with early adopters will be enormously beneficial, but requires investment.<br />
* The PMM team is currently working on building the Aurora user base, but part of the issue we're seeing is that users aren't seeing game-changing features land in Aurora (as PMs also mention above), making it hard to distinguish it from the rest of the channels available. We know that many key features are landing soon, but the lack key feature additions in our releases right now is impeding channel differentiation, and in effect, impeding the growth of the Firefox Aurora channel. This will be an issue regardless of how many channels we have, but it should be noted that the growth of this channel will correlate with the impact of the features we land.<br />
* The Beta Channel in our current scheme has very little differentiation because right now it serves as the "more stable Aurora". Although the current focus is on building Aurora, we will see issues when we try to build the Beta channel because of the lack of channel differentiation. <br />
<br />
'''Resolution''': Unresolved. As mentioned above, a larger discussion needs to happen around release channels.<br />
<br />
=== Staying Up to Date with Product Changes ===<br />
'''Impact''': It's very difficult for the PMM team (and other down stream teams) to stay up to date with what features that are being added, removed or held in each release. The Release Tracking Page is useful, but many are not up to date, particularly for Platform features. This has improved overall, but this is still an issue especially as many decisions are made during triage meetings that many are not able to attend. We lack a uniform communications process to make sure the decisions made in Triage are communicated out to downstream teams on a consistent basis. To be clear, this isn't a new struggle--this was also a problem before the move to the new release release, its just been exacerbated by the faster<br />
release process, especially if the feature pages are out of date. We also don't expect 100% compliance, but stakeholders should understand the need behind these pages to help (perhaps?) create an expectation of the "normal" feature development process. <br />
<br />
'''Resolution''': Unresolved. This issue has not been resolved and will likely need input from PMs, Project Managers and Engineering to find a better process. <br />
<br />
=== Feature Pages are Incomplete ===<br />
'''Impact''': Many feature pages are out of date or do not include the necessary information to define the feature, use case or explanation of the feature. This is particularly true of platform features that lack explanations that non-techie, down stream teams need to be able to use the feature pages properly.<br />
<br />
'''Resolution''': Unresolved. This is something that the Release Tracking page owners, PMM<br />
and the platform team will need to discuss.<br />
<br />
== Press and Public Relations ==<br />
<br />
== Engineering ==<br />
<br />
=== Review bandwidth ===<br />
'''Impact''': We have preliminary data from Martin Best's work that suggests review backlogs may have been growing disproportionately since the introduction of the new process. It's not immediately clear what is driving this but, if true, it would suggest a need for changes in our development process to avoid languishing in bugzilla instead of shipping, which threatens product quality and agility.<br />
<br />
'''Unresolved''': Research is ongoing<br />
<br />
=== Bug Triage ===<br />
'''Impact''': We have preliminary data from Martin Best's work that shows a growing backlog of untriaged bugs. This might suggest we are missing important bugs due to a lack of resources applied to triage, which threatens product quality.<br />
<br />
'''Unresolved''': Research is ongoing<br />
<br />
=== Quality Measurement ===<br />
'''Impact''': Independent of triage in particular, we are concerned that our current process does not adequately detect breakage during the Nightly->Aurora->Beta migration. We note that so far each rapid release we've shipped has required at least one chemspill (see below), albeit in 2 of 4 cases this was due to third party code change or vulnerabilities that would not have been detectable during testing.<br />
<br />
'''Resolution'''<br />
* Lucas Adamski is driving an effort to build a set of quality programs which should allow us to track things more closely and detect issues sooner<br />
* Early detection would also be helped by larger testing populations on our Aurora and Beta channels. Growing these populations is a priority for the product marketing organization.<br />
<br />
'''Unresolved''': In several cases (e.g. crashes), we do have the metrics now to be able to gauge trends and compare our prior monolithic releases with our new scheduled ones. I'll need to gather this data.<br />
<br />
=== Emergency Response ===<br />
'''Impact''': Each release under the new model has required a chemspill response at some point during its lifetime. Only half of these were a result of bugs in mozilla code, but it nevertheless remains the case that we have a frequent need to address bugs between scheduled releases. Chemspills are resource intensive and, because they involve deploying new client software for the affected users, can result in significant interruption and annoyance for our users.<br />
<br />
'''Resolution''': Christian Legnitto and Dave Townsend have proposed and built support for a new "hot fix" add-on in Firefox to eliminate many situations where we would otherwise require a chemspill. If the chemspill is something that an add-on can address, we can package and deliver code through our daily add-on update system which can address the issue until an actual fix is delivered in a subsequent Firefox release. While hotfixes still require QA and testing and validation, they can be delivered without the full machinery of a release, making us both more agile and less irritating. In most cases, the download, install, and activation of a hotfix would be completely invisible to users.<br />
<br />
= Contributors =<br />
<br />
This is the list of people who have contributed, or been invited to contribute, to this process review. If I've forgotten you, please add your name below.<br />
<br />
* Johnathan Nightingale - Firefox Engineering<br />
* Christian Legnitto - Release Management<br />
* Asa Dotzler - Desktop Product Management (in progress)<br />
* Erica Jostedt - Product PR (in progress)<br />
* Laura Mesa - Product Marketing<br />
* Chris Hofmann - Localization<br />
* Axel Hecht - Localization (in progress)<br />
* Sheila Mooney - Engineering Project Management (in progress)<br />
* Patrick Finch - Product Marketing</div>Pfinchhttps://wiki.mozilla.org/index.php?title=RapidRelease/ImpactAssessment&diff=376791RapidRelease/ImpactAssessment2011-12-07T23:18:04Z<p>Pfinch: /* Contributors */</p>
<hr />
<div>= Preamble =<br />
<br />
We've made the change to a regular schedule of releases. This is a massive win for our ability to compete. We can deliver new features and fixes to users much more quickly. We can upgrade the web on a continuous basis and respond to changes we see with agility. We can execute better on our mission.<br />
<br />
The central benefits of our release schedule aren't the subject of this review. We are keen, though, to ensure we've identified any challenges that this process has introduced. In some cases, we are already well underway on addressing them. In others, we may decide no change is needed at this time. In still others, we may not know the problem exists until someone tells us.<br />
<br />
Please help us fully understand the impact of our new process so that we can make smart adjustments where appropriate. If you have concerns you don't see addressed below, please add them, or email and I'll add them.<br />
<br />
The owner of this document is Johnathan Nightingale.<br />
<br />
= Market/Product Impacts =<br />
<br />
The most important drivers of change in our process should be the impacts our process has on our users and the web.<br />
<br />
== User Experience ==<br />
=== Update Pain ===<br />
'''Impact''': Firefox updates result in several kinds of distracting interactions that bother our users. These include Firefox internal prompts, ecosystem impacts like add-on compatibility, and OS level interference from things like the Windows UAC security system. Some of these are specific to the major version increments in the new process, some of them have happened all along, even for minor releases. The net effect is a terrible user experience, distraction for our users, and a resistance to apply updates which harms our ability to deliver great software.<br />
<br />
'''Resolution''': There are several pieces of work needed to address this impact:<br />
* Eliminating or adjusting our own prompts. This work is largely complete or in progress.<br />
* Add-on compatibility is an area of considerable investment, described below<br />
* Eliminating OS-level interruptions. This work is underway and targeted at early 2012 release. It goes well beyond reducing our level of update annoyance to FF4 levels, in many cases silencing 100% of the interruptions that updates represent (something Firefox has never been capable of previously).<br />
<br />
=== Update Frequency ===<br />
'''Impact:''' We currently ship a release every 6 weeks, barring exceptional circumstance, but it is not clear whether this is the optimum schedule.<br />
<br />
* An accelerated schedule (e.g. every 4-5 weeks) would reduce the amount of change that each release represents, likely resulting in better risk management. It would also shorten the time to market for new features. However a shorter cycle would amplify many of the impacts discussed in this document.<br />
<br />
* A longer release cycle (e.g. 8-10 weeks) would, by contrast, likely dampen the effect of many of the impacts documented here. Each release would have a larger set of features for users and web developers, albeit with greater associated code and integration risk.<br />
<br />
* A significantly longer release cycle (e.g. 3 months) would require us to build an alternate mechanism for delivering security updates, in addition to the costs outlined above. One suggestion has been to syncopate, with security-only releases interwoven with "feature" releases, however these proposals have thus far lacked a clear plan for how testing would accommodate the two streams (particularly since the feature releases would now have twice as much change to test within the same time frame).<br />
<br />
* Right now our development, stabilization, and beta testing phases are of equal length. Moving to a shorter or longer cycle may work better for some phases and worse for others. If, f.e. we moved to 10 weeks of dev, would we also need 10 weeks of stabilization and 10 weeks of beta? <br />
<br />
'''Unresolved''': This topic requires specific discussion and planning, as the various options have a complex set of costs and benefits.<br />
<br />
=== Channel Confusion ===<br />
'''Impact''': The current model has four channels: Nightly, Aurora, Beta and Release. This many channels may be a source of confusion for users. This is particularly true for mobile, where Release and Beta are in the android market, but Nightly and Aurora are available only through sideloading/direct download.<br />
* Are our channels providing us the coverage we need?<br />
* Are our channels providing users the right offer to attract the coverage we need?<br />
* Would three channels work as well as four and carry less confusion?<br />
* Are we capable of differentiating and sustaining four channels?<br />
<br />
'''Unresolved''': This may not be an issue, or may be an issue only on mobile, but in any case requires a more detailed discussion.<br />
* As a "non-urgent" topic, differentiating and growing these distinct channels has not had much focused investment to date.<br />
* Product Marketing is developing and pushing an Aurora program to strengthen that channel, and work with SUMO to build a support community around Aurora.<br />
<br />
== Firefox Ecosystem ==<br />
=== Add-on Compatibility ===<br />
'''Impact''': Firefox add-ons check compatibility based on version number, and our new release process changes version numbers frequently, resulting in significant problems with compatibility. Our add-on ecosystem is a central competitive advantage for Mozilla, and something we value highly, as do our users. Concerns about add-on compatibility occur frequently in feedback about upgrades. (It's not just about the version revs, it's that we actually rev XUL "API"s a lot more frequently too.) <br />
<br />
'''Resolution''': We are addressing this issue in several ways:<br />
* Automated compatibility checking for AMO hosted add-ons. This is complete, and results in very high compatibility rates from one version of Firefox to the next.<br />
* Third party add-on opt-in. In Firefox 8 we shipped support for informing users when a third party installs add ons and asks for explicit consent. We believe that a significant portion of incompatible, non-AMO add-ons are installed without our users' understanding. Making this choice explicit for users will allow them to disable addons they don't want, removing them from the list of add-ons that will warn about compatibility.<br />
* Changing Firefox's code to treat addons as compatible by default. This work is largely complete, but not yet enabled in shipping Firefox builds and it's not clear what level of compatibility among "dark matter" add-ons that this will get us. <br />
<br />
'''Unresolved''':<br />
* We have not yet articulated a clear strategy for add-ons with binary components, who will not be helped by the compatible-by-default work mentioned above.<br />
* We haven't resolved how we're going to ensure the best possible blacklist or mitigation for when the blacklist misses a bad add-on.<br />
<br />
=== Enterprise ===<br />
'''Impact''': Enterprise practices for qualifying software deployments require significantly longer windows than our release cycle accommodates. As a result, they have expressed significant concern about their ability to continue supporting Firefox. This loses us goodwill, but also means we are failing to serve a significant number of users.<br />
<br />
'''Resolution''': Kev Needham is driving the creation of an Extended Support Release version of Firefox, in consultation with our community and the revived Enterprise Working Group. The proposal is near completion, and EWG participants seem supportive.<br />
<br />
'''Unresolved''': While the handful of EWG participants seem supportive, we have no real data on whether this will be an effective program -- especially for education and public sectors which are not well represented on the EWG and may have different requirements.<br />
<br />
<br />
== Perceptions of the Project ==<br />
<br />
=== Version Number Inflation ===<br />
'''Impact''': Some industry followers, and especially web developers and site owners, have expressed concerns about Firefox's major numbering convention. The merits of major version numbering by default, (allowing for the possibility of new features in every release) do not necessarily communicate themselves, and with Chrome and IE both iterating their version numbers more quickly than they have in the past, a sense lingers in some parts that version numbers are being iterated for user-facing "marketing purposes", and that the project is placing the most superficial of concerns above the needs of users and developers.<br />
<br />
'''Resolution''': A concerted communication about this topic seems unlikely to generate much more understanding as the topic is a nuanced one. The market will gradually adapt to the Firefox and Chrome schemas, but this will only be resolved once the wisdom of updating version numbers is proven.<br />
<br />
'''Unresolved''': Evangelism and online engagement can only do so much; but likely our efforts have not been concentrated on addressing this misconception. This should be addressed over time as new features ship and the differences between versions become more meaningful for developers and less meaningful for users.<br />
<br />
= Internal/Project Impacts =<br />
<br />
Second to user impact, but still important, are the challenges our process presents for our own ability to build, ship, and communicate about Firefox.<br />
<br />
== Localization ==<br />
=== Potential Missed Cycles ===<br />
'''Impact''': While recent feedback shows a slight majority (55%) of localizers prefer the new process, some smaller locales worry that they might miss a cycle and leave users stranded.<br />
<br />
'''Resolution''': This concern can be mitigated in some cases by shipping the locale with the new strings untranslated. We have done this already in a few cases where the newly added strings were in low-visibility parts of the product, like the about:permissions prototype.<br />
<br />
=== Per-Release Overhead ===<br />
'''Impact:''' There is a fixed cost associated with spinning up each new release's translation work. This administrative cost is incurred regardless of the number of strings needing translation. This gives localizers the sense that they are burning more time on tiresome administration instead of actual localization.<br />
<br />
'''Unresolved''': This issue has not been resolved, though it suggests finding ways to reduce the administrative burden where possible.<br />
<br />
== Product Management ==<br />
* Delivering collections of features in a single release is more difficult with shorter cycles than longer cycles. This isn't important for all features, but some collections are bigger than the sum of their parts.<br />
* If all features must ride the trains, that's a minimum of 3 months of the feature being in public builds which may allow competitors to scoop us on features. This isn't important for all features, but could matter for some.<br />
<br />
== Product Marketing ==<br />
=== Focused Communications and Messaging around Feature Collections ===<br />
'''Impact''': The strength of our outward communications has been greatly challenged by the new release process. This is an issue because Mozilla is much more reliant upon earned media (PR/news) rather than paid media (advertising). So, when things happen, we have to capitalize. As Product notes, it is very difficult to deliver a collection or set of themed features in a single release. This in turn, makes it very hard to articulate product narrative or theme with each update. As a result, we're forced to lean on "laundry list" approach to messaging which greatly dilutes the outward communication's strength and positioning. <br />
<br />
'''Resolution''': This concern will be addressed when we move to silent updates. Having silent updates will allow us the flexibility to to wait for a set of features to land and to create messaging around certainthemes instead of having a release define the themes for us. This should enable us to have stronger, more targeted messages that will strengthen<br />
positioning in the market. To be clear, we will still make lots of noise when major features land, but this model allows us to have clearer, more concise messaging and to pick and choose what features we talk about. Until silent updates land, we will continue with our current messaging and communications approach. <br />
<br />
=== Building Development Channels ===<br />
'''Impact''': As noted above, there is a lot of discussion around the development channels, especially the value add of Aurora and Beta. We have an opportunity with release channels to grow a new brand to target influencers. Having a much more precise relationship with early adopters will be enormously beneficial, but requires investment.<br />
* The PMM team is currently working on building the Aurora user base, but part of the issue we're seeing is that users aren't seeing game-changing features land in Aurora (as PMs also mention above), making it hard to distinguish it from the rest of the channels available. We know that many key features are landing soon, but the lack key feature additions in our releases right now is impeding channel differentiation, and in effect, impeding the growth of the Firefox Aurora channel. This will be an issue regardless of how many channels we have, but it should be noted that the growth of this channel will correlate with the impact of the features we land.<br />
* The Beta Channel in our current scheme has very little differentiation because right now it serves as the "more stable Aurora". Although the current focus is on building Aurora, we will see issues when we try to build the Beta channel because of the lack of channel differentiation. <br />
<br />
'''Resolution''': Unresolved. As mentioned above, a larger discussion needs to happen around release channels.<br />
<br />
=== Staying Up to Date with Product Changes ===<br />
'''Impact''': It's very difficult for the PMM team (and other down stream teams) to stay up to date with what features that are being added, removed or held in each release. The Release Tracking Page is useful, but many are not up to date, particularly for Platform features. This has improved overall, but this is still an issue especially as many decisions are made during triage meetings that many are not able to attend. We lack a uniform communications process to make sure the decisions made in Triage are communicated out to downstream teams on a consistent basis. To be clear, this isn't a new struggle--this was also a problem before the move to the new release release, its just been exacerbated by the faster<br />
release process, especially if the feature pages are out of date. We also don't expect 100% compliance, but stakeholders should understand the need behind these pages to help (perhaps?) create an expectation of the "normal" feature development process. <br />
<br />
'''Resolution''': Unresolved. This issue has not been resolved and will likely need input from PMs, Project Managers and Engineering to find a better process. <br />
<br />
=== Feature Pages are Incomplete ===<br />
'''Impact''': Many feature pages are out of date or do not include the necessary information to define the feature, use case or explanation of the feature. This is particularly true of platform features that lack explanations that non-techie, down stream teams need to be able to use the feature pages properly.<br />
<br />
'''Resolution''': Unresolved. This is something that the Release Tracking page owners, PMM<br />
and the platform team will need to discuss.<br />
<br />
== Press and Public Relations ==<br />
<br />
== Engineering ==<br />
<br />
=== Review bandwidth ===<br />
'''Impact''': We have preliminary data from Martin Best's work that suggests review backlogs may have been growing disproportionately since the introduction of the new process. It's not immediately clear what is driving this but, if true, it would suggest a need for changes in our development process to avoid languishing in bugzilla instead of shipping, which threatens product quality and agility.<br />
<br />
'''Unresolved''': Research is ongoing<br />
<br />
=== Bug Triage ===<br />
'''Impact''': We have preliminary data from Martin Best's work that shows a growing backlog of untriaged bugs. This might suggest we are missing important bugs due to a lack of resources applied to triage, which threatens product quality.<br />
<br />
'''Unresolved''': Research is ongoing<br />
<br />
=== Quality Measurement ===<br />
'''Impact''': Independent of triage in particular, we are concerned that our current process does not adequately detect breakage during the Nightly->Aurora->Beta migration. We note that so far each rapid release we've shipped has required at least one chemspill (see below), albeit in 2 of 4 cases this was due to third party code change or vulnerabilities that would not have been detectable during testing.<br />
<br />
'''Resolution'''<br />
* Lucas Adamski is driving an effort to build a set of quality programs which should allow us to track things more closely and detect issues sooner<br />
* Early detection would also be helped by larger testing populations on our Aurora and Beta channels. Growing these populations is a priority for the product marketing organization.<br />
<br />
'''Unresolved''': In several cases (e.g. crashes), we do have the metrics now to be able to gauge trends and compare our prior monolithic releases with our new scheduled ones. I'll need to gather this data.<br />
<br />
=== Emergency Response ===<br />
'''Impact''': Each release under the new model has required a chemspill response at some point during its lifetime. Only half of these were a result of bugs in mozilla code, but it nevertheless remains the case that we have a frequent need to address bugs between scheduled releases. Chemspills are resource intensive and, because they involve deploying new client software for the affected users, can result in significant interruption and annoyance for our users.<br />
<br />
'''Resolution''': Christian Legnitto and Dave Townsend have proposed and built support for a new "hot fix" add-on in Firefox to eliminate many situations where we would otherwise require a chemspill. If the chemspill is something that an add-on can address, we can package and deliver code through our daily add-on update system which can address the issue until an actual fix is delivered in a subsequent Firefox release. While hotfixes still require QA and testing and validation, they can be delivered without the full machinery of a release, making us both more agile and less irritating. In most cases, the download, install, and activation of a hotfix would be completely invisible to users.<br />
<br />
= Contributors =<br />
<br />
This is the list of people who have contributed, or been invited to contribute, to this process review. If I've forgotten you, please add your name below.<br />
<br />
* Johnathan Nightingale - Firefox Engineering<br />
* Christian Legnitto - Release Management<br />
* Asa Dotzler - Desktop Product Management (in progress)<br />
* Erica Jostedt - Product PR (in progress)<br />
* Laura Mesa - Product Marketing<br />
* Chris Hofmann - Localization<br />
* Axel Hecht - Localization (in progress)<br />
* Sheila Mooney - Engineering Project Management (in progress)<br />
* Patrick Finch - Product Marketing</div>Pfinchhttps://wiki.mozilla.org/index.php?title=RapidRelease/ImpactAssessment&diff=376789RapidRelease/ImpactAssessment2011-12-07T23:14:50Z<p>Pfinch: /* Version Number Inflation */</p>
<hr />
<div>= Preamble =<br />
<br />
We've made the change to a regular schedule of releases. This is a massive win for our ability to compete. We can deliver new features and fixes to users much more quickly. We can upgrade the web on a continuous basis and respond to changes we see with agility. We can execute better on our mission.<br />
<br />
The central benefits of our release schedule aren't the subject of this review. We are keen, though, to ensure we've identified any challenges that this process has introduced. In some cases, we are already well underway on addressing them. In others, we may decide no change is needed at this time. In still others, we may not know the problem exists until someone tells us.<br />
<br />
Please help us fully understand the impact of our new process so that we can make smart adjustments where appropriate. If you have concerns you don't see addressed below, please add them, or email and I'll add them.<br />
<br />
The owner of this document is Johnathan Nightingale.<br />
<br />
= Market/Product Impacts =<br />
<br />
The most important drivers of change in our process should be the impacts our process has on our users and the web.<br />
<br />
== User Experience ==<br />
=== Update Pain ===<br />
'''Impact''': Firefox updates result in several kinds of distracting interactions that bother our users. These include Firefox internal prompts, ecosystem impacts like add-on compatibility, and OS level interference from things like the Windows UAC security system. Some of these are specific to the major version increments in the new process, some of them have happened all along, even for minor releases. The net effect is a terrible user experience, distraction for our users, and a resistance to apply updates which harms our ability to deliver great software.<br />
<br />
'''Resolution''': There are several pieces of work needed to address this impact:<br />
* Eliminating or adjusting our own prompts. This work is largely complete or in progress.<br />
* Add-on compatibility is an area of considerable investment, described below<br />
* Eliminating OS-level interruptions. This work is underway and targeted at early 2012 release. It goes well beyond reducing our level of update annoyance to FF4 levels, in many cases silencing 100% of the interruptions that updates represent (something Firefox has never been capable of previously).<br />
<br />
=== Update Frequency ===<br />
'''Impact:''' We currently ship a release every 6 weeks, barring exceptional circumstance, but it is not clear whether this is the optimum schedule.<br />
<br />
* An accelerated schedule (e.g. every 4-5 weeks) would reduce the amount of change that each release represents, likely resulting in better risk management. It would also shorten the time to market for new features. However a shorter cycle would amplify many of the impacts discussed in this document.<br />
<br />
* A longer release cycle (e.g. 8-10 weeks) would, by contrast, likely dampen the effect of many of the impacts documented here. Each release would have a larger set of features for users and web developers, albeit with greater associated code and integration risk.<br />
<br />
* A significantly longer release cycle (e.g. 3 months) would require us to build an alternate mechanism for delivering security updates, in addition to the costs outlined above. One suggestion has been to syncopate, with security-only releases interwoven with "feature" releases, however these proposals have thus far lacked a clear plan for how testing would accommodate the two streams (particularly since the feature releases would now have twice as much change to test within the same time frame).<br />
<br />
* Right now our development, stabilization, and beta testing phases are of equal length. Moving to a shorter or longer cycle may work better for some phases and worse for others. If, f.e. we moved to 10 weeks of dev, would we also need 10 weeks of stabilization and 10 weeks of beta? <br />
<br />
'''Unresolved''': This topic requires specific discussion and planning, as the various options have a complex set of costs and benefits.<br />
<br />
=== Channel Confusion ===<br />
'''Impact''': The current model has four channels: Nightly, Aurora, Beta and Release. This many channels may be a source of confusion for users. This is particularly true for mobile, where Release and Beta are in the android market, but Nightly and Aurora are available only through sideloading/direct download.<br />
* Are our channels providing us the coverage we need?<br />
* Are our channels providing users the right offer to attract the coverage we need?<br />
* Would three channels work as well as four and carry less confusion?<br />
* Are we capable of differentiating and sustaining four channels?<br />
<br />
'''Unresolved''': This may not be an issue, or may be an issue only on mobile, but in any case requires a more detailed discussion.<br />
* As a "non-urgent" topic, differentiating and growing these distinct channels has not had much focused investment to date.<br />
* Product Marketing is developing and pushing an Aurora program to strengthen that channel, and work with SUMO to build a support community around Aurora.<br />
<br />
== Firefox Ecosystem ==<br />
=== Add-on Compatibility ===<br />
'''Impact''': Firefox add-ons check compatibility based on version number, and our new release process changes version numbers frequently, resulting in significant problems with compatibility. Our add-on ecosystem is a central competitive advantage for Mozilla, and something we value highly, as do our users. Concerns about add-on compatibility occur frequently in feedback about upgrades. (It's not just about the version revs, it's that we actually rev XUL "API"s a lot more frequently too.) <br />
<br />
'''Resolution''': We are addressing this issue in several ways:<br />
* Automated compatibility checking for AMO hosted add-ons. This is complete, and results in very high compatibility rates from one version of Firefox to the next.<br />
* Third party add-on opt-in. In Firefox 8 we shipped support for informing users when a third party installs add ons and asks for explicit consent. We believe that a significant portion of incompatible, non-AMO add-ons are installed without our users' understanding. Making this choice explicit for users will allow them to disable addons they don't want, removing them from the list of add-ons that will warn about compatibility.<br />
* Changing Firefox's code to treat addons as compatible by default. This work is largely complete, but not yet enabled in shipping Firefox builds and it's not clear what level of compatibility among "dark matter" add-ons that this will get us. <br />
<br />
'''Unresolved''':<br />
* We have not yet articulated a clear strategy for add-ons with binary components, who will not be helped by the compatible-by-default work mentioned above.<br />
* We haven't resolved how we're going to ensure the best possible blacklist or mitigation for when the blacklist misses a bad add-on.<br />
<br />
=== Enterprise ===<br />
'''Impact''': Enterprise practices for qualifying software deployments require significantly longer windows than our release cycle accommodates. As a result, they have expressed significant concern about their ability to continue supporting Firefox. This loses us goodwill, but also means we are failing to serve a significant number of users.<br />
<br />
'''Resolution''': Kev Needham is driving the creation of an Extended Support Release version of Firefox, in consultation with our community and the revived Enterprise Working Group. The proposal is near completion, and EWG participants seem supportive.<br />
<br />
'''Unresolved''': While the handful of EWG participants seem supportive, we have no real data on whether this will be an effective program -- especially for education and public sectors which are not well represented on the EWG and may have different requirements.<br />
<br />
<br />
== Perceptions of the Project ==<br />
<br />
=== Version Number Inflation ===<br />
'''Impact''': Some industry followers, and especially web developers and site owners, have expressed concerns about Firefox's major numbering convention. The merits of major version numbering by default, (allowing for the possibility of new features in every release) do not necessarily communicate themselves, and with Chrome and IE both iterating their version numbers more quickly than they have in the past, a sense lingers in some parts that version numbers are being iterated for user-facing "marketing purposes", and that the project is placing the most superficial of concerns above the needs of users and developers.<br />
<br />
'''Resolution''': A concerted communication about this topic seems unlikely to generate much more understanding as the topic is a nuanced one. The market will gradually adapt to the Firefox and Chrome schemas, but this will only be resolved once the wisdom of updating version numbers is proven.<br />
<br />
'''Unresolved''': Evangelism and online engagement can only do so much; but likely our efforts have not been concentrated on addressing this misconception. This should be addressed over time as new features ship and the differences between versions become more meaningful for developers and less meaningful for users.<br />
<br />
= Internal/Project Impacts =<br />
<br />
Second to user impact, but still important, are the challenges our process presents for our own ability to build, ship, and communicate about Firefox.<br />
<br />
== Localization ==<br />
=== Potential Missed Cycles ===<br />
'''Impact''': While recent feedback shows a slight majority (55%) of localizers prefer the new process, some smaller locales worry that they might miss a cycle and leave users stranded.<br />
<br />
'''Resolution''': This concern can be mitigated in some cases by shipping the locale with the new strings untranslated. We have done this already in a few cases where the newly added strings were in low-visibility parts of the product, like the about:permissions prototype.<br />
<br />
=== Per-Release Overhead ===<br />
'''Impact:''' There is a fixed cost associated with spinning up each new release's translation work. This administrative cost is incurred regardless of the number of strings needing translation. This gives localizers the sense that they are burning more time on tiresome administration instead of actual localization.<br />
<br />
'''Unresolved''': This issue has not been resolved, though it suggests finding ways to reduce the administrative burden where possible.<br />
<br />
== Product Management ==<br />
* Delivering collections of features in a single release is more difficult with shorter cycles than longer cycles. This isn't important for all features, but some collections are bigger than the sum of their parts.<br />
* If all features must ride the trains, that's a minimum of 3 months of the feature being in public builds which may allow competitors to scoop us on features. This isn't important for all features, but could matter for some.<br />
<br />
== Product Marketing ==<br />
=== Focused Communications and Messaging around Feature Collections ===<br />
'''Impact''': The strength of our outward communications has been greatly challenged by the new release process. This is an issue because Mozilla is much more reliant upon earned media (PR/news) rather than paid media (advertising). So, when things happen, we have to capitalize. As Product notes, it is very difficult to deliver a collection or set of themed features in a single release. This in turn, makes it very hard to articulate product narrative or theme with each update. As a result, we're forced to lean on "laundry list" approach to messaging which greatly dilutes the outward communication's strength and positioning. <br />
<br />
'''Resolution''': This concern will be addressed when we move to silent updates. Having silent updates will allow us the flexibility to to wait for a set of features to land and to create messaging around certainthemes instead of having a release define the themes for us. This should enable us to have stronger, more targeted messages that will strengthen<br />
positioning in the market. To be clear, we will still make lots of noise when major features land, but this model allows us to have clearer, more concise messaging and to pick and choose what features we talk about. Until silent updates land, we will continue with our current messaging and communications approach. <br />
<br />
=== Building Development Channels ===<br />
'''Impact''': As noted above, there is a lot of discussion around the development channels, especially the value add of Aurora and Beta. We have an opportunity with release channels to grow a new brand to target influencers. Having a much more precise relationship with early adopters will be enormously beneficial, but requires investment.<br />
* The PMM team is currently working on building the Aurora user base, but part of the issue we're seeing is that users aren't seeing game-changing features land in Aurora (as PMs also mention above), making it hard to distinguish it from the rest of the channels available. We know that many key features are landing soon, but the lack key feature additions in our releases right now is impeding channel differentiation, and in effect, impeding the growth of the Firefox Aurora channel. This will be an issue regardless of how many channels we have, but it should be noted that the growth of this channel will correlate with the impact of the features we land.<br />
* The Beta Channel in our current scheme has very little differentiation because right now it serves as the "more stable Aurora". Although the current focus is on building Aurora, we will see issues when we try to build the Beta channel because of the lack of channel differentiation. <br />
<br />
'''Resolution''': Unresolved. As mentioned above, a larger discussion needs to happen around release channels.<br />
<br />
=== Staying Up to Date with Product Changes ===<br />
'''Impact''': It's very difficult for the PMM team (and other down stream teams) to stay up to date with what features that are being added, removed or held in each release. The Release Tracking Page is useful, but many are not up to date, particularly for Platform features. This has improved overall, but this is still an issue especially as many decisions are made during triage meetings that many are not able to attend. We lack a uniform communications process to make sure the decisions made in Triage are communicated out to downstream teams on a consistent basis. To be clear, this isn't a new struggle--this was also a problem before the move to the new release release, its just been exacerbated by the faster<br />
release process, especially if the feature pages are out of date. We also don't expect 100% compliance, but stakeholders should understand the need behind these pages to help (perhaps?) create an expectation of the "normal" feature development process. <br />
<br />
'''Resolution''': Unresolved. This issue has not been resolved and will likely need input from PMs, Project Managers and Engineering to find a better process. <br />
<br />
=== Feature Pages are Incomplete ===<br />
'''Impact''': Many feature pages are out of date or do not include the necessary information to define the feature, use case or explanation of the feature. This is particularly true of platform features that lack explanations that non-techie, down stream teams need to be able to use the feature pages properly.<br />
<br />
'''Resolution''': Unresolved. This is something that the Release Tracking page owners, PMM<br />
and the platform team will need to discuss.<br />
<br />
== Press and Public Relations ==<br />
<br />
== Engineering ==<br />
<br />
=== Review bandwidth ===<br />
'''Impact''': We have preliminary data from Martin Best's work that suggests review backlogs may have been growing disproportionately since the introduction of the new process. It's not immediately clear what is driving this but, if true, it would suggest a need for changes in our development process to avoid languishing in bugzilla instead of shipping, which threatens product quality and agility.<br />
<br />
'''Unresolved''': Research is ongoing<br />
<br />
=== Bug Triage ===<br />
'''Impact''': We have preliminary data from Martin Best's work that shows a growing backlog of untriaged bugs. This might suggest we are missing important bugs due to a lack of resources applied to triage, which threatens product quality.<br />
<br />
'''Unresolved''': Research is ongoing<br />
<br />
=== Quality Measurement ===<br />
'''Impact''': Independent of triage in particular, we are concerned that our current process does not adequately detect breakage during the Nightly->Aurora->Beta migration. We note that so far each rapid release we've shipped has required at least one chemspill (see below), albeit in 2 of 4 cases this was due to third party code change or vulnerabilities that would not have been detectable during testing.<br />
<br />
'''Resolution'''<br />
* Lucas Adamski is driving an effort to build a set of quality programs which should allow us to track things more closely and detect issues sooner<br />
* Early detection would also be helped by larger testing populations on our Aurora and Beta channels. Growing these populations is a priority for the product marketing organization.<br />
<br />
'''Unresolved''': In several cases (e.g. crashes), we do have the metrics now to be able to gauge trends and compare our prior monolithic releases with our new scheduled ones. I'll need to gather this data.<br />
<br />
=== Emergency Response ===<br />
'''Impact''': Each release under the new model has required a chemspill response at some point during its lifetime. Only half of these were a result of bugs in mozilla code, but it nevertheless remains the case that we have a frequent need to address bugs between scheduled releases. Chemspills are resource intensive and, because they involve deploying new client software for the affected users, can result in significant interruption and annoyance for our users.<br />
<br />
'''Resolution''': Christian Legnitto and Dave Townsend have proposed and built support for a new "hot fix" add-on in Firefox to eliminate many situations where we would otherwise require a chemspill. If the chemspill is something that an add-on can address, we can package and deliver code through our daily add-on update system which can address the issue until an actual fix is delivered in a subsequent Firefox release. While hotfixes still require QA and testing and validation, they can be delivered without the full machinery of a release, making us both more agile and less irritating. In most cases, the download, install, and activation of a hotfix would be completely invisible to users.<br />
<br />
= Contributors =<br />
<br />
This is the list of people who have contributed, or been invited to contribute, to this process review. If I've forgotten you, please add your name below.<br />
<br />
* Johnathan Nightingale - Firefox Engineering<br />
* Christian Legnitto - Release Management<br />
* Asa Dotzler - Desktop Product Management (in progress)<br />
* Erica Jostedt - Product PR (in progress)<br />
* Laura Mesa - Product Marketing<br />
* Chris Hofmann - Localization<br />
* Axel Hecht - Localization (in progress)<br />
* Sheila Mooney - Engineering Project Management (in progress)<br />
* Patrick Finch - Product Marketing (in progress)</div>Pfinchhttps://wiki.mozilla.org/index.php?title=RapidRelease/ImpactAssessment&diff=376787RapidRelease/ImpactAssessment2011-12-07T23:13:11Z<p>Pfinch: /* Market/Product Impacts */</p>
<hr />
<div>= Preamble =<br />
<br />
We've made the change to a regular schedule of releases. This is a massive win for our ability to compete. We can deliver new features and fixes to users much more quickly. We can upgrade the web on a continuous basis and respond to changes we see with agility. We can execute better on our mission.<br />
<br />
The central benefits of our release schedule aren't the subject of this review. We are keen, though, to ensure we've identified any challenges that this process has introduced. In some cases, we are already well underway on addressing them. In others, we may decide no change is needed at this time. In still others, we may not know the problem exists until someone tells us.<br />
<br />
Please help us fully understand the impact of our new process so that we can make smart adjustments where appropriate. If you have concerns you don't see addressed below, please add them, or email and I'll add them.<br />
<br />
The owner of this document is Johnathan Nightingale.<br />
<br />
= Market/Product Impacts =<br />
<br />
The most important drivers of change in our process should be the impacts our process has on our users and the web.<br />
<br />
== User Experience ==<br />
=== Update Pain ===<br />
'''Impact''': Firefox updates result in several kinds of distracting interactions that bother our users. These include Firefox internal prompts, ecosystem impacts like add-on compatibility, and OS level interference from things like the Windows UAC security system. Some of these are specific to the major version increments in the new process, some of them have happened all along, even for minor releases. The net effect is a terrible user experience, distraction for our users, and a resistance to apply updates which harms our ability to deliver great software.<br />
<br />
'''Resolution''': There are several pieces of work needed to address this impact:<br />
* Eliminating or adjusting our own prompts. This work is largely complete or in progress.<br />
* Add-on compatibility is an area of considerable investment, described below<br />
* Eliminating OS-level interruptions. This work is underway and targeted at early 2012 release. It goes well beyond reducing our level of update annoyance to FF4 levels, in many cases silencing 100% of the interruptions that updates represent (something Firefox has never been capable of previously).<br />
<br />
=== Update Frequency ===<br />
'''Impact:''' We currently ship a release every 6 weeks, barring exceptional circumstance, but it is not clear whether this is the optimum schedule.<br />
<br />
* An accelerated schedule (e.g. every 4-5 weeks) would reduce the amount of change that each release represents, likely resulting in better risk management. It would also shorten the time to market for new features. However a shorter cycle would amplify many of the impacts discussed in this document.<br />
<br />
* A longer release cycle (e.g. 8-10 weeks) would, by contrast, likely dampen the effect of many of the impacts documented here. Each release would have a larger set of features for users and web developers, albeit with greater associated code and integration risk.<br />
<br />
* A significantly longer release cycle (e.g. 3 months) would require us to build an alternate mechanism for delivering security updates, in addition to the costs outlined above. One suggestion has been to syncopate, with security-only releases interwoven with "feature" releases, however these proposals have thus far lacked a clear plan for how testing would accommodate the two streams (particularly since the feature releases would now have twice as much change to test within the same time frame).<br />
<br />
* Right now our development, stabilization, and beta testing phases are of equal length. Moving to a shorter or longer cycle may work better for some phases and worse for others. If, f.e. we moved to 10 weeks of dev, would we also need 10 weeks of stabilization and 10 weeks of beta? <br />
<br />
'''Unresolved''': This topic requires specific discussion and planning, as the various options have a complex set of costs and benefits.<br />
<br />
=== Channel Confusion ===<br />
'''Impact''': The current model has four channels: Nightly, Aurora, Beta and Release. This many channels may be a source of confusion for users. This is particularly true for mobile, where Release and Beta are in the android market, but Nightly and Aurora are available only through sideloading/direct download.<br />
* Are our channels providing us the coverage we need?<br />
* Are our channels providing users the right offer to attract the coverage we need?<br />
* Would three channels work as well as four and carry less confusion?<br />
* Are we capable of differentiating and sustaining four channels?<br />
<br />
'''Unresolved''': This may not be an issue, or may be an issue only on mobile, but in any case requires a more detailed discussion.<br />
* As a "non-urgent" topic, differentiating and growing these distinct channels has not had much focused investment to date.<br />
* Product Marketing is developing and pushing an Aurora program to strengthen that channel, and work with SUMO to build a support community around Aurora.<br />
<br />
== Firefox Ecosystem ==<br />
=== Add-on Compatibility ===<br />
'''Impact''': Firefox add-ons check compatibility based on version number, and our new release process changes version numbers frequently, resulting in significant problems with compatibility. Our add-on ecosystem is a central competitive advantage for Mozilla, and something we value highly, as do our users. Concerns about add-on compatibility occur frequently in feedback about upgrades. (It's not just about the version revs, it's that we actually rev XUL "API"s a lot more frequently too.) <br />
<br />
'''Resolution''': We are addressing this issue in several ways:<br />
* Automated compatibility checking for AMO hosted add-ons. This is complete, and results in very high compatibility rates from one version of Firefox to the next.<br />
* Third party add-on opt-in. In Firefox 8 we shipped support for informing users when a third party installs add ons and asks for explicit consent. We believe that a significant portion of incompatible, non-AMO add-ons are installed without our users' understanding. Making this choice explicit for users will allow them to disable addons they don't want, removing them from the list of add-ons that will warn about compatibility.<br />
* Changing Firefox's code to treat addons as compatible by default. This work is largely complete, but not yet enabled in shipping Firefox builds and it's not clear what level of compatibility among "dark matter" add-ons that this will get us. <br />
<br />
'''Unresolved''':<br />
* We have not yet articulated a clear strategy for add-ons with binary components, who will not be helped by the compatible-by-default work mentioned above.<br />
* We haven't resolved how we're going to ensure the best possible blacklist or mitigation for when the blacklist misses a bad add-on.<br />
<br />
=== Enterprise ===<br />
'''Impact''': Enterprise practices for qualifying software deployments require significantly longer windows than our release cycle accommodates. As a result, they have expressed significant concern about their ability to continue supporting Firefox. This loses us goodwill, but also means we are failing to serve a significant number of users.<br />
<br />
'''Resolution''': Kev Needham is driving the creation of an Extended Support Release version of Firefox, in consultation with our community and the revived Enterprise Working Group. The proposal is near completion, and EWG participants seem supportive.<br />
<br />
'''Unresolved''': While the handful of EWG participants seem supportive, we have no real data on whether this will be an effective program -- especially for education and public sectors which are not well represented on the EWG and may have different requirements.<br />
<br />
<br />
== Perceptions of the Project ==<br />
<br />
=== Version Number Inflation ===<br />
'''Impact''': Some industry followers, and especially web developers and site owners, have expressed concerns about Firefox's major numbering convention. The merits of major version numbering by default, (allowing for the possibility of new features in every release) do not necessarily communicate themselves, and with Chrome and IE both iterating their version numbers more quickly than they have in the past, a sense lingers in some parts that version numbers are being iterated for user-facing "marketing purposes", and that the project is placing the most superficial of concerns above the needs of users and developers.<br />
<br />
'''Resolution''': A concerted communication about this topic seems unlikely to generate much more understanding as the topic is a nuanced one. The market will partly adapt to the Firefox and Chrome schemas.<br />
<br />
'''Unresolved''': Evangelism and online engagement can only do so much; but likely our efforts have not been concentrated on addressing this misconception. This should be addressed over time as new features ship and the differences between versions become more meaningful for developers and less meaningful for users.<br />
<br />
= Internal/Project Impacts =<br />
<br />
Second to user impact, but still important, are the challenges our process presents for our own ability to build, ship, and communicate about Firefox.<br />
<br />
== Localization ==<br />
=== Potential Missed Cycles ===<br />
'''Impact''': While recent feedback shows a slight majority (55%) of localizers prefer the new process, some smaller locales worry that they might miss a cycle and leave users stranded.<br />
<br />
'''Resolution''': This concern can be mitigated in some cases by shipping the locale with the new strings untranslated. We have done this already in a few cases where the newly added strings were in low-visibility parts of the product, like the about:permissions prototype.<br />
<br />
=== Per-Release Overhead ===<br />
'''Impact:''' There is a fixed cost associated with spinning up each new release's translation work. This administrative cost is incurred regardless of the number of strings needing translation. This gives localizers the sense that they are burning more time on tiresome administration instead of actual localization.<br />
<br />
'''Unresolved''': This issue has not been resolved, though it suggests finding ways to reduce the administrative burden where possible.<br />
<br />
== Product Management ==<br />
* Delivering collections of features in a single release is more difficult with shorter cycles than longer cycles. This isn't important for all features, but some collections are bigger than the sum of their parts.<br />
* If all features must ride the trains, that's a minimum of 3 months of the feature being in public builds which may allow competitors to scoop us on features. This isn't important for all features, but could matter for some.<br />
<br />
== Product Marketing ==<br />
=== Focused Communications and Messaging around Feature Collections ===<br />
'''Impact''': The strength of our outward communications has been greatly challenged by the new release process. This is an issue because Mozilla is much more reliant upon earned media (PR/news) rather than paid media (advertising). So, when things happen, we have to capitalize. As Product notes, it is very difficult to deliver a collection or set of themed features in a single release. This in turn, makes it very hard to articulate product narrative or theme with each update. As a result, we're forced to lean on "laundry list" approach to messaging which greatly dilutes the outward communication's strength and positioning. <br />
<br />
'''Resolution''': This concern will be addressed when we move to silent updates. Having silent updates will allow us the flexibility to to wait for a set of features to land and to create messaging around certainthemes instead of having a release define the themes for us. This should enable us to have stronger, more targeted messages that will strengthen<br />
positioning in the market. To be clear, we will still make lots of noise when major features land, but this model allows us to have clearer, more concise messaging and to pick and choose what features we talk about. Until silent updates land, we will continue with our current messaging and communications approach. <br />
<br />
=== Building Development Channels ===<br />
'''Impact''': As noted above, there is a lot of discussion around the development channels, especially the value add of Aurora and Beta. We have an opportunity with release channels to grow a new brand to target influencers. Having a much more precise relationship with early adopters will be enormously beneficial, but requires investment.<br />
* The PMM team is currently working on building the Aurora user base, but part of the issue we're seeing is that users aren't seeing game-changing features land in Aurora (as PMs also mention above), making it hard to distinguish it from the rest of the channels available. We know that many key features are landing soon, but the lack key feature additions in our releases right now is impeding channel differentiation, and in effect, impeding the growth of the Firefox Aurora channel. This will be an issue regardless of how many channels we have, but it should be noted that the growth of this channel will correlate with the impact of the features we land.<br />
* The Beta Channel in our current scheme has very little differentiation because right now it serves as the "more stable Aurora". Although the current focus is on building Aurora, we will see issues when we try to build the Beta channel because of the lack of channel differentiation. <br />
<br />
'''Resolution''': Unresolved. As mentioned above, a larger discussion needs to happen around release channels.<br />
<br />
=== Staying Up to Date with Product Changes ===<br />
'''Impact''': It's very difficult for the PMM team (and other down stream teams) to stay up to date with what features that are being added, removed or held in each release. The Release Tracking Page is useful, but many are not up to date, particularly for Platform features. This has improved overall, but this is still an issue especially as many decisions are made during triage meetings that many are not able to attend. We lack a uniform communications process to make sure the decisions made in Triage are communicated out to downstream teams on a consistent basis. To be clear, this isn't a new struggle--this was also a problem before the move to the new release release, its just been exacerbated by the faster<br />
release process, especially if the feature pages are out of date. We also don't expect 100% compliance, but stakeholders should understand the need behind these pages to help (perhaps?) create an expectation of the "normal" feature development process. <br />
<br />
'''Resolution''': Unresolved. This issue has not been resolved and will likely need input from PMs, Project Managers and Engineering to find a better process. <br />
<br />
=== Feature Pages are Incomplete ===<br />
'''Impact''': Many feature pages are out of date or do not include the necessary information to define the feature, use case or explanation of the feature. This is particularly true of platform features that lack explanations that non-techie, down stream teams need to be able to use the feature pages properly.<br />
<br />
'''Resolution''': Unresolved. This is something that the Release Tracking page owners, PMM<br />
and the platform team will need to discuss.<br />
<br />
== Press and Public Relations ==<br />
<br />
== Engineering ==<br />
<br />
=== Review bandwidth ===<br />
'''Impact''': We have preliminary data from Martin Best's work that suggests review backlogs may have been growing disproportionately since the introduction of the new process. It's not immediately clear what is driving this but, if true, it would suggest a need for changes in our development process to avoid languishing in bugzilla instead of shipping, which threatens product quality and agility.<br />
<br />
'''Unresolved''': Research is ongoing<br />
<br />
=== Bug Triage ===<br />
'''Impact''': We have preliminary data from Martin Best's work that shows a growing backlog of untriaged bugs. This might suggest we are missing important bugs due to a lack of resources applied to triage, which threatens product quality.<br />
<br />
'''Unresolved''': Research is ongoing<br />
<br />
=== Quality Measurement ===<br />
'''Impact''': Independent of triage in particular, we are concerned that our current process does not adequately detect breakage during the Nightly->Aurora->Beta migration. We note that so far each rapid release we've shipped has required at least one chemspill (see below), albeit in 2 of 4 cases this was due to third party code change or vulnerabilities that would not have been detectable during testing.<br />
<br />
'''Resolution'''<br />
* Lucas Adamski is driving an effort to build a set of quality programs which should allow us to track things more closely and detect issues sooner<br />
* Early detection would also be helped by larger testing populations on our Aurora and Beta channels. Growing these populations is a priority for the product marketing organization.<br />
<br />
'''Unresolved''': In several cases (e.g. crashes), we do have the metrics now to be able to gauge trends and compare our prior monolithic releases with our new scheduled ones. I'll need to gather this data.<br />
<br />
=== Emergency Response ===<br />
'''Impact''': Each release under the new model has required a chemspill response at some point during its lifetime. Only half of these were a result of bugs in mozilla code, but it nevertheless remains the case that we have a frequent need to address bugs between scheduled releases. Chemspills are resource intensive and, because they involve deploying new client software for the affected users, can result in significant interruption and annoyance for our users.<br />
<br />
'''Resolution''': Christian Legnitto and Dave Townsend have proposed and built support for a new "hot fix" add-on in Firefox to eliminate many situations where we would otherwise require a chemspill. If the chemspill is something that an add-on can address, we can package and deliver code through our daily add-on update system which can address the issue until an actual fix is delivered in a subsequent Firefox release. While hotfixes still require QA and testing and validation, they can be delivered without the full machinery of a release, making us both more agile and less irritating. In most cases, the download, install, and activation of a hotfix would be completely invisible to users.<br />
<br />
= Contributors =<br />
<br />
This is the list of people who have contributed, or been invited to contribute, to this process review. If I've forgotten you, please add your name below.<br />
<br />
* Johnathan Nightingale - Firefox Engineering<br />
* Christian Legnitto - Release Management<br />
* Asa Dotzler - Desktop Product Management (in progress)<br />
* Erica Jostedt - Product PR (in progress)<br />
* Laura Mesa - Product Marketing<br />
* Chris Hofmann - Localization<br />
* Axel Hecht - Localization (in progress)<br />
* Sheila Mooney - Engineering Project Management (in progress)<br />
* Patrick Finch - Product Marketing (in progress)</div>Pfinchhttps://wiki.mozilla.org/index.php?title=RapidRelease/ImpactAssessment&diff=376781RapidRelease/ImpactAssessment2011-12-07T23:02:08Z<p>Pfinch: /* Channel Confusion */</p>
<hr />
<div>= Preamble =<br />
<br />
We've made the change to a regular schedule of releases. This is a massive win for our ability to compete. We can deliver new features and fixes to users much more quickly. We can upgrade the web on a continuous basis and respond to changes we see with agility. We can execute better on our mission.<br />
<br />
The central benefits of our release schedule aren't the subject of this review. We are keen, though, to ensure we've identified any challenges that this process has introduced. In some cases, we are already well underway on addressing them. In others, we may decide no change is needed at this time. In still others, we may not know the problem exists until someone tells us.<br />
<br />
Please help us fully understand the impact of our new process so that we can make smart adjustments where appropriate. If you have concerns you don't see addressed below, please add them, or email and I'll add them.<br />
<br />
The owner of this document is Johnathan Nightingale.<br />
<br />
= Market/Product Impacts =<br />
<br />
The most important drivers of change in our process should be the impacts our process has on our users and the web.<br />
<br />
== User Experience ==<br />
=== Update Pain ===<br />
'''Impact''': Firefox updates result in several kinds of distracting interactions that bother our users. These include Firefox internal prompts, ecosystem impacts like add-on compatibility, and OS level interference from things like the Windows UAC security system. Some of these are specific to the major version increments in the new process, some of them have happened all along, even for minor releases. The net effect is a terrible user experience, distraction for our users, and a resistance to apply updates which harms our ability to deliver great software.<br />
<br />
'''Resolution''': There are several pieces of work needed to address this impact:<br />
* Eliminating or adjusting our own prompts. This work is largely complete or in progress.<br />
* Add-on compatibility is an area of considerable investment, described below<br />
* Eliminating OS-level interruptions. This work is underway and targeted at early 2012 release. It goes well beyond reducing our level of update annoyance to FF4 levels, in many cases silencing 100% of the interruptions that updates represent (something Firefox has never been capable of previously).<br />
<br />
=== Update Frequency ===<br />
'''Impact:''' We currently ship a release every 6 weeks, barring exceptional circumstance, but it is not clear whether this is the optimum schedule.<br />
<br />
* An accelerated schedule (e.g. every 4-5 weeks) would reduce the amount of change that each release represents, likely resulting in better risk management. It would also shorten the time to market for new features. However a shorter cycle would amplify many of the impacts discussed in this document.<br />
<br />
* A longer release cycle (e.g. 8-10 weeks) would, by contrast, likely dampen the effect of many of the impacts documented here. Each release would have a larger set of features for users and web developers, albeit with greater associated code and integration risk.<br />
<br />
* A significantly longer release cycle (e.g. 3 months) would require us to build an alternate mechanism for delivering security updates, in addition to the costs outlined above. One suggestion has been to syncopate, with security-only releases interwoven with "feature" releases, however these proposals have thus far lacked a clear plan for how testing would accommodate the two streams (particularly since the feature releases would now have twice as much change to test within the same time frame).<br />
<br />
* Right now our development, stabilization, and beta testing phases are of equal length. Moving to a shorter or longer cycle may work better for some phases and worse for others. If, f.e. we moved to 10 weeks of dev, would we also need 10 weeks of stabilization and 10 weeks of beta? <br />
<br />
'''Unresolved''': This topic requires specific discussion and planning, as the various options have a complex set of costs and benefits.<br />
<br />
=== Channel Confusion ===<br />
'''Impact''': The current model has four channels: Nightly, Aurora, Beta and Release. This many channels may be a source of confusion for users. This is particularly true for mobile, where Release and Beta are in the android market, but Nightly and Aurora are available only through sideloading/direct download.<br />
* Are our channels providing us the coverage we need?<br />
* Are our channels providing users the right offer to attract the coverage we need?<br />
* Would three channels work as well as four and carry less confusion?<br />
* Are we capable of differentiating and sustaining four channels?<br />
<br />
'''Unresolved''': This may not be an issue, or may be an issue only on mobile, but in any case requires a more detailed discussion.<br />
* As a "non-urgent" topic, differentiating and growing these distinct channels has not had much focused investment to date.<br />
* Product Marketing is developing and pushing an Aurora program to strengthen that channel, and work with SUMO to build a support community around Aurora.<br />
<br />
== Firefox Ecosystem ==<br />
=== Add-on Compatibility ===<br />
'''Impact''': Firefox add-ons check compatibility based on version number, and our new release process changes version numbers frequently, resulting in significant problems with compatibility. Our add-on ecosystem is a central competitive advantage for Mozilla, and something we value highly, as do our users. Concerns about add-on compatibility occur frequently in feedback about upgrades. (It's not just about the version revs, it's that we actually rev XUL "API"s a lot more frequently too.) <br />
<br />
'''Resolution''': We are addressing this issue in several ways:<br />
* Automated compatibility checking for AMO hosted add-ons. This is complete, and results in very high compatibility rates from one version of Firefox to the next.<br />
* Third party add-on opt-in. In Firefox 8 we shipped support for informing users when a third party installs add ons and asks for explicit consent. We believe that a significant portion of incompatible, non-AMO add-ons are installed without our users' understanding. Making this choice explicit for users will allow them to disable addons they don't want, removing them from the list of add-ons that will warn about compatibility.<br />
* Changing Firefox's code to treat addons as compatible by default. This work is largely complete, but not yet enabled in shipping Firefox builds and it's not clear what level of compatibility among "dark matter" add-ons that this will get us. <br />
<br />
'''Unresolved''':<br />
* We have not yet articulated a clear strategy for add-ons with binary components, who will not be helped by the compatible-by-default work mentioned above.<br />
* We haven't resolved how we're going to ensure the best possible blacklist or mitigation for when the blacklist misses a bad add-on.<br />
<br />
=== Enterprise ===<br />
'''Impact''': Enterprise practices for qualifying software deployments require significantly longer windows than our release cycle accommodates. As a result, they have expressed significant concern about their ability to continue supporting Firefox. This loses us goodwill, but also means we are failing to serve a significant number of users.<br />
<br />
'''Resolution''': Kev Needham is driving the creation of an Extended Support Release version of Firefox, in consultation with our community and the revived Enterprise Working Group. The proposal is near completion, and EWG participants seem supportive.<br />
<br />
'''Unresolved''': While the handful of EWG participants seem supportive, we have no real data on whether this will be an effective program -- especially for education and public sectors which are not well represented on the EWG and may have different requirements.<br />
<br />
= Internal/Project Impacts =<br />
<br />
Second to user impact, but still important, are the challenges our process presents for our own ability to build, ship, and communicate about Firefox.<br />
<br />
== Localization ==<br />
=== Potential Missed Cycles ===<br />
'''Impact''': While recent feedback shows a slight majority (55%) of localizers prefer the new process, some smaller locales worry that they might miss a cycle and leave users stranded.<br />
<br />
'''Resolution''': This concern can be mitigated in some cases by shipping the locale with the new strings untranslated. We have done this already in a few cases where the newly added strings were in low-visibility parts of the product, like the about:permissions prototype.<br />
<br />
=== Per-Release Overhead ===<br />
'''Impact:''' There is a fixed cost associated with spinning up each new release's translation work. This administrative cost is incurred regardless of the number of strings needing translation. This gives localizers the sense that they are burning more time on tiresome administration instead of actual localization.<br />
<br />
'''Unresolved''': This issue has not been resolved, though it suggests finding ways to reduce the administrative burden where possible.<br />
<br />
== Product Management ==<br />
* Delivering collections of features in a single release is more difficult with shorter cycles than longer cycles. This isn't important for all features, but some collections are bigger than the sum of their parts.<br />
* If all features must ride the trains, that's a minimum of 3 months of the feature being in public builds which may allow competitors to scoop us on features. This isn't important for all features, but could matter for some.<br />
<br />
== Product Marketing ==<br />
=== Focused Communications and Messaging around Feature Collections ===<br />
'''Impact''': The strength of our outward communications has been greatly challenged by the new release process. This is an issue because Mozilla is much more reliant upon earned media (PR/news) rather than paid media (advertising). So, when things happen, we have to capitalize. As Product notes, it is very difficult to deliver a collection or set of themed features in a single release. This in turn, makes it very hard to articulate product narrative or theme with each update. As a result, we're forced to lean on "laundry list" approach to messaging which greatly dilutes the outward communication's strength and positioning. <br />
<br />
'''Resolution''': This concern will be addressed when we move to silent updates. Having silent updates will allow us the flexibility to to wait for a set of features to land and to create messaging around certainthemes instead of having a release define the themes for us. This should enable us to have stronger, more targeted messages that will strengthen<br />
positioning in the market. To be clear, we will still make lots of noise when major features land, but this model allows us to have clearer, more concise messaging and to pick and choose what features we talk about. Until silent updates land, we will continue with our current messaging and communications approach. <br />
<br />
=== Building Development Channels ===<br />
'''Impact''': As noted above, there is a lot of discussion around the development channels, especially the value add of Aurora and Beta. We have an opportunity with release channels to grow a new brand to target influencers. Having a much more precise relationship with early adopters will be enormously beneficial, but requires investment.<br />
* The PMM team is currently working on building the Aurora user base, but part of the issue we're seeing is that users aren't seeing game-changing features land in Aurora (as PMs also mention above), making it hard to distinguish it from the rest of the channels available. We know that many key features are landing soon, but the lack key feature additions in our releases right now is impeding channel differentiation, and in effect, impeding the growth of the Firefox Aurora channel. This will be an issue regardless of how many channels we have, but it should be noted that the growth of this channel will correlate with the impact of the features we land.<br />
* The Beta Channel in our current scheme has very little differentiation because right now it serves as the "more stable Aurora". Although the current focus is on building Aurora, we will see issues when we try to build the Beta channel because of the lack of channel differentiation. <br />
<br />
'''Resolution''': Unresolved. As mentioned above, a larger discussion needs to happen around release channels.<br />
<br />
=== Staying Up to Date with Product Changes ===<br />
'''Impact''': It's very difficult for the PMM team (and other down stream teams) to stay up to date with what features that are being added, removed or held in each release. The Release Tracking Page is useful, but many are not up to date, particularly for Platform features. This has improved overall, but this is still an issue especially as many decisions are made during triage meetings that many are not able to attend. We lack a uniform communications process to make sure the decisions made in Triage are communicated out to downstream teams on a consistent basis. To be clear, this isn't a new struggle--this was also a problem before the move to the new release release, its just been exacerbated by the faster<br />
release process, especially if the feature pages are out of date. We also don't expect 100% compliance, but stakeholders should understand the need behind these pages to help (perhaps?) create an expectation of the "normal" feature development process. <br />
<br />
'''Resolution''': Unresolved. This issue has not been resolved and will likely need input from PMs, Project Managers and Engineering to find a better process. <br />
<br />
=== Feature Pages are Incomplete ===<br />
'''Impact''': Many feature pages are out of date or do not include the necessary information to define the feature, use case or explanation of the feature. This is particularly true of platform features that lack explanations that non-techie, down stream teams need to be able to use the feature pages properly.<br />
<br />
'''Resolution''': Unresolved. This is something that the Release Tracking page owners, PMM<br />
and the platform team will need to discuss.<br />
<br />
== Press and Public Relations ==<br />
<br />
== Engineering ==<br />
<br />
=== Review bandwidth ===<br />
'''Impact''': We have preliminary data from Martin Best's work that suggests review backlogs may have been growing disproportionately since the introduction of the new process. It's not immediately clear what is driving this but, if true, it would suggest a need for changes in our development process to avoid languishing in bugzilla instead of shipping, which threatens product quality and agility.<br />
<br />
'''Unresolved''': Research is ongoing<br />
<br />
=== Bug Triage ===<br />
'''Impact''': We have preliminary data from Martin Best's work that shows a growing backlog of untriaged bugs. This might suggest we are missing important bugs due to a lack of resources applied to triage, which threatens product quality.<br />
<br />
'''Unresolved''': Research is ongoing<br />
<br />
=== Quality Measurement ===<br />
'''Impact''': Independent of triage in particular, we are concerned that our current process does not adequately detect breakage during the Nightly->Aurora->Beta migration. We note that so far each rapid release we've shipped has required at least one chemspill (see below), albeit in 2 of 4 cases this was due to third party code change or vulnerabilities that would not have been detectable during testing.<br />
<br />
'''Resolution'''<br />
* Lucas Adamski is driving an effort to build a set of quality programs which should allow us to track things more closely and detect issues sooner<br />
* Early detection would also be helped by larger testing populations on our Aurora and Beta channels. Growing these populations is a priority for the product marketing organization.<br />
<br />
'''Unresolved''': In several cases (e.g. crashes), we do have the metrics now to be able to gauge trends and compare our prior monolithic releases with our new scheduled ones. I'll need to gather this data.<br />
<br />
=== Emergency Response ===<br />
'''Impact''': Each release under the new model has required a chemspill response at some point during its lifetime. Only half of these were a result of bugs in mozilla code, but it nevertheless remains the case that we have a frequent need to address bugs between scheduled releases. Chemspills are resource intensive and, because they involve deploying new client software for the affected users, can result in significant interruption and annoyance for our users.<br />
<br />
'''Resolution''': Christian Legnitto and Dave Townsend have proposed and built support for a new "hot fix" add-on in Firefox to eliminate many situations where we would otherwise require a chemspill. If the chemspill is something that an add-on can address, we can package and deliver code through our daily add-on update system which can address the issue until an actual fix is delivered in a subsequent Firefox release. While hotfixes still require QA and testing and validation, they can be delivered without the full machinery of a release, making us both more agile and less irritating. In most cases, the download, install, and activation of a hotfix would be completely invisible to users.<br />
<br />
= Contributors =<br />
<br />
This is the list of people who have contributed, or been invited to contribute, to this process review. If I've forgotten you, please add your name below.<br />
<br />
* Johnathan Nightingale - Firefox Engineering<br />
* Christian Legnitto - Release Management<br />
* Asa Dotzler - Desktop Product Management (in progress)<br />
* Erica Jostedt - Product PR (in progress)<br />
* Laura Mesa - Product Marketing<br />
* Chris Hofmann - Localization<br />
* Axel Hecht - Localization (in progress)<br />
* Sheila Mooney - Engineering Project Management (in progress)<br />
* Patrick Finch - Product Marketing (in progress)</div>Pfinchhttps://wiki.mozilla.org/index.php?title=RapidRelease/ImpactAssessment&diff=376780RapidRelease/ImpactAssessment2011-12-07T23:00:58Z<p>Pfinch: /* Channel Confusion */</p>
<hr />
<div>= Preamble =<br />
<br />
We've made the change to a regular schedule of releases. This is a massive win for our ability to compete. We can deliver new features and fixes to users much more quickly. We can upgrade the web on a continuous basis and respond to changes we see with agility. We can execute better on our mission.<br />
<br />
The central benefits of our release schedule aren't the subject of this review. We are keen, though, to ensure we've identified any challenges that this process has introduced. In some cases, we are already well underway on addressing them. In others, we may decide no change is needed at this time. In still others, we may not know the problem exists until someone tells us.<br />
<br />
Please help us fully understand the impact of our new process so that we can make smart adjustments where appropriate. If you have concerns you don't see addressed below, please add them, or email and I'll add them.<br />
<br />
The owner of this document is Johnathan Nightingale.<br />
<br />
= Market/Product Impacts =<br />
<br />
The most important drivers of change in our process should be the impacts our process has on our users and the web.<br />
<br />
== User Experience ==<br />
=== Update Pain ===<br />
'''Impact''': Firefox updates result in several kinds of distracting interactions that bother our users. These include Firefox internal prompts, ecosystem impacts like add-on compatibility, and OS level interference from things like the Windows UAC security system. Some of these are specific to the major version increments in the new process, some of them have happened all along, even for minor releases. The net effect is a terrible user experience, distraction for our users, and a resistance to apply updates which harms our ability to deliver great software.<br />
<br />
'''Resolution''': There are several pieces of work needed to address this impact:<br />
* Eliminating or adjusting our own prompts. This work is largely complete or in progress.<br />
* Add-on compatibility is an area of considerable investment, described below<br />
* Eliminating OS-level interruptions. This work is underway and targeted at early 2012 release. It goes well beyond reducing our level of update annoyance to FF4 levels, in many cases silencing 100% of the interruptions that updates represent (something Firefox has never been capable of previously).<br />
<br />
=== Update Frequency ===<br />
'''Impact:''' We currently ship a release every 6 weeks, barring exceptional circumstance, but it is not clear whether this is the optimum schedule.<br />
<br />
* An accelerated schedule (e.g. every 4-5 weeks) would reduce the amount of change that each release represents, likely resulting in better risk management. It would also shorten the time to market for new features. However a shorter cycle would amplify many of the impacts discussed in this document.<br />
<br />
* A longer release cycle (e.g. 8-10 weeks) would, by contrast, likely dampen the effect of many of the impacts documented here. Each release would have a larger set of features for users and web developers, albeit with greater associated code and integration risk.<br />
<br />
* A significantly longer release cycle (e.g. 3 months) would require us to build an alternate mechanism for delivering security updates, in addition to the costs outlined above. One suggestion has been to syncopate, with security-only releases interwoven with "feature" releases, however these proposals have thus far lacked a clear plan for how testing would accommodate the two streams (particularly since the feature releases would now have twice as much change to test within the same time frame).<br />
<br />
* Right now our development, stabilization, and beta testing phases are of equal length. Moving to a shorter or longer cycle may work better for some phases and worse for others. If, f.e. we moved to 10 weeks of dev, would we also need 10 weeks of stabilization and 10 weeks of beta? <br />
<br />
'''Unresolved''': This topic requires specific discussion and planning, as the various options have a complex set of costs and benefits.<br />
<br />
=== Channel Confusion ===<br />
'''Impact''': The current model has four channels: Nightly, Aurora, Beta and Release. This many channels may be a source of confusion for users. This is particularly true for mobile, where Release and Beta are in the android market, but Nightly and Aurora are available only through sideloading/direct download.<br />
* Are our channels providing us the coverage we need?<br />
* Are our channels providing users the right offer to attract the coverage we need?<br />
* Would three channels work as well as four and carry less confusion?<br />
* Are we capable of differentiating and sustaining four channels?<br />
<br />
'''Unresolved''': This may not be an issue, or may be an issue only on mobile, but in any case requires a more detailed discussion.<br />
* Product Marketing is developing and pushing an Aurora program to strengthen that channel, and work with SUMO to build a support community around Aurora.<br />
<br />
== Firefox Ecosystem ==<br />
=== Add-on Compatibility ===<br />
'''Impact''': Firefox add-ons check compatibility based on version number, and our new release process changes version numbers frequently, resulting in significant problems with compatibility. Our add-on ecosystem is a central competitive advantage for Mozilla, and something we value highly, as do our users. Concerns about add-on compatibility occur frequently in feedback about upgrades. (It's not just about the version revs, it's that we actually rev XUL "API"s a lot more frequently too.) <br />
<br />
'''Resolution''': We are addressing this issue in several ways:<br />
* Automated compatibility checking for AMO hosted add-ons. This is complete, and results in very high compatibility rates from one version of Firefox to the next.<br />
* Third party add-on opt-in. In Firefox 8 we shipped support for informing users when a third party installs add ons and asks for explicit consent. We believe that a significant portion of incompatible, non-AMO add-ons are installed without our users' understanding. Making this choice explicit for users will allow them to disable addons they don't want, removing them from the list of add-ons that will warn about compatibility.<br />
* Changing Firefox's code to treat addons as compatible by default. This work is largely complete, but not yet enabled in shipping Firefox builds and it's not clear what level of compatibility among "dark matter" add-ons that this will get us. <br />
<br />
'''Unresolved''':<br />
* We have not yet articulated a clear strategy for add-ons with binary components, who will not be helped by the compatible-by-default work mentioned above.<br />
* We haven't resolved how we're going to ensure the best possible blacklist or mitigation for when the blacklist misses a bad add-on.<br />
<br />
=== Enterprise ===<br />
'''Impact''': Enterprise practices for qualifying software deployments require significantly longer windows than our release cycle accommodates. As a result, they have expressed significant concern about their ability to continue supporting Firefox. This loses us goodwill, but also means we are failing to serve a significant number of users.<br />
<br />
'''Resolution''': Kev Needham is driving the creation of an Extended Support Release version of Firefox, in consultation with our community and the revived Enterprise Working Group. The proposal is near completion, and EWG participants seem supportive.<br />
<br />
'''Unresolved''': While the handful of EWG participants seem supportive, we have no real data on whether this will be an effective program -- especially for education and public sectors which are not well represented on the EWG and may have different requirements.<br />
<br />
= Internal/Project Impacts =<br />
<br />
Second to user impact, but still important, are the challenges our process presents for our own ability to build, ship, and communicate about Firefox.<br />
<br />
== Localization ==<br />
=== Potential Missed Cycles ===<br />
'''Impact''': While recent feedback shows a slight majority (55%) of localizers prefer the new process, some smaller locales worry that they might miss a cycle and leave users stranded.<br />
<br />
'''Resolution''': This concern can be mitigated in some cases by shipping the locale with the new strings untranslated. We have done this already in a few cases where the newly added strings were in low-visibility parts of the product, like the about:permissions prototype.<br />
<br />
=== Per-Release Overhead ===<br />
'''Impact:''' There is a fixed cost associated with spinning up each new release's translation work. This administrative cost is incurred regardless of the number of strings needing translation. This gives localizers the sense that they are burning more time on tiresome administration instead of actual localization.<br />
<br />
'''Unresolved''': This issue has not been resolved, though it suggests finding ways to reduce the administrative burden where possible.<br />
<br />
== Product Management ==<br />
* Delivering collections of features in a single release is more difficult with shorter cycles than longer cycles. This isn't important for all features, but some collections are bigger than the sum of their parts.<br />
* If all features must ride the trains, that's a minimum of 3 months of the feature being in public builds which may allow competitors to scoop us on features. This isn't important for all features, but could matter for some.<br />
<br />
== Product Marketing ==<br />
=== Focused Communications and Messaging around Feature Collections ===<br />
'''Impact''': The strength of our outward communications has been greatly challenged by the new release process. This is an issue because Mozilla is much more reliant upon earned media (PR/news) rather than paid media (advertising). So, when things happen, we have to capitalize. As Product notes, it is very difficult to deliver a collection or set of themed features in a single release. This in turn, makes it very hard to articulate product narrative or theme with each update. As a result, we're forced to lean on "laundry list" approach to messaging which greatly dilutes the outward communication's strength and positioning. <br />
<br />
'''Resolution''': This concern will be addressed when we move to silent updates. Having silent updates will allow us the flexibility to to wait for a set of features to land and to create messaging around certainthemes instead of having a release define the themes for us. This should enable us to have stronger, more targeted messages that will strengthen<br />
positioning in the market. To be clear, we will still make lots of noise when major features land, but this model allows us to have clearer, more concise messaging and to pick and choose what features we talk about. Until silent updates land, we will continue with our current messaging and communications approach. <br />
<br />
=== Building Development Channels ===<br />
'''Impact''': As noted above, there is a lot of discussion around the development channels, especially the value add of Aurora and Beta. We have an opportunity with release channels to grow a new brand to target influencers. Having a much more precise relationship with early adopters will be enormously beneficial, but requires investment.<br />
* The PMM team is currently working on building the Aurora user base, but part of the issue we're seeing is that users aren't seeing game-changing features land in Aurora (as PMs also mention above), making it hard to distinguish it from the rest of the channels available. We know that many key features are landing soon, but the lack key feature additions in our releases right now is impeding channel differentiation, and in effect, impeding the growth of the Firefox Aurora channel. This will be an issue regardless of how many channels we have, but it should be noted that the growth of this channel will correlate with the impact of the features we land.<br />
* The Beta Channel in our current scheme has very little differentiation because right now it serves as the "more stable Aurora". Although the current focus is on building Aurora, we will see issues when we try to build the Beta channel because of the lack of channel differentiation. <br />
<br />
'''Resolution''': Unresolved. As mentioned above, a larger discussion needs to happen around release channels.<br />
<br />
=== Staying Up to Date with Product Changes ===<br />
'''Impact''': It's very difficult for the PMM team (and other down stream teams) to stay up to date with what features that are being added, removed or held in each release. The Release Tracking Page is useful, but many are not up to date, particularly for Platform features. This has improved overall, but this is still an issue especially as many decisions are made during triage meetings that many are not able to attend. We lack a uniform communications process to make sure the decisions made in Triage are communicated out to downstream teams on a consistent basis. To be clear, this isn't a new struggle--this was also a problem before the move to the new release release, its just been exacerbated by the faster<br />
release process, especially if the feature pages are out of date. We also don't expect 100% compliance, but stakeholders should understand the need behind these pages to help (perhaps?) create an expectation of the "normal" feature development process. <br />
<br />
'''Resolution''': Unresolved. This issue has not been resolved and will likely need input from PMs, Project Managers and Engineering to find a better process. <br />
<br />
=== Feature Pages are Incomplete ===<br />
'''Impact''': Many feature pages are out of date or do not include the necessary information to define the feature, use case or explanation of the feature. This is particularly true of platform features that lack explanations that non-techie, down stream teams need to be able to use the feature pages properly.<br />
<br />
'''Resolution''': Unresolved. This is something that the Release Tracking page owners, PMM<br />
and the platform team will need to discuss.<br />
<br />
== Press and Public Relations ==<br />
<br />
== Engineering ==<br />
<br />
=== Review bandwidth ===<br />
'''Impact''': We have preliminary data from Martin Best's work that suggests review backlogs may have been growing disproportionately since the introduction of the new process. It's not immediately clear what is driving this but, if true, it would suggest a need for changes in our development process to avoid languishing in bugzilla instead of shipping, which threatens product quality and agility.<br />
<br />
'''Unresolved''': Research is ongoing<br />
<br />
=== Bug Triage ===<br />
'''Impact''': We have preliminary data from Martin Best's work that shows a growing backlog of untriaged bugs. This might suggest we are missing important bugs due to a lack of resources applied to triage, which threatens product quality.<br />
<br />
'''Unresolved''': Research is ongoing<br />
<br />
=== Quality Measurement ===<br />
'''Impact''': Independent of triage in particular, we are concerned that our current process does not adequately detect breakage during the Nightly->Aurora->Beta migration. We note that so far each rapid release we've shipped has required at least one chemspill (see below), albeit in 2 of 4 cases this was due to third party code change or vulnerabilities that would not have been detectable during testing.<br />
<br />
'''Resolution'''<br />
* Lucas Adamski is driving an effort to build a set of quality programs which should allow us to track things more closely and detect issues sooner<br />
* Early detection would also be helped by larger testing populations on our Aurora and Beta channels. Growing these populations is a priority for the product marketing organization.<br />
<br />
'''Unresolved''': In several cases (e.g. crashes), we do have the metrics now to be able to gauge trends and compare our prior monolithic releases with our new scheduled ones. I'll need to gather this data.<br />
<br />
=== Emergency Response ===<br />
'''Impact''': Each release under the new model has required a chemspill response at some point during its lifetime. Only half of these were a result of bugs in mozilla code, but it nevertheless remains the case that we have a frequent need to address bugs between scheduled releases. Chemspills are resource intensive and, because they involve deploying new client software for the affected users, can result in significant interruption and annoyance for our users.<br />
<br />
'''Resolution''': Christian Legnitto and Dave Townsend have proposed and built support for a new "hot fix" add-on in Firefox to eliminate many situations where we would otherwise require a chemspill. If the chemspill is something that an add-on can address, we can package and deliver code through our daily add-on update system which can address the issue until an actual fix is delivered in a subsequent Firefox release. While hotfixes still require QA and testing and validation, they can be delivered without the full machinery of a release, making us both more agile and less irritating. In most cases, the download, install, and activation of a hotfix would be completely invisible to users.<br />
<br />
= Contributors =<br />
<br />
This is the list of people who have contributed, or been invited to contribute, to this process review. If I've forgotten you, please add your name below.<br />
<br />
* Johnathan Nightingale - Firefox Engineering<br />
* Christian Legnitto - Release Management<br />
* Asa Dotzler - Desktop Product Management (in progress)<br />
* Erica Jostedt - Product PR (in progress)<br />
* Laura Mesa - Product Marketing<br />
* Chris Hofmann - Localization<br />
* Axel Hecht - Localization (in progress)<br />
* Sheila Mooney - Engineering Project Management (in progress)<br />
* Patrick Finch - Product Marketing (in progress)</div>Pfinch