Skip to content

Latest commit

 

History

History
145 lines (85 loc) · 9.06 KB

faq.md

File metadata and controls

145 lines (85 loc) · 9.06 KB

Questions

Why are we using GitHub?

There are four factors that led us to choose to use GitHub issues:

  • Our code lives in GitHub, and being able to refer to code changes (pull requests) in the same organizational model as the issue management makes eminent practical sense for managing bugs and feature progress.

  • GitHub is a central point of activity for open source activity, especially web development, which is a large part of what we do. There are network effects that we hope will yield more active volunteer contributions to our projects.

  • GitHub is amazingly self-service and granular. We can have as many repos, with as many teams and bug categorization systems as we want, without having to go through a manual process.

  • The GitHub API means we can build custom tools to fit the process we want, rather than having to adapt to the Bugzilla process.

There are definite downsides to not using Bugzilla, but we believe the tradeoff currently favors GitHub for our needs in 2015. We can revisit next year.

When I should you use GitHub issues?

  • When you're working with designers, developers or product management
  • To let the rest of MoFo know about an important piece of work happening (because it may affects how others are planning).
  • Whenever you think it would be helpful! Working in tickets/issues/bugs (instead of email threads) can be a great way to increase speed, collaboration, agility, openness and communication. Feel free to play around and make it your own! It's impossible to break anything. It's easy, free and self-service to create a public repository and associated issue tracker in GitHub, so you may just find it handy.

When should I use Bugzilla or something else?

  • When you're working closely with MoCo colleagues who use Bugzilla. Not all parts of MoCo use Bugzilla, but many do, in particular, legal, privacy, engagement, etc. Anything confidential shouldn't be done in a GitHub public issue tracker (GitHub doesn't support making individual bugs "not-public").
  • When you're working with Studio MoFo. Instead, use their intake form
  • When you need the MoFo Operations team (finance, HR, admin) to do something. Their Bugzilla input is here.

Getting started

  1. Create your GitHub account (if you don't already have one, it's free). If you pick a nickname that is close to your name, it'll make your colleagues life easier.
  2. Log in
  3. Fill out your profile
  4. Ask one of the members of the owners group to add you to the "MozillaFoundation" organization, so that your handle will come up in autocomplete for example.

Want to play around?

Here's a testing sandbox you can play around in, to get your feet wet with filing, labeling and playing around with tickets

Top Tips

  • Tweak your email notifications. We suggest adjusting your settings to only receive emails on stuff you care about. e.g., conversations your participate in. Or when someone mentions you.

email_settings

  • If you say something in an issue, you'll get email whenever anyone else makes a comment or a change. You can simply click the "unsubscribe" button on issues that you don't want/need to follow.

  • Check out build.webmaker.org. It makes a lot of this GitHub stuff waaaaay easier. (And we can improve it as we go). If you want to see what we're working on, propose a new project idea, or get an overview of how we're using GitHub, this is a great place to start.

We've put together some more GitHub tips

What should I do if I'm stuck or have a question?

  • Ask in #webmaker IRC.
  • For Learning Networks: ask Lainie or Hannah.
  • For Learning Products: ask Wex, Cassie or Andrew.
  • For all else: ask OpenMatt.
  • If you don't know who any of these people are: ask a friend, colleague, anyone.

We're here to help -- no question is too big or small.

(Q: can we overexplain this section for the sake of helping external contributors - i.e. link to our how to use IRC, and give contact details / twitter handles etc... Or that might be a seperate document?)

Which GitHub repo should I use?

There are lots of repos, and many of them have their own issue trackers. Mozilla has probably over 2000 repos overall. The MoFo repos we know about are:

Some notable repos:

How about filing a bug?

If you're trying to file a bug on a website, it's a good idea to look for a repo with the name of the website under the mozilla org. So, if you see a bug in build.webmaker.org, you can file a bug in github.com/mozilla/build.webmaker.org/issues/new

Good candidates:

When in doubt, file under webmaker.org, we'll figure it out.

What's the plan repo?

It's the repo where we track the initiatives to resource and schedule them in heartbeats. Read all about it.

What are heartbeats again?

Read all about it.

Where should I create a repo?

Software generally should end up under the mozilla org, but it may make sense to start exploring in your personal repo until you're ready for collaborators. We can transfer a repo from an individual to an org when that's needed (sometime after rough draft and before it shows up in a heartbeat, and well before it shows up in production).

Repos that are primarily used to either house documents or just issues can be in any of the orgs we have (mozilla, MozillaFoundation, MozillaHive). Creating a new 'org' means you get a space that random people won't find easily, and that contributors won't find if they're not clued in, so we generally don't recommend it.

Unanswered questions