mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Kim Moir: Distributed teams: Better communication and engagement

Mozilla planet - to, 21/12/2017 - 21:46

As I have written before, I work on a very distributed team.

Screen Shot 2017-12-21 at 10.57.56 AM<figcaption class="wp-caption-text">Mozilla release engineering around the world.</figcaption>

I always think that as a distributed team, we have to overcome friction to communicate. If we all worked in the same physical office, you could just walk over to someone’s desk and look at the same screen to debug a problem.  Instead, we have to talk in slack, irc, a video chat, email, or issue trackers.  When the discussion takes place in a public forum, some people hesitate to discuss the issue.  It’s sometimes difficult to admit you don’t know something, even if the team culture is welcoming and people are happy to answer questions.

Over the last month or so I’ve been facilitating the releng team meeting. We have one meeting a week, and the timeslot rotates so that one week it’s convenient for folks in Europe, the other time it’s convenient for those in Pacific timezones.  The people in Eastern timezones usually attend both since it overlaps our work days in both cases.  We have a shared document where we have discussion items and status updates.  As part of each person’s update on the work they are doing I asked them to add:

1) Shoutout to someone you’d like to thank for helping you this week, or someone who you’d like to recognize for doing great work that helped the team

2) Where you need help

One of the things about writing tooling for a large distributed system such as Mozilla’s build and release pipeline is that a lot of the time, things just work. There are many ongoing projects to make components of it more resilient or more scalable.  So it’s good to publicly acknowledge that they work they are doing is is appreciated, and not just in the case of heroic work to address an operational failure.

Sometimes it’s surprising what people are thankful for – you may think it’s something small but it makes a difference in people’s happiness.   For example, conducting code reviews quickly so people can move forward with landing their patches.  Other times, it’s a larger projects that get the shoutout.  For example, when we were getting ready for the Quantum release, Johan wrote a document about all the update scenarios we needed to implement so release management were on the same page as us.  Ben wrote some tests to test these update scenarios so we could ensure they were implemented in an automated fashion. Thanking people for their work feels great and improves team engagement.

IMG_5654<figcaption class="wp-caption-text">Go team!</figcaption>

Asking people to indicate where they stuck or need help normalizes asking for help as part of team culture. Whether you are new to the team or have been working on it for a long time, people see that it’s okay to describe where they are stuck understanding the root of a problem or how to implement a solution.  When you have all the team in a room, people can jump in with suggestions or point you to other people with the expertise to help.  Also, if you have too much work on your plate, someone who just finished a project may be able to jump in which allows the team to redistribute workload more effectively.

At Rail’s suggestion, some people started having regularly scheduled 1x1s with people who aren’t their manager.  I started having 1x1s with Nick, who lives in New Zealand.  Our work days don’t overlap for very long so we haven’t worked much together in the past.  This has been great as we got to know each other better and can share expertise.  I was in a course earlier this year where a colleague mentioned that a sign of a dysfunctional team is when everyone talks to the manager, but team members don’t talk to each other.  So regularly scheduled 1x1s with teammates are a fantastic way to get to know people better, and gain new skills.

We have been working on migrating our build and release pipeline to a new system. During this migration, Ben and Aki would often announce that they would be in a shared video conference room for a few hours in the afternoon, in case people needed help. This was another great way to reduce friction when people got stuck solving a problem.  We could just go and ask.  A lot of the time, the room was silent as people worked, but we could have a quick conversation.  Even if you knew the solution to a problem, it was useful to talk about your approach with other team members to ensure you were on the right path.

The final thing is that Mihai created a shared drive of team pictures.  I gave a presentation last week, and included many team pictures.  I really like to show the human side of teams, and nothing shows that better than pictures of people having fun together.  So it’s really awesome that we have an archive of team pictures that we can look at and use when showcase our work.

In summary, these are some things that have worked for our distributed team

  1. Saying thanks to team members and asking for help in regularly scheduled team meetings.
  2. Regularly scheduled 1x1s with teammates you want to get to know better or learn new skills from
  3. Regularly scheduled video conferences for project teams to assist with debugging
  4. Shared drive for team pictures

If you work on a distributed team, what strategies to you use to help your team communicate more effectively?

Further reading


Categorieën: Mozilla-nl planet

Joel Maher: running tests by bugzilla component instead of test suite

Mozilla planet - to, 21/12/2017 - 18:07

Over the years we have had great dreams of running our tests in many different ways.  There was a dream of ‘hyperchunking’ where we would run everything in hundreds of chunks finishing in just a couple of minutes for all the tests.  This idea is difficult for many reasons, so we shifted to ‘run-by-manifest’, while we sort of do this now for mochitest, we don’t for web-platform-tests, reftest, or xpcshell.  Both of these models require work on how we schedule and report data which isn’t too hard to solve, but does require a lot of additional work and supporting 2 models in parallel for some time.

In recent times, there has been an ongoing conversation about ‘run-by-component’.  Let me explain.  We have all files in tree mapped to bugzilla components.  In fact almost all manifests have a clean list of tests that map to the same component.  Why not schedule, run, and report our tests on the same bugzilla component?

I got excited near the end of the Austin work week as I started working on this to see what would happen.

rbc

This is hand crafted to show top level productions, and when we expand those products you can see all the components:

rbc_expanded

I just used the first 3 letters of each component until there was a conflict, then I hand edited exceptions.

What is great here is we can easy schedule networking only tests:

rbc_scheduling

and what you would see is:

rbc_networking

^ keep in mind in this example I am using the same push, but just filtering- but I did test on a smaller scale for a bit with just Core-networking until I got it working.

What would we use this for:

  1. collecting code coverage on components instead of random chunks which will give us the ability to recommend tests to run with more accuracy than we have now
  2. tools like SETA will be more deterministic
  3. developers can filter in treeherder on their specific components and see how green they are, etc.
  4. easier backfilling of intermittents for sheriffs as tests are not moving around between chunks every time we add/remove a test

While I am excited about the 4 reasons above, this is far from being production ready.  There are a few things we would need to solve:

  1. My current patch takes a list of manifests associated with bugzilla components are runs all manifests related to that component- we would need to sanitize all manifests to only have tests related to one component (or solve this differently)
  2. My current patch iterates through all possible test types- this is grossly inefficient, but the best I could do with mozharness- I suspect a slight bit of work and I could have reftest/xpcshell working, likewise web-platform tests.  Ideally we would run all tests from a source checkout and use |./mach test <component>| and it would find what needs to run
  3. What do we do when we need to chunk certain components?  Right now I hack on taskcluster to duplicate a ‘component’ test for each component in a .json file; we also cannot specify specific platform specific features and lose a lot of the functionality that we gain with taskcluster;  I assume some simple thought and a feature or two would allow for us to retain all the features of taskcluster with the simplicity of component based scheduling
  4. We would need a concrete method for defining the list of components (#2 solves this for the harnesses).  Currently I add raw .json into the taskcluster decision task since it wouldn’t find the file I had checked into the tree when I pushed to try.  In addition, finding the right code names and mappings would ideally be automatic, but might need to be a manual process.
  5. when we run tests in parallel, they will have to be different ‘platforms’ such as linux64-qr, linux64-noe10s.  This is much easier in the land of taskcluster, but a shift from how we currently do things.

This is something I wanted to bring visibility to- many see this as the next stage of how we test at Mozilla, I am glad for tools like taskcluster, mozharness, and common mozbase libraries (especially manifestparser) which have made this a simple hack.  There is still a lot to learn here, we do see a lot of value going here, but are looking for value and not for dangers- what problems do you see with this approach?


Categorieën: Mozilla-nl planet

Air Mozilla: Reps Weekly Meeting Dec. 21, 2017

Mozilla planet - to, 21/12/2017 - 17:00

Reps Weekly Meeting Dec. 21, 2017 This is a weekly call with some of the Reps to discuss all matters about/affecting Reps and invite Reps to share their work with everyone.

Categorieën: Mozilla-nl planet

Air Mozilla: Reps Weekly Meeting Dec. 21, 2017

Mozilla planet - to, 21/12/2017 - 17:00

Reps Weekly Meeting Dec. 21, 2017 This is a weekly call with some of the Reps to discuss all matters about/affecting Reps and invite Reps to share their work with everyone.

Categorieën: Mozilla-nl planet

Mozilla Open Innovation Team: Applying Open Practices — Arduino

Mozilla planet - to, 21/12/2017 - 14:42

This is the fifth post in our Open by Design series describing findings from industry research on how companies use open practices, share knowledge, work, or influence in order to shape a market towards their business goals. This time we’ll take a look at Arduino, a name synonymous with hardware hacking for the masses.

Since 2003, this 50-person company, with offices in Europe and US, has build out a robust ecosystem of accessible, open electronics ideal for prototyping new technology and exploring novel hardware applications. The first Arduino board was introduced in 2005 to help design students without prior experience in electronics or micro-controller programming to create working prototypes connecting the physical world to the digital world. It has grown to become the world’s most popular teaching platform for physical prototyping. Arduino launched an integrated development environment (IDE) in 2015, and also has begun offering services to build and customize teaching materials suited to the specific needs of its educational partners.

Behind the widespread adoption of its hardware platform there is a focus on a guiding mission and a clearly-defined user group: making technology open and accessible for non-technical beginners. All hardware design and development decisions feed into keeping the experience optimal and consistent for this target group, attracting a solid, stable base of fans.

The popularity of an open-source platform does not, however, necessarily translate to a sustainable business model. One consequence of Arduino’s growing popularity has been the proliferation of non-licensed third-party versions of its boards. What can’t be cloned is Arduino’s model of community collaboration, strategic partnerships, and mix of open and closed practices — all primary forces in driving their ongoing success.

“Being open means you engage a lot of people with different skills and expertise — you create an ecosystem that is much more diverse that any company could create by itself. It also provides a lot of momentum for the company at the core, that is driving it (…) We are making something that exists no matter what happens to the company, it will continue to exist, it will still have a life of its own.”Dave Mellis, Co-Founder and former Software Lead — Arduino

Arduino was originally conceived as an educational kit to help creative people learn physical computing, and has always relied heavily on Learning from Use: which in this case, involved putting prototypes in front of students to study their learning process goals and frustrations, to gather ideas for how the kits could be made less confusing and more user-friendly. CEO Massimo Banzi personally teaches a number of Arduino workshops each year, giving him direct experiential knowledge that helps prioritize the organization’s hardware R&D efforts.

Continual improvement of its prototyping kits has extended Arduino’s popularity beyond technologists and designers, capturing the attention of artists who are interested in engaging with tech. Arduino’s specific focus on users with expertise in music, performance, and visual art who are passionate about publishing and sharing their work has increased the platform’s visibility, scope and speed of adoption.

On the IDE side, Arduino relies on a more expert community of designer-software specialists who have developed more in-depth technical expertise, and want to push the boundaries by creating custom libraries. In this community, a more familiar approach to open source is employed: creating together with a community of developers who form an essential part of the product development team.

With the launch of Arduino Education in 2015, the team brought creating together closer to the front end of the innovation timeline, collaborating to define services and materials with end users. Long before launching the service under the Arduino brand, the team conducted early explorations with teachers and schools to ensure the product was ideal for an established base of educators. This close collaboration averts the risk normally associated with new product development by ensuring a core community of users before the product is launched.

The Benefits of Participation

Arduino’s engagement with educational institutions and the maker community ensures a continuous feedback loop with end users, resulting in Better Products & Services in hardware. ‘Better’ in this case does not mean ‘technically more advanced’ than competitors — but rather that the boards, kits and instructions better fulfill Arduino’s educational mission. With the IDE, Arduino relies on an open source approach to Lower Product Development Costs. The educational services business — an extension of the Arduino brand — has co-developed its strategy with voices from the educational institutions, helping to anticipate their specific needs, driving even greater Adoption.

Alex Klepel & Gitte Jonsdatter (CIID)

https://cdn-images-1.medium.com/max/1200/1*ZJ4iaJ4OV4_nw3O3GQaaEA.png

Applying Open Practices — Arduino was originally published in Mozilla Open Innovation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

Andy McKay: The Mozilla Bug Firehose - Design Decisions

Mozilla planet - to, 21/12/2017 - 09:00

There could be many blog posts about the Mozilla bug firehose. This is just about dealing with one particular aspect.

When a bug comes into Mozilla it needs to get triaged - someone needs to figure out what to do with it. Triaging is an effort to try and get bugs appropriately classified to see how critical the bug is. Part of shipping a product every 6 weeks is that we have to try and fix crucial bugs in each release. To do that you have to read the bugs reports and try to understand what's happening.

We set aside a certain amount of time for triage meetings every week to triage those bugs. With product, engineering management, QA management and a bunch of engineers, those meetings are expensive to the whole organisation. So we started getting pretty ruthless on those triage meetings to keep them as short as possible .

One category of bugs that we got a lot of (an awful lot of) in WebExtension is a "feature request". This is where someone is asking for feature that we currently don't provide in the WebExtensions API. This one bug could slow down a whole triage as all the people look at a bug and think about it and try to decide if its a good idea or not. That's a terribly expensive and inefficient way to spend the triage meeting.

Instead we decided that we can do a few things:

  • We can usually determine quickly if a bug is within the bounds of WebExtensions or not. If not, it gets closed quickly.
  • We can usually determine quickly if a bug is reasonable or not. If it is, it goes into the backlog.
  • The rest go into a seperate bucket called design-decision-needed.

Then we have a seperate design-decision-needed meeting. For that meeting we do a few things:

  • Pick a few bugs from the bucket. For arbitrary reasons we pick the 3 oldest and 3 newest.
  • Try to involve the community, so we let the community know about the meeting and bugs before hand. All our meetings are public, but we specifically feel community should be involved in this one.
  • Ping the reporter before the meeting asking if they want to come to the meeting or enter more details in the bug.
  • Try to spend 5 minutes on each bug.
  • Try to find someone to argue for the bug, especially when everyone thinks it shouldn't happen.

There are currently 107 bugs needing a decision, 57 have been denied, 133 have been approved and 2 deferred. The deferred bugs are ones where we still have no real idea what to do with.

We are hoping this process means that:

  • Contributors can feel comfortable that before they start working on a bug, they know the patch will be accepted.
  • Everyone's time is respected, from developers to the reporters.
  • The process constrains internal developers time to prevent them from being overwhelmed by external requests.

The single best part of this process, was that we got our awesome Community Manager - Caitlin to run these triages. She does a much better job of working with the contributors and making them welcome than I can do.

So far we feel this process has been pretty good. One thing we need to improve is following up with comments on the bug quickly after the meeting. Some have fallen through the cracks and we struggle to remember later on what we discussed. Ideally, we do need more contributors to work on the bugs that have been marked as design-decision-approved. They are all there for the taking!

Categorieën: Mozilla-nl planet

Mozilla B-Team: happy shiney bmo push day

Mozilla planet - to, 21/12/2017 - 05:41

release tag

the following changes have been pushed to bugzilla.mozilla.org:

  • [1423391] Add additional phabricator settings to generate_conduit_data.pl for running bmo-extensions demo
  • [1424787] Due Date on bug modal is 1 day ahead
  • [1424155] Write scripts to import/export attachments to disk
  • [1376826] New HTML Header for BMO
  • [1425119] Allow the new-bug interface to be used
  • [1424940] Support HTML5 datepicker
  • [1403777] Migrate urlbase from params to localconfig
  • [1409957] Create polling daemon to query Phabricator for recent transcations and update bug data according to revision changes
  • [1422329] The phabricator conduit API method feed.query_id return data format has changed so the phabbugz_feed.pl daemon needs to be updated
  • [1420771] Remove global footer
  • [1426424] feed daemon complains when trying to set an inactive review flag
  • [1361890] Remove asset concatenation
  • [1426117] Failure when opening a bug: Invalid parameter passed to Bugzilla::Bug::new_from_list: It must be numeric.
  • [905763] Fix named anchors in various pages so that the Sandstone theme header can be set to a fixed position
  • [1424408] “Sign in with GitHub” button triggers a bugzilla security error, if I’m viewing a page with e.g. “t=”

discuss these changes on mozilla.tools.bmo.

Categorieën: Mozilla-nl planet

The Rust Programming Language Blog: Rust in 2017: what we achieved

Mozilla planet - to, 21/12/2017 - 01:00

Rust’s development in 2017 fit into a single overarching theme: increasing productivity, especially for newcomers to Rust. From tooling to libraries to documentation to the core language, we wanted to make it easier to get things done with Rust. That desire led to a roadmap for the year, setting out 8 high-level objectives that would guide the work of the team.

How’d we do? Really, really well.

There’s not room in a single post to cover everything that happened, but we’ll cover some of the highlights below.

The goals for 2017 Rust should have a lower learning curve Rust should have a pleasant edit-compile-debug cycle
  • The cargo check workflow
    • Cargo now offers a check subcommand which can be used to speed up the edit-compile cycle when you’re working on getting your code to pass the compiler’s checks. This mode, in particular, skips producing executable artifacts for crates in the dependency tree, instead doing just enough work to be able to type check the current crate.
  • Incremental recompilation
    • The cornerstone of our approach to improving compilation times is incremental recompilation, allowing rebuilds to reuse significant pieces of work from prior compilations. Over the course of the year we have put a lot of work into making this happen and now we are happy to announce that incremental compilation will start riding the trains with the next beta version of the compiler in January and become available on the stable channel with Rust 1.24 in February!
    • You can see how incremental recompilation performs in practice on some of our key benchmarks below. Note that -opt refers to optimized builds, “best case” refers to a recompilation with no changes, and println refers to a recompilation with a small change, like adding a println call to a function body. We expect the 50+% speedups we’re seeing now to continue to grow next year as we push incremental recompilation more deeply through the compiler.
    • Together with the changes in the compiler we will also update Cargo to use incremental recompilation by default for select use cases, so you can take advantage of improved compile times without the need for additional configuration. Of course you will also be able to opt into and out of the feature on a case by case basis as you see fit.

Incremental recompilation benchmarks

Rust should provide a solid, but basic IDE experience
  • Rust now has solid IDE support in IntelliJ and via the Rust Language Server (RLS). Whether you prefer a fully-featured IDE or a more lightweight editor with IDE features, you can boost your productivity by taking advantage of great Rust integration.
  • IntelliJ. Rust has official support in JetBrains’ IDEs (IntelliJ IDEA, CLion, WebStorm, etc.), which includes:
    • Finding types, functions and traits across the whole project, its dependencies and the standard library.
    • Hierarchical overview of the symbols defined in the current file.
    • Search for all implementations of a given trait.
    • Go to definition of symbol at cursor.
    • Navigation to the parent module.
    • Refactoring and code generation
  • RLS. The RLS is an editor-independent source of intelligence about Rust programs. It is used to power Rust support in many editors including Visual Studio Code, Visual Studio, and Atom, with more in the pipeline. It is on schedule for a 1.0 release in early 2018, but is currently available in preview form for all channels (nightly, beta, and stable). It supports:
    • Code completion (using Racer)
    • Go to definition (and peek definition if the editor supports it)
    • Find all references
    • Find impls for a type or trait
    • Symbol search (current file and project)
    • Reformatting using rustfmt, renaming
    • Apply error suggestions (e.g., to add missing imports)
    • Docs and types on hover
    • Code generation using snippets
    • Cargo tasks
    • Installation and update of the RLS (via rustup)
Rust should integrate easily into large build systems
  • Alternative registries. Cargo now has unstable support for installing crates from registries other than crates.io. This will enable companies to manage and use internal crates as easily as open source crates. Work is underway developing crate servers that are more tailored for private use than the crates.io server is.
  • Cargo as a component. A lot of work this year went into gathering constraints from stakeholders who want to integrate Rust crates into a large existing build system (like Bazel). The Cargo team has formulated a vision of Cargo as a suite of components that can be customized or swapped out, making it easy for an external build system to manage the work it is built to do, while still integrating with crates.io and with Cargo workflows. While we did not get as far as we hoped in terms of implementing this vision, there is ongoing work spiking out “build plan generation” to a sufficient degree that it can support the Firefox build system and Tup. This initial spike should provide a good strawman for further iteration in early 2018.
Rust should provide easy access to high quality crates Rust should be well-equipped for writing robust servers
  • Futures and Tokio
    • Much of the story for Rust on the server has revolved around its async I/O story. The futures crate was introduced in late 2016, and the Tokio project (which provides a networking-focused event loop for use with futures) published its 0.1 early in 2017. Since then, there’s been significant work building out the “Tokio ecosystem”, and a lot of feedback about the core primitives. Late in the year, the Tokio team proposed a significant API revamp to streamline and clarify the crate’s API, and work is underway on a book dedicated to asynchronous programming in Rust. This latest round of work is expected to land very early in 2018.
  • Async ecosystem
  • Generators
    • Thanks to a heroic community effort, Rust also saw experimental generator support land in 2017! That support provides the ingredients necessary for async/await notation, which is usable today on nightly. Further work in this area is expected to be a high priority in early 2018.
  • Web frameworks
    • Finally, sophisticated web frameworks like Rocket (sync) and Gotham (async) have continued to evolve this year, and take advantage of Rust’s expressivity to provide a robust but productive style of programming.
Rust should have 1.0-level crates for essential tasks
  • Libz Blitz. The library team launched the Libz Blitz this year, a major effort to vet and improve a large number of foundational crates and push them toward 1.0 releases. It was a massive community effort: we performed a crowd-sourced “crate evaluation” every two weeks, fully vetting a crate against a clear set of guidelines, assessing the issue tracker, and sussing out any remaining design questions. While not all of the assessed crates have published a 1.0 yet, they are all very close to doing so. The full list includes: log, env_logger, rayon, mio, url, num_cpus, semver, mime, reqwest, tempdir, threadpool, byteorder, bitflags, cc-rs, walkdir, same-file, memmap, lazy_static, flate2.
  • API Guidelines. A great by-product of the Libz Blitz is the API Guidelines book, which consolidates the official library team API guidance as informed by the standard library and the Libz Blitz process.
Rust’s community should provide mentoring at all levels
  • We ran 5 RustBridge Workshops in 2017, in Kyiv, Ukraine; Mexico City, Mexico; Portland, OR, USA; Zurich, Switzerland; and Columbus, OH, USA! RustBridge workshops aim to get underrepresented folks started in Rust. Attendees get an introduction to syntax and concepts, work on some exercism exercises, and build a web application that delivers emergency compliments and crab pictures. We hope to scale this program and help more folks run more workshops in 2018!
  • The Increasing Rust’s Reach program brought people with skills from other areas (such as teaching) and with different experiences into Rust so that we can improve in areas where the community is missing these skills and experiences. The participants have helped immensely, and many are planning to continue helping in the Rust community going forward. We’re glad they’re here! Here are some blog posts about the experience:
  • Last but not least, we also launched the first Rust impl Period. This was an ambitious effort to simultaneously help get a lot of new people contributing to the Rust ecosystem while also getting a lot of things done. To that end, we created 40+ working groups, each with their own focus area, leaders, and chat channel. These groups identified good “entry points” for people who wanted to contribute, and helped mentor them through the changes needed. This event was a wild success and resulted in changes and contributions to all areas of Rust, ranging from the compiler internals to documentation to the ecosystem at large. To those of you who participated, a great big thank you — and please keep contributing! To those of you who didn’t get a chance, don’t worry: we hope to make this a regular tradition.
2018

We’ll be spinning up the 2018 roadmap process in the very near future; watch this space!

Thank you!

We got a staggering amount of work done this year — and the “we” here includes an equally staggering number of people. Because the work has been spread out over so many facets of the project, it’s hard to provide a single list of people who contributed. For the impl period specifically, you can see detailed contribution lists in the newsletters:

but of course, there have been contributions of all kinds during the year.

In this post, I’d like to specifically call out the leaders and mentors who have helped orchestrate our 2017 work. Leadership of this kind — where you are working to enable others — is hard work and not recognized enough. So let’s hand it to these folks!

  • Cargo
    • carols10cents, for sustained leadership and mentoring work throughout the year on crates.io.
  • Community
  • Compiler
    • nikomatsakis, for an incredible amount of leadership, organization, and mentoring work, and for a lot of high-value hacking on NLL in particular.
    • arielb1, likewise for mentoring and hacking work, spanning both NLL and the rest of the compiler.
    • michaelwoerister, for pushing continuously on delivering incremental recompilation, and creating opportunities for others to join in throughout the year.
    • eddyb, for continuing to act as a general compiler guru, and for tackling some truly heavy lifts around const generics this year.
  • Dev tools
    • nrc, for overseeing the dev tools group as a whole, and for steady work toward shipping the RLS and rustfmt, despite many thorny infrastructure problems to get there.
    • matklad, for the incredible work on IntelliJ Rust.
    • xanewok, for enormous efforts making the RLS a reality.
    • fitzgen, for happily corralling a huge contributor base around bindgen.
  • Docs
    • steveklabnik, for launching and overseeing a hugely exciting revamp of rustdoc.
    • quietmisdreavus, for overseeing tons of activity in the docs world, but most especially for helping the community significantly improve rustdoc this year.
  • Infrastructure
    • mark-simulacrum, for getting the perf website to a highly useful state, and for overhauling rustbuild to better support contribution.
    • aidanhs, for coordinating maintenance of crater.
  • Language
    • withoutboats, for keeping us focused on the programmer experience and for helping the community navigate discussion around very thorny language design issues.
    • cramertj, for keeping us focused on shipping, and in particular building consensus around some of the topics where that’s been hardest to find: impl Trait, and module system changes.
    • nikomatsakis, for making the NLL RFC so accessible, and pioneering the idea of using a separate repo for it to allow for greater participation.
  • Libraries
    • brson, for envisioning and largely overseeing the Libz Blitz initiative.
    • kodraus, for gracefully taking over the Libz Blitz and seeing it to a successful conclusion.
    • dtolnay, for taking on the API guidelines work and getting it to a coherent and polished state.
    • budziq, for a ton of work coordinating and editing contributions to the cookbook.
    • dhardy, for leading a heroic effort to revamp the rand crate.

Technical leaders are an essential ingredient for our success, and I hope in 2018 we can continue to grow our leadership pool, and get even more done — together.

Categorieën: Mozilla-nl planet

The Mozilla Blog: Plugging in on Policy

Mozilla planet - wo, 20/12/2017 - 23:00
Mozilla Tech Policy Fellows continue to lead policy conversations around the world.

 

When Mozilla rolled out a new fellowship focused on tech policy this past June, the goal was to gather some of the world’s top policymakers in tech to continue advancing the important initiatives they were working on in government as fellows with Mozilla.

We rounded up 10 fellows from the U.S., Brazil, India, and Kenya as part of the initial cohort. Fellows are spending the year keeping the Internet open and free both by furthering the crucial work they had already been leading, and by finding new ways to add to forward-thinking policy efforts.

Fellows are urging policymakers to keep net neutrality in the United States and to adopt it in India, they’re promoting data privacy and security in East Africa and Brazil, and they’re encouraging increased access to high-quality broadband in vulnerable communities in rural, urban, and tribal areas everywhere. The fellows have all described their work in depth on Mozilla’s network blog:

Alan Davidson is advancing policies and practices to support building the field of public interest technologists — the next generation of leaders with expertise in technology and public policy who we need to guide our society through coming challenges such as encryption, autonomous vehicles, blockchain, cybersecurity, and more.

Amina Fazlullah is exploring policies that will help lower the cost of broadband access, support broad adoption, ensure that applications are developed with the most vulnerable users in mind, promoting a fair and open Internet, and identifying and highlighting the good work of digital inclusion organizations around the world.

Camille Fischer worked on policies that support legal protections for privacy rights in the U.S. Camille completed her fellowship and recently joined the Electronic Frontier Foundation as a fellow working on free speech and government transparency.

Caroline Holland is working to promote competition for a healthy Internet to make sure consumers have access to affordable and competitive high speed broadband and equal access to the lawful content they desire.

Amba Kak is moving policies forward on net neutrality, zero rating and the open Internet in India, including supporting the country’s recent commitment to comprehensive net-neutrality protection.

— In East Africa, Linet Kwamboka is working to promote policies that support data protection and privacy as well as data literacy for the public.

Terah Lyons explored the global role of stakeholders from public, private, civil society, and academic stakeholder communities on AI policy to address issues related to ethics, accountability, the future of work, and safety and control. Terah recently completed her fellowship and joined the Partnership on AI as its first Executive Director.

–From Brazil, Marília Monteiro is working to analyze tech policy issues from a consumer protection perspective to ensure that policy makers are balancing consumer interests with technology and innovation advances.

Jason Schultz is exploring AI’s impact on open technologies including the need for new methods both to measure the negative impacts of AI closure and to adapt alternatives in meaningful technological, economic, and social ways.

Gigi Sohn is continuing her nearly 30-year fight for fast, fair, and open networks, including working to keep net neutrality in the U.S.

The Tech Policy Fellows gathered at MozFest, Mozilla’s annual festival for the open Internet movement, in October. They led workshops, roundtables, and panels, and — of course — met Foxy.

Mozilla Tech Policy Fellow Amina Fazlullah meets Foxy at MozFest.

Fellows are also contributing to the upcoming 2018 version of the Internet Health Report (you can get involved with that project, too!) and they are working closely with a dedicated Advisory Board, made up of seven top experts and supporters of a free and open Internet located in six different countries.

Mozilla will begin recruiting for a new cohort of fellows in 2018 — keep an eye out for our announcement and help us bring together even more amazing tech policy leaders to advance this crucial work.

The post Plugging in on Policy appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Plugging in on Policy

Mozilla Blog - wo, 20/12/2017 - 23:00
Mozilla Tech Policy Fellows continue to lead policy conversations around the world.

 

When Mozilla rolled out a new fellowship focused on tech policy this past June, the goal was to gather some of the world’s top policymakers in tech to continue advancing the important initiatives they were working on in government as fellows with Mozilla.

We rounded up 10 fellows from the U.S., Brazil, India, and Kenya as part of the initial cohort. Fellows are spending the year keeping the Internet open and free both by furthering the crucial work they had already been leading, and by finding new ways to add to forward-thinking policy efforts.

Fellows are urging policymakers to keep net neutrality in the United States and to adopt it in India, they’re promoting data privacy and security in East Africa and Brazil, and they’re encouraging increased access to high-quality broadband in vulnerable communities in rural, urban, and tribal areas everywhere. The fellows have all described their work in depth on Mozilla’s network blog:

Alan Davidson is advancing policies and practices to support building the field of public interest technologists — the next generation of leaders with expertise in technology and public policy who we need to guide our society through coming challenges such as encryption, autonomous vehicles, blockchain, cybersecurity, and more.

Amina Fazlullah is exploring policies that will help lower the cost of broadband access, support broad adoption, ensure that applications are developed with the most vulnerable users in mind, promoting a fair and open Internet, and identifying and highlighting the good work of digital inclusion organizations around the world.

Camille Fischer worked on policies that support legal protections for privacy rights in the U.S. Camille completed her fellowship and recently joined the Electronic Frontier Foundation as a fellow working on free speech and government transparency.

Caroline Holland is working to promote competition for a healthy Internet to make sure consumers have access to affordable and competitive high speed broadband and equal access to the lawful content they desire.

Amba Kak is moving policies forward on net neutrality, zero rating and the open Internet in India, including supporting the country’s recent commitment to comprehensive net-neutrality protection.

— In East Africa, Linet Kwamboka is working to promote policies that support data protection and privacy as well as data literacy for the public.

Terah Lyons explored the global role of stakeholders from public, private, civil society, and academic stakeholder communities on AI policy to address issues related to ethics, accountability, the future of work, and safety and control. Terah recently completed her fellowship and joined the Partnership on AI as its first Executive Director.

–From Brazil, Marília Monteiro is working to analyze tech policy issues from a consumer protection perspective to ensure that policy makers are balancing consumer interests with technology and innovation advances.

Jason Schultz is exploring AI’s impact on open technologies including the need for new methods both to measure the negative impacts of AI closure and to adapt alternatives in meaningful technological, economic, and social ways.

Gigi Sohn is continuing her nearly 30-year fight for fast, fair, and open networks, including working to keep net neutrality in the U.S.

The Tech Policy Fellows gathered at MozFest, Mozilla’s annual festival for the open Internet movement, in October. They led workshops, roundtables, and panels, and — of course — met Foxy.

Mozilla Tech Policy Fellow Amina Fazlullah meets Foxy at MozFest.

Fellows are also contributing to the upcoming 2018 version of the Internet Health Report (you can get involved with that project, too!) and they are working closely with a dedicated Advisory Board, made up of seven top experts and supporters of a free and open Internet located in six different countries.

Mozilla will begin recruiting for a new cohort of fellows in 2018 — keep an eye out for our announcement and help us bring together even more amazing tech policy leaders to advance this crucial work.

The post Plugging in on Policy appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Chris H-C: Another Stay of Execution for Firefox Users on Windows XP

Mozilla planet - wo, 20/12/2017 - 21:44

windows_xp_bliss-wide_dusk

Firefox users who are on Windows XP now have until August 28, 2018 to upgrade their machines. In the grand Internet tradition I will explore this by pretending someone is asking me questions.

Why?

The last Firefox release supporting Windows XP is Firefox ESR 52. Previously Firefox ESR 52 was set to end-of-life on or around May of 2018 after the next ESR, Firefox ESR 59, had been released and stabilized. Now, with an email to the Enterprise, Dev Platform, Firefox Dev, and Mobile Firefox Dev mailing lists, :Sylvestre has announced that the next ESR will be Firefox ESR 60, which extends the Firefox ESR 52 end-of-life to August 28, 2018.

No, not “Why did it change,” Why should anyone still care about Windows XP? Hasn’t it been out-of-service for a decade or something?

Not quite a decade, but the last release of Windows XP was over nine years ago, and even Microsoft’s extended support tapped out nearly four years ago.

But as to why we should care… well, Windows XP is still a large-ish portion of the Firefox user base. I don’t have public numbers in front of me, but you can see the effect the Windows XP Firefox population numbers had on the Firefox Hardware Report when we diverted them to ESR this past March. At that time they were nearly 8.5% of all Firefox users. That was more than all versions of Mac Firefox users.

Also, it’s possible that these users may be some of the most vulnerable of the Internet’s users. They deserve our thought.

Oh, okay, fine. If they matter so much, why aren’t we supporting them forever?

As you can see from the same Firefox Hardware Report, the number of Windows XP Firefox users was in steady decline. At some point our desire and capability to support this population of users can no longer match up with our desire to ship the best experience to the most users.

Given the slope of the decline in the weeks leading up to when we migrated Windows XP Firefox users to Firefox ESR, we ought to be getting pretty close to zero. We hate to remove support from any users, but there was a real cost to supporting Windows XP.

For instance, the time between the ESR branch being cut and the first Windows XP-breaking change was a mere six days. And it wasn’t on purpose, we were just fixing something somewhere in Gecko in a way that Windows XP didn’t like.

So who are we going to drop support for next?

I don’t know of any plans to drop support for any Operating Systems in the near future. I expect we’ll drop support for older compilers in our usual manner, but not OSs.

That pretty much sums it up.

If you have any questions about Firefox ESR 60, please check out the Firefox ESR FAQ.

:chutten


Categorieën: Mozilla-nl planet

Firefox Test Pilot: Students Pitch New Accessibility Features for Firefox

Mozilla planet - wo, 20/12/2017 - 20:56

In early October, the Test Pilot team helped kick off an undergraduate product design course at design and media school Ravensbourne in London. The partnership with Ravensbourne was spearheaded by Mozilla’s Open Innovation team with the goal of generating ideas for Mozilla’s innovation pipeline. With Test Pilot as the “client” for the course, students working in seven small teams have been iterating on design concepts to advance accessibility in Firefox. Test Pilot team members John Gruen and I were back in London last month to evaluate the student’s final product pitches. We ultimately chose two winning teams.

First Place: Team Spectrum

The winning team set out to improve the browser experience for individuals with phonological dyslexia. After conducting both secondary and primary research, the team identified an opportunity to help alleviate the tired eyes and general cognitive overhead that individuals with dyslexia experience when reading text on the web. Team Spectrum’s solution is an add-on that allows people to enlarge and embolden text and apply color filters to increase contrast — all from the browser toolbar.

<figcaption>Screenshot from Team Spectrum’s prototype showing a large cursor intended to make it easier to enlarge and embolden text for more comfortable reading</figcaption>

The team conducted some initial usability testing and found that their solution increased reported ease of reading and reading speed.

Honorable Mention: Team Elderline

The second place team was interested in helping older adults use the browser more easily by creating an add-on to surface customization options. Through their research, Team Elderline determined that among the biggest opportunities were to support adults over 75-years-old in: reading online more comfortably, reducing confusing ads on webpages, and understanding icons representing valuable browser controls. The team’s solution is a control panel that lets people easily manipulate the current webpage to make content more accessible and manageable.

<figcaption>Screenshot from Team Elderline’s prototype showing control panel options tailored to the current webpage</figcaption>

Based on what they learned from initial usability testing of their concept, Team Elderline’s final concept emphasized plain language and clearer selection indicators.

In addition to the pitches by Teams Spectrum and Elderline, the other student teams presented a range of intriguing concepts to support challenges encountered by older adults, students with dyslexia, and individuals with Attention Deficit Hyperactivity Disorder (ADHD) in the browser.

Next Steps

We will be sharing the winning concepts with the broader Test Pilot team and investigating the feasibility of turning the concepts into future experiments. Thanks to all of the Ravensbourne students for your fresh thinking on improving Firefox through accessibility! Read more about our collaboration with Ravensbourne on their blog.

Students Pitch New Accessibility Features for Firefox was originally published in Firefox Test Pilot on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

The Firefox Frontier: Private shopping is smart holiday shopping

Mozilla planet - wo, 20/12/2017 - 20:47

Maybe Santa’s running a little late this year. There are gifts left to buy. You’re shopping online. You’re hoping you make it under the wire for shipping. Basically, you’re trying … Read more

The post Private shopping is smart holiday shopping appeared first on The Firefox Frontier.

Categorieën: Mozilla-nl planet

Air Mozilla: Sheriffing episode 1 - failure starring and beta uplifts

Mozilla planet - wo, 20/12/2017 - 19:35

Sheriffing episode 1 - failure starring and beta uplifts 00:00 identifying failure in second line of log summary 01:19 failure not in log summary 02:14 test name of failing test not in log summary...

Categorieën: Mozilla-nl planet

Air Mozilla: Sheriffing episode 1 - failure starring and beta uplifts

Mozilla planet - wo, 20/12/2017 - 19:35

Sheriffing episode 1 - failure starring and beta uplifts 00:00 identifying failure in second line of log summary 01:19 failure not in log summary 02:14 test name of failing test not in log summary...

Categorieën: Mozilla-nl planet

Air Mozilla: The Joy of Coding - Episode 124

Mozilla planet - wo, 20/12/2017 - 19:00

The Joy of Coding - Episode 124 mconley livehacks on real Firefox bugs while thinking aloud.

Categorieën: Mozilla-nl planet

Air Mozilla: The Joy of Coding - Episode 124

Mozilla planet - wo, 20/12/2017 - 19:00

The Joy of Coding - Episode 124 mconley livehacks on real Firefox bugs while thinking aloud.

Categorieën: Mozilla-nl planet

Firefox lands on Amazon's Fire TV - TechCrunch

Nieuws verzameld via Google - wo, 20/12/2017 - 18:04

TechCrunch

Firefox lands on Amazon's Fire TV
TechCrunch
If you own an Amazon Fire TV, you can now use Firefox to browse the web on your TV. As Mozilla and Amazon announced today, Firefox, which joins Amazon's own Silk browser on the device, is now available for all your browsing needs. “Bringing Firefox to ...
Firefox is now available on Amazon's Fire TV, and it can access YouTubeThe Verge
It didn't start the fire, but Mozilla fuels feud with Firefox for Fire TVNeowin
Mozilla's Firefox Web Browser for Amazon Fire TV is Now AvailablegroovyPost
Lifehacker
alle 144 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Air Mozilla: Weekly SUMO Community Meeting December 20, 2017

Mozilla planet - wo, 20/12/2017 - 18:00

Weekly SUMO Community Meeting December 20, 2017 This is the SUMO weekly call

Categorieën: Mozilla-nl planet

Air Mozilla: Weekly SUMO Community Meeting December 20, 2017

Mozilla planet - wo, 20/12/2017 - 18:00

Weekly SUMO Community Meeting December 20, 2017 This is the SUMO weekly call

Categorieën: Mozilla-nl planet

Pages