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
Copy file name to clipboardExpand all lines: app/views/university/example_app.md.erb
+18-9Lines changed: 18 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -1,19 +1,31 @@
1
1
An example app is an application that is designed to reproduce a bug or demonstrate an issue.
2
2
3
-
An example app is not a gigantic repo, your private source code, or telling someone a series of bash commands.
3
+
**Q: "What is an example app?"**
4
4
5
-
Before a bug can be fixed, it has to be understood and reproduced. For every issue, a maintainer gets, they have to decipher what was supposed to happen and then spend minutes or hours piecing together their reproduction.
5
+
A way to reliably trigger a bug or demonstrate bad behavior in a contained, easily executable application. It is a specific form of [a reproduction](https://codetriage.com/reproduction).
6
6
7
-
Usually, they can't get it right, so they have to ask for clarification. This back-and-forth process takes lots of energy and wastes everyone's time. Instead, it's better to provide an example app from the beginning.
7
+
**Q: "What isn't an example app?"**
8
8
9
-
At the end of the day, would you rather maintainers spend their time making example apps or fixing issues?
9
+
An example app is not a step-by-step story of things you did to trigger the error, such as "I clicked this link" or "I entered this command" or "I compiled this code." While such descriptions can sometimes be helpful, they're often missing crucial contexts that might require guessing on the part of the person debugging. Chances are if your "reproduction" doesn't involve source control, it's not "a reproduction app."
10
+
11
+
**Q: "Why should I make an example app?"**
12
+
13
+
Before someone can fix a bug, they need to understand why it happens. While descriptions can help, the golden standard for debugging code is to be able to reproduce the bug. The easier it is to reproduce the bug, the shorter the debugging cycles will take, and the faster it can be fixed.
14
+
15
+
**Q: "Does that mean I should send my whole application over when I open a bug report?"**
16
+
17
+
Please no. Reproduction code is best when there's a minimal amount of code necessary to reproduce the issue. The more extra stuff there is, the harder it may be to separate what's causing the bug versus what's just there.
18
+
19
+
**Q: "Is a series of shell commands in an issue description reproduction code?"**
20
+
21
+
Instead of making a full-on reproduction committed to source control, it might be tempting to provide a bunch of shell commands instead. While a handful of shell commands is better than nothing, there's an extremely high chance that the person debugging won't be able to reproduce your issue. When this happens, they have to ask for clarification. This back-and-forth process takes lots of energy and wastes everyone's time. Instead, it's better to provide an executable reproduction from the beginning.
10
22
11
23
## How to make an example app
12
24
13
25
1. Start with a clean app with no other features.
14
26
2. Add whatever code is necessary to demonstrate the issue.
15
27
3. Add instructions to the README describing how to boot the app and reproduce the problem.
16
-
4. Push the example app somewhere public such as GitHub.
28
+
4. Push the example app somewhere public, such as GitHub.
17
29
5. Bonus: Give the app to a friend or co-worker. See if they can repro the problem without any instructions other than what's in the README.
18
30
6. Finally: Give a link to the example app to a maintainer (usually through an issue).
19
31
@@ -37,9 +49,7 @@ Better yet, send them a link to this page to help them understand why and how to
37
49
Please provide an [example app that can reproduce this issue](https://www.codetriage.com/example_app).
For additional tips on creating and responding to issues, check out the [How to Open Source](https://howtoopensource.dev/) book.
43
53
44
54
<%if !current_user%>
45
55
@@ -49,7 +59,6 @@ CodeTriage is the easiest way to get started contributing to open source.
49
59
50
60
Sign up, subscribe to repos you want to help, and we send you contribution ideas in your inbox. Easy Peazy. If you want to know more read <ahref="what">What is CodeTriage</a>.
51
61
52
-
53
62
<br/>
54
63
<center>
55
64
<%=link_to"Sign up via GitHub",user_github_omniauth_authorize_path,method: :post,class: 'button'%>
Copy file name to clipboardExpand all lines: app/views/university/index.md.erb
+10-1Lines changed: 10 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,16 @@ While CodeTriage helps by sending issues from repos, how do you pick the open-so
7
7
- **[Picking an open-source repo to help](university/picking_a_repo)**
8
8
- **[Triage with Me - 11 issues & 2 PRs in 1.5 hours](https://www.schneems.com/2020/09/22/triage-with-me-11-issues-2-prs-in-15-hours/)**
9
9
10
+
## The handbook
11
+
12
+
- [How to Open Source](https://howtoopensource.dev) is a paid book by Richard Schneeman sold under a creative commons license. It aims to teach developers actionable steps to grow from a coder into a contributor.
13
+
14
+
<divalign="center">
15
+
<ahref="https://howtoopensource.dev/">
16
+
<imgsrc="https://howtoopensource.dev/images/HowToOpenSource_FinalCover.jpg" style="width: 150px" alt="How to Open Source book cover" />
17
+
</a>
18
+
</div>
19
+
10
20
## I want to report a bug
11
21
12
22
When opening an issue about a bug, the number one thing anyone will want to know is: "how can I reproduce this problem." To help answer that question we've got some guides helping to explain what an excellent reproduction looks like and why:
@@ -20,4 +30,3 @@ When you make a PR (Pull Request), the maintainer might ask you to do some house
Copy file name to clipboardExpand all lines: app/views/university/reproduction_code.md.erb
+21-9Lines changed: 21 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -1,19 +1,26 @@
1
1
## Please Provide Reproduction Code
2
2
3
-
**What is Reproduction code?** A way to reliably trigger a bug or demonstrate bad behavior in a contained, easily executable package.
3
+
**Q: "What is Reproduction code?"**
4
4
5
-
**What isn't Reproduction code?** Repro code is not a step-by-step story of things you did to trigger the error, such as "I clicked this link" or "I entered this command" or "I compiled this code." While such descriptions can sometimes be helpful, they're often missing crucial contexts that might require guessing on the part of the person debugging. Chances are if your "reproduction" doesn't involve source control, it's not "reproduction code."
5
+
A way to reliably trigger a bug or demonstrate bad behavior in a contained, easily executable package.
6
6
7
-
**Why should I make a Reproduction?** Before someone can fix a bug, they need to understand why it happens. While descriptions can help, the golden standard for debugging code is to be able to reproduce the bug. The easier it is to reproduce the bug, the shorter the debugging cycles will take, and the faster it can be fixed.
7
+
A specialized case of "reproduction code" is an [example app](https://www.codetriage.com/example_app) if you're the open-source library is a framework for application development.
8
8
9
-
- An example could be: Creating a new "clean" repository on GitHub that includes all code, declares dependencies, and instructions necessary to see the behavior.
10
-
- An example could be: Adding a failing test added to the repo
9
+
**Q: "What isn't Reproduction code?"**
11
10
12
-
A specialized case of "reproduction code" is an [example app](https://www.codetriage.com/example_app) if you're the open-source library is a framework for application development.
11
+
Repro code is not a step-by-step story of things you did to trigger the error, such as "I clicked this link" or "I entered this command" or "I compiled this code." While such descriptions can sometimes be helpful, they're often missing crucial contexts that might require guessing on the part of the person debugging. Chances are if your "reproduction" doesn't involve source control, it's not "reproduction code."
12
+
13
+
**Q: "Why should I make a Reproduction?"**
14
+
15
+
Before someone can fix a bug, they need to understand why it happens. While descriptions can help, the golden standard for debugging code is to be able to reproduce the bug. The easier it is to reproduce the bug, the shorter the debugging cycles will take, and the faster it can be fixed.
16
+
17
+
**Q: "Does that mean I should send my whole application over when I open a bug report?"**
13
18
14
-
**Does that mean I should send my whole application over when I open a bug report?** Please no. Reproduction code is best when there's a minimal amount of code necessary to reproduce the issue. The more extra stuff there is, the harder it may be to separate what's causing the bug versus what's just there.
19
+
Please no. Reproduction code is best when there's a minimal amount of code necessary to reproduce the issue. The more extra stuff there is, the harder it may be to separate what's causing the bug versus what's just there.
15
20
16
-
**Is a series of shell commands in an issue description reproduction code?** Instead of making a full-on reproduction committed to source control, it might be tempting to provide a bunch of shell commands instead. While a handful of shell commands is better than nothing, there's an extremely high chance that the person debugging won't be able to reproduce your issue. When this happens, they have to ask for clarification. This back-and-forth process takes lots of energy and wastes everyone's time. Instead, it's better to provide an executable reproduction from the beginning.
21
+
**Q: "Is a series of shell commands in an issue description reproduction code?"**
22
+
23
+
Instead of making a full-on reproduction committed to source control, it might be tempting to provide a bunch of shell commands instead. While a handful of shell commands is better than nothing, there's an extremely high chance that the person debugging won't be able to reproduce your issue. When this happens, they have to ask for clarification. This back-and-forth process takes lots of energy and wastes everyone's time. Instead, it's better to provide an executable reproduction from the beginning.
17
24
18
25
## How to make reproduction code
19
26
@@ -40,6 +47,12 @@ If you see an open bug report that does not have a working reproduction ask them
40
47
41
48
Better yet, send them a link to this page to help them understand why and how to make one!
42
49
50
+
<textarea>
51
+
Please provide a [working reproduction](https://www.codetriage.com/reproduction).
52
+
</textarea>
53
+
54
+
For additional tips on creating and responding to issues, check out the [How to Open Source](https://howtoopensource.dev) book.
55
+
43
56
<%if !current_user%>
44
57
45
58
## What is CodeTriage?
@@ -48,7 +61,6 @@ CodeTriage is the easiest way to get started contributing to open source.
48
61
49
62
Sign up, subscribe to repos you want to help, and we send you contribution ideas in your inbox. Easy Peazy. If you want to know more read <ahref="what">What is CodeTriage</a>.
50
63
51
-
52
64
<br/>
53
65
<center>
54
66
<%=link_to"Sign up via GitHub",user_github_omniauth_authorize_path,method: :post,class: 'button'%>
0 commit comments