Skip to content

Commit a98c179

Browse files
JordanMartinezJordanMartinez
committed
Create templates for GitHub PRs, issues; update CONTRIBUTING
1 parent 91895c3 commit a98c179

4 files changed

Lines changed: 137 additions & 21 deletions

File tree

‎.github/CONTRIBUTING.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
## List of Maintainers
2+
3+
- [TomasMikula](https://github.com/TomasMikula) - original contributor, currently inactive
4+
- [JordanMartinez](https://github.com/JordanMartinez) - later contributor, sometimes active
5+
- [afester](https://github.com/afester) - later contributor, sometimes active

‎.github/ISSUE_TEMPLATE.md‎

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
## Read these guidelines first, write your issue, and only then submit it.
2+
3+
Click the "Preview" tab to read this issue template in a clearer way.
4+
5+
Determine what kind of issue this is (bug report, feature request, or a question) and follow the corresponding guidelines below
6+
7+
### Guidelines For Bug Reports
8+
9+
- Check whether this issue has already been reported
10+
- Use the first set of headers to structure what you write (`expected behavior`, `actual behavior`, `reproducible demo`, and `environment info`) and delete the other parts of this issue template
11+
- Use a clear title that summarizes the problem
12+
13+
### Guidelines For Feature Requests
14+
15+
- Use a clear title that starts with words like "Add", "Support", etc.
16+
- Use the second set of headers to structure what you write (`Desired Feature`, `Current Workaroudns`, and `Implementation Costs`) and delete the other parts of this issue template (e.g. question & feature request guidelines)
17+
18+
### Guidelines For Questions
19+
20+
- Explain whether this is a question about the API, best practices, feedback on some approach to solving a problem, etc.
21+
- Use a clear title that either starts with "Question" or ends with a "?" to signify that this is a question.
22+
- Example: "Question: syntax highlighting best practices"
23+
- Example: "What is the best way to do syntax highlighting?"
24+
- If asking for feedback on some approach to solving a problem, explain your goal and your constraints in reaching that goal before explaining what you are trying to do to solve that problem
25+
- Once the above has been done, delete the rest of this issue template and feel free to structure your issue in whatever way works best for you.
26+
27+
<hr>
28+
29+
## Expected Behavior
30+
31+
Describe what should be occurring when you use some method or the end-user does some behavior
32+
33+
## Actual Behavior
34+
35+
Describe what actually occurs when you use some method or the end-user does some behavior
36+
37+
## Reproducible Demo
38+
39+
Provide a demo that maintainers of this project can copy, paste, and run to reproduce it immediately.
40+
41+
Use the following template to get started.
42+
````java
43+
public class Bug extends Application {
44+
45+
public void start(Stage primaryStage) {
46+
47+
primaryStage.show();
48+
}
49+
50+
}
51+
````
52+
53+
## Environment info:
54+
55+
- RichTextFX Version: \<version\>
56+
- Operating System: \<my OS\>
57+
- Java version: \<version\>
58+
59+
<hr>
60+
61+
## Desired Feature
62+
63+
Explain what you want RichTextFX or some component within it to be able to do and why
64+
65+
## Current Workarounds
66+
67+
Explain whether the feature can be done right now or not. If it can, how much one would need to hack at the code to produce the desired result? Is such a hack inconvenient but possible, difficult and troublesome, or impossible in the current version?
68+
69+
## Implementation Costs
70+
71+
To the best of your knowledge...
72+
73+
- What would need to be changed to support the feature (e.g. accessibility changes, type refactoring, splitting up a method into multiple methods, etc.)?
74+
- What problems or issues would need to be resolved first (if any)?
75+
- What problems might this feature create (e.g. compatibility issues, inconvenience upon some developers, etc.)

‎.github/PULL_REQUEST_TEMPLATE.md‎

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
## Guidelines for Pull Requests
2+
3+
### General Guidelines
4+
- You are either submitting a pull request to the RichTextFX project or submitting a new demo for its demo package. See the corresponding guidelines.
5+
- State which issue this fixes/addresses/resolves (e.g. "Fixes #0" or "Resolves #0"). If such an issue doesn't exist yet, open a new issue first.
6+
- Each PR should resolve only one issue. Do not fix multiple things in a single request; rather open multiple requests that each fix one issue.
7+
- State any concerns you have with your current approach, any requests for comments or feedback on specific points, etc.
8+
9+
## Guidelines for contributing to RichTextFX
10+
11+
### Documentation Guidelines
12+
The following expectations must be met before a PR will be merged:
13+
14+
- Do not document self-explanatory things unless one must be aware of some issues that may arise with using it incorrectly.
15+
- Do not document getters and setters. We know what they do.
16+
- `moveCaretToFirstLine()` explains what it does. However, if it has a side-effect of scrolling the viewport, then it should be documented
17+
- Document private classes/methods if it would take us more than 2 minutes to understand the code 6 months after it was merged.
18+
- Document all non-self-explanatory public classes:
19+
- Why does the class exist?
20+
- What other classes relate to it and its usage?
21+
- Document all non-self-explanatory public methods:
22+
- What does it do?
23+
- What side effects does it have (if any)?
24+
- What is one example of its usage?
25+
26+
### Testing Guidelines
27+
Each PR that changes the code may need to include tests (if they aren't already covered) to insure that such changes do not affect the stability of the project. The following expectations must be met before a PR will be merged:
28+
29+
- Things that should go in the `src/test` package
30+
- tests which do not require starting or running on the JavaFX Application Thread
31+
- unit tests (e.g. tests on model-related classes/API)
32+
- Things that should go in the `src/integrationTest` package
33+
- tests which require starting and running on the JavaFX Application Thread
34+
- integration tests
35+
- behavior tests
36+
- API tests
37+
- Test Structure
38+
- Use nested classes to reduce code duplication (see the integrationTest package's tests as an example)
39+
- method names should be snake case (e.g. `moving_caret_to_first_line_works()`)
40+
- test one feature/API per test method
41+
42+
43+
## Guidelines for contributing to RichTextFX's demo package
44+
45+
- Modulate the code:
46+
- Start creating a single class that extends `Application`.
47+
- Name the class something related to the thing it illustrates and ends the name with "Demo" (e.g. `XMLHighlightingDemo`)
48+
- Put all of the demo code into `Application#start`
49+
- If the required code cannot fit into `Application#start` method or should be broken up, create helper methods with clear names (e.g. `computeHighlighting()`) in the demo class
50+
- Do not use nested classes: put support classes into their own separate files
51+
- If the demo is a single class, put it in topmost package (e.g. `org.fxmisc.richtext.demo`)
52+
- If the demo requires multiple classes,
53+
- Put the demo and its classes into their own appropriately-named package (e.g. `org.fxmisc.richtext.demo.mydemo`).
54+
- Write a brief class-level javadoc on each class that explains what it does
55+
56+
57+

‎CONTRIBUTING.md‎

Lines changed: 0 additions & 21 deletions
This file was deleted.

0 commit comments

Comments
 (0)
⚡