You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -243,7 +244,7 @@ Mozilla has and continues to hire many people from within the Open Source Softwa
243
244
**Referrals**. If you’ve been making reasonable and regular contributions to the project we’d be happy to be a reference for you. We can make internal referrals to Mozilla or act as your reference to other companies. Please be considerate when making this request, we are happy to help you and want to see you find a job you want but can’t do this for everyone who contributes.
Copy file name to clipboardExpand all lines: docs/issues.md
+9-10Lines changed: 9 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@
4
4
*[Issue Descriptions](#issue-descriptions)
5
5
*[Claiming Issues](#claiming-issues)
6
6
*[Labels](#labels)
7
-
*[Up For Grab Issues](#up-for-grab-issues)
7
+
*[Available Issues](#available-issues)
8
8
*[Triaging](#triaging)
9
9
*[Issue Organization](#issue-organization)
10
10
*[Community Friendly](#community-friendly)
@@ -101,7 +101,7 @@ These are the [labels](https://github.com/devtools-html/debugger.html/labels) we
101
101
102
102
| Label name | query:mag_right:| Description |
103
103
| --- | --- | --- |
104
-
|`up-for-grabs`|[search][labels-up-for-grabs]| Good for contributors to work on |
104
+
|`available`|[search][labels-available]| Good for contributors to work on |
105
105
|`difficulty:easy`|[search][labels-difficulty-easy]| Work that is small changes, updating tests, updating docs, expect very little review |
106
106
|`difficulty:medium`|[search][labels-difficulty-medium]| Work that adapts existing code, adapts existing tests, expect quick review |
107
107
|`difficulty:hard`|[search][labels-difficulty-hard]| Work that requires new tests, new code, and a good understanding of project; expect lots of review |
@@ -114,15 +114,14 @@ These are the [labels](https://github.com/devtools-html/debugger.html/labels) we
114
114
|`infrastructure`|[search][labels-infrastructure]| Issues with testing / build infrastructure |
115
115
|`discussion`|[search][labels-discussion]| Issues need clearer requirements before work can be started |
116
116
117
-
### Up For Grab Issues
117
+
### Available Issues
118
118
119
-
[up for grabs][labels-up-for-grabs] issues have clear requirements and a difficulty level.
119
+
[available][labels-available] issues have clear requirements and a difficulty level.
120
120
121
121
They often have a patch, which should be a good starting off point.
122
122
Sometimes the patches are enough to fix the bug!
123
123
124
-
One reason we file up for grabs issues when the solution is somewhat simple is that it's great to get a second
125
-
set of eyes. Running the fix locally and QAing it thoroughly is a huge help. A lot of times you'll discover things that we missed.
124
+
One reason we file `available` issues when the solution is somewhat simple is that it's great to get a second set of eyes. Running the fix locally and QAing it thoroughly is a huge help. A lot of times you'll discover things that we missed.
126
125
127
126
### Triaging
128
127
@@ -131,10 +130,10 @@ It's one of the most helpful ways to help a project.
131
130
132
131
There are a couple of ways to think about it:
133
132
* it's great to be able to close issues that are done or stale
134
-
* it's great to make issue descriptions as clear as possible. Our goal is for every issue to be *actionable* i.e. it's clear what needs to be done.
133
+
* it's great to make issue descriptions as clear as possible. Our goal is for every issue to be `available` i.e. it's clear what needs to be done.
135
134
* it's really helpful to double check a new bug and see if you can reproduce it.
136
-
* it's great to ask questions that help make the issue actionable or call out vague issues.
137
-
* it's great to sort the issues by oldest first and help make stale issues actionable.
135
+
* it's great to ask questions that help make the issue available or call out vague issues.
136
+
* it's great to sort the issues by oldest first and help make stale issues available.
138
137
139
138
### Issue Organization
140
139
@@ -152,7 +151,7 @@ We focus on being community friendly for many reasons.
152
151
* There's an incredible diversity of talent to help us with topics ranging from testing to internationalization.
153
152
* Focusing on *contributor experience* helps us build the best development environment. For instance, if you find it's hard to describe how to make an accessibility change, maybe we should improve how we support tab navigation.
Copy file name to clipboardExpand all lines: docs/maintainer.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,22 +10,22 @@ Helping maintain a project is the best way to contribute to its overall health.
10
10
11
11
#### Closing Stale Issues
12
12
13
-
We define *stale* as issues that are 30 days or older. Stale is often an indicator of another issue: it is unecessary, too vague, too broad, or a low priority.
13
+
We define *stale* as issues that are 30 days or older. Stale is often an indicator of another issue: it is unnecessary, too vague, too broad, or a low priority.
14
14
15
-
**unecessary* - close it
16
-
**vague* - clarify the issue and make it more actionable
15
+
**unnecessary* - close it
16
+
**vague* - clarify the issue and make it more available
17
17
**broad* - create more focused issues, such as "add flow types to `WhyPaused` component"
18
18
**low priority* - close it and add it to the [enhancements board]
19
19
20
-
#### Making Issues Actionable a.k.a "Up for Grabs"
20
+
#### Making Issues `available`
21
21
22
-
Actionable is short for two things:
22
+
Available is short for two things:
23
23
24
24
1. a clearly defined specification (end-state)
25
25
2. a clear implementation plan
26
26
27
-
Our goal is to have 100% of our issues actionable or blocked by another actionable ticket.
28
-
If you find an issue that is not actionable you can:
27
+
Our goal is to have 100% of our issues available or blocked by another available ticket.
28
+
If you find an issue that is not available you can:
29
29
30
30
1. investigate the issue and answer questions that you have
31
31
2. share questions or offer reasonable solutions that can be implemented
@@ -56,7 +56,7 @@ I recommend [ship] for tracking issues.
56
56
57
57
Patches are a great way to clarify what work needs to be done.
58
58
59
-
Patches on "up for grabs" issues help clarify where the code should go and are often clearer than english.
59
+
Patches on `available`issues help clarify where the code should go and are often clearer than English.
0 commit comments