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: CONTRIBUTING.md
+14-20Lines changed: 14 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,16 @@
1
1
# Contributing
2
2
3
-
Look who wants to contribute! Nice to see you here, let me show you what you can do :)
3
+
## Users cannot create GitHub Issues directly
4
+
5
+
Unfortunately, AeroSpace project doesn't accept bug reports and feature requests from everyone.
6
+
7
+
The submitted Issues are often either obvious duplicates, environmental problems, or configuration errors by the users themselves.
8
+
For a hobby project, I don't have enough time and energy to process every such submitted Issue.
9
+
10
+
**As an alternative, you can start a Discussion on GitHub discussions forum**https://github.com/nikitabobko/AeroSpace/discussions.
11
+
Any Discussion which clearly identifies a problem and can be confirmed or reproduced will be converted to an Issue by maintainers.
12
+
13
+
Thank you for your understanding.
4
14
5
15
## Submit bugs and feature ideas
6
16
@@ -30,30 +40,14 @@ Rules:
30
40
* Synopsis, if you suggest a new command
31
41
* Mental model description
32
42
33
-
## Users cannot create GitHub Issues directly
34
-
35
-
Users are not allowed to create Issues directly in this repository - we ask that you create a Discussion first.
36
-
37
-
Users can't create issues directly because:
38
-
- Users submit too many duplicates without prior search
39
-
- A lot of user issues are misunderstandings, environmental problems, or configuration errors by the users themselves
40
-
- Few people can formulate proper bug reports
41
-
- Even fewer people can formulate proper, actionable feature requests that align with other existing/planned features and the overall AeroSpace mental model
42
-
43
-
Any Discussion which clearly identifies a problem and can be confirmed or reproduced will be converted to an Issue by maintainers.
44
-
45
-
This whole pattern makes it easier for maintainers or contributors to find issues to work on.
46
-
Issues are like a publicly observable maintainers' inbox.
47
-
We want to keep this inbox tidy and clean.
48
-
49
43
## Discuss issues/discussions
50
44
51
45
One of the most useful thing you can do is to discuss issues/discussions.
52
46
53
47
Imagine that you were assigned to fix the issue.
54
48
Try to suggest the best approach and design on how to fix the issue.
55
49
Suggest the synopsis/config format, reason in written form what is good about it, what is bad about it, what are the alternatives, etc.
56
-
Basically, see the "Prior discussion" section in [Submit Pull Requests](#submit-pull-requests) :)
50
+
Basically, see the "Prior discussion" section in [Submit Pull Requests](#submit-pull-requests).
57
51
58
52
If you have something to contribute to the conversation. Do it!
59
53
@@ -67,6 +61,8 @@ You can take a look at the following issues:
67
61
68
62
## Submit Pull Requests
69
63
64
+
Small and trivial improvements can be submitted without any discussion.
65
+
70
66
**Prior discussion**. For non-trivial changes (such as user visible changes), it's always better to ask for prior approval and discuss what you want to do before doing it.
71
67
72
68
Please create a new discussion and describe you want to do.
@@ -83,8 +79,6 @@ Consider including
83
79
84
80
Discussing that you want to do something doesn't put any obligations on you. If you don't want to start the discussion just because you're afraid that you won't do it. Don't be afraid!
85
81
86
-
Small and trivial improvements can be submitted without any discussion.
87
-
88
82
**Commit hygiene**. Each submitted commit must be atomic change (a Pull Request may contain several commits). Don't introduce new functional changes together with refactorings in the same commit.
89
83
90
84
Similarly, when implementing features and bug fixes, please stick to the structure of the codebase as much as possible and do not take this as an opportunity to do some "refactoring along the way".
0 commit comments