Hi Matt,
Thanks for reaching out - your course sounds like an exciting way to
get real-world experience for your students and is something we'd love
to help you where we can.
We certainly do have a backlog of low-priority work. While we do make
some effort to flag "easy" issues, we don't really end up with many that
truly are easy. As a result, I'd expect many of the items in that
backlog probably aren't really suitable for somewhat "casual"
contributors - but we'd be happy to help you determine what you think
might be OK for your students to tackle.
This team has 2 broadly defined efforts which might be suitable:
* "Application Services" is our effort to implement syncing and Firefox
Accounts related services for Firefox products in Rust, with the aim of
using these components in all our mobile and desktop products. This work
is done in https://github.com/mozilla/application-services, and
interesting labels to get started with are "good-first-issue",
"good-second-issue" and "cleanups"
* Sync/Firefox Accounts in Desktop Firefox. Desktop Firefox is our
"bread and butter" and has a sync implementation written in javascript.
It's pushing 10 years old so has a fair bit of cruft. Over the next few
years we intend moving the rust components into desktop, but planning is
just getting underway for that - and in the meantime we need to keep
Desktop humming along. Issue tracking for this is done in bugzilla - see
[1] for a very long URL :) We do have a keyword "good-first-bug", but
there are only 2 bugs in that category. We consider any bug with a
"mentor" set to be a "good second bug" - there are a handful of them -
see [2]
Many of the issues you'll find will require a fair bit of context to
make progress on, which may test the patience of both your students and
you! However, if you have a poke around and can find some issues which
you think are suitable, then we'd be happy to help support your efforts.
The other members of the team might have additional thoughts or ideas -
hopefully they will chime in if they do!
Communicating with us via email is fine. While slack is probably better
in many ways, there's a bit of a process involved -
https://wiki.mozilla.org/NDA-Slack has some of those details. I guess it
depends on how many hoops you are willing to jump through!
Let us know how we can help further.
Cheers,
Mark
[1] - all desktop sync and fxa bugs:
https://bugzilla.mozilla.org/buglist.cgi?component=Firefox
Accounts&component=Sync&product=Firefox&resolution=---&classification=Client
Software&classification=Developer
Infrastructure&classification=Components&classification=Server
Software&classification=Other&query_format=advanced
[2] - desktop sync and fxa bugs with a mentor set:
https://bugzilla.mozilla.org/buglist.cgi?list_id=14992010&resolution=---&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&emailtype1=regexp&query_format=advanced&email1=.%2A&emailbug_mentor1=1&component=Firefox%20Accounts&component=Sync&product=Firefox
On 14/11/2019 9:49 am, Lang_Matthew wrote:
Hi Application Services team!
Elise Richards suggested that I reach out to you about a possible collaboration.
I’m a professor at Rhodes College: a small, selective, undergraduate-only
institution. This coming Spring I’m teaching an upper-level software
engineering course.
I’m curious whether your team would be interested in having my students
contribute.
Ideally I would like to partner with a team that has a backlog of low-priority
feature work, bugs, tech debt/janitorial work, etc and wouldn’t mind some
attention to clearing some of it.
I want this to be as low-effort as possible on your engineering team; I would
take responsibility of being a filter between students and you (to the degree
you desire). I have experience in industry—I was at Google for 6 years prior to
this fall, where I was TL of team building distributed data processing tools.
Let me know if this is interesting your team; if so, we can start talking. I’m
happy to VC if you want to chat in person, otherwise email/IRC/Slack would be
fine.
If we go forward, my goal would be to invest in ramping up to be a contributor
over the next few months so that I am in a position to make sure your team’s
velocity isn’t affected by interrupts.
Let me know if there’s any interest and any questions you have!
Thanks and best,
Matt Lang
Assistant Professor of Computer Science
Rhodes College
p.s., A little more info: My goal for the course is to have students come out
of the course understanding the process and reality of real-world software
engineering. I want my students to gain the process skills that are necessary
for building real-world systems: deep debugging, integration challenges,
testing and deployment, configuration management, etc.
The class is 25 juniors and seniors with C++ experience. I had a similar
demographic in a distributed systems class and got them ramped up to Go pretty
quickly; I would image that Rust wouldn’t be a barrier. I would be dividing
them into groups and overseeing them, and would filter any interrupts that
would come to you.
Here’s the course description if you are interested:
"The software systems we often find the most useful and magical are also the largest
and most complex to build and understand. In order for these systems to be reliable,
maintainable, and secure, they must be built according to disciplined and well-founded
methods. This course examines these methods—both in the large (defining requirements,
system design, architecture patterns, software process, etc.) and in the small (version
control, testing, benchmarking, code review, etc.). At the same time, students will
engage in the construction of a large software system or feature."
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
