1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
Contributing
============
Overview
--------
- Make your changes.
- Update `NEWS.md.in`.
- Update `.mailmap` if necessary.
- Write a test covering your feature or fix.
- Ensure existing and new tests are passing.
- Submit a pull request on GitHub.
Explanation
-----------
Consider updating `NEWS.md.in`. The topmost section is for the upcoming
release. Bugfixes should be marked with `BUGFIX`. Small things (typos,
code style) should be grouped but with multiple authors (`Documentation
updates thanks to Dan Croak and Roberto Pedroso`).
We use your name and email address as produced by `git-shortlog(1)`. You
can change how this is formatted by modifying `.mailmap`. More details
on that file can be found in the git [Documentation/mailmap.txt][mailmap].
It is mandatory to include tests with pull requests. You must ensure that the
existing test suite passes with any changes you make. Also, any attempts to add
or extend tests will increase the chances of your pull request being merged.
Submit a pull request using GitHub. If there is a relevant bug, mention
it in the commit message (`Fixes #42.`). We love pull requests from everyone.
By participating in this project, you agree to abide by the thoughtbot
[code of conduct].
[mailmap]: https://github.com/git/git/blob/master/Documentation/mailmap.txt
[code of conduct]: https://thoughtbot.com/open-source-code-of-conduct
Setup
-----
1. Fork the repo.
2. Install dependencies
- Cram is used for tests: `pip install cram`
- The mustache gem for building the HTML pages: `gem install mustache`
3. Prepare the build system: `./autogen.sh`. (This depends on GNU
autoconf and GNU automake.)
4. Configure the package: `./configure`.
5. Make sure the tests pass: `make check`.
6. Start hacking
Testing
-------
The test suite uses [cram][]. It is an integration suite, meaning the
programs are exercised from the outside and assertions are made only on
their output or effects.
The test suite requires Perl with the `Cwd` module. It expects to find Perl as
`perl` in `$PATH`.
All tests can be run like so:
$ make check
Individual tests can be run like so:
$ env TESTS=test/lsrc-dotfiles-dirs.t make -e check
If you intend to write a new test:
1. Add your test at `test/subcommand-something-meaningful.t`.
2. Add the relative name to the `TESTS` variable in `Makefile.am`.
3. Source `test/helper.sh` as the first line of your test.
4. When in doubt, use existing tests as a guide.
[cram]: https://bitheap.org/cram/
Governance
==========
Your interaction with this project can be divided into three sections: you as a
contributor, you as a committer, and how to become a committer.
Commenter and meta-contributor
------------------------------
Those commenting and triaging issues and pull reports are expected to adhere to
our [code of conduct].
Contributor
-----------
This is a slow-moving project. The maintainers' goal is to provide a yearly
release.
As a contributor, you can expect a maintainer to add a GitHub label to your
pull request or issue within two weeks. This indicates that a maintainer has
seen your contribution and quickly triaged it. If a maintainer believe that
your feature request will not be merged, they will tell you as much during the
triage step.
Bug reports, either as issues or as pull requests, get the maintainers'
priority. The maintainers consider documentation bugs to be as important as
code bugs.
Feature contributions (that is, a pull request that add a new feature) get
lower priority. A maintainer will evaluate the patch carefully for
maintainability and to ensure the test coverage is high.
Feature requests without a patch will be closed. A maintainer will try to
provide a description of how to write your patch while we close the request,
though they cannot guarantee this.
Interactions outside of GitHub Issues and Pull Requests are not considered
contributing. For example, tweeting about a bug in rcm is not contributing to
rcm, and therefore we can make no guarantees or promises about such an action.
You are expected to adhere to our [code of conduct].
Committer
---------
As a committer, you can merge at any time. The maintainers encourage you to
have the code reviewed by someone beforehand. Those in the thoughtbot team can
ping the `@thoughtbot/shell` group.
You are expected to adhere to our [code of conduct].
Maintainer
----------
A maintainer acts as a project manager and, as such, has final say and
responsibility.
All maintainers must adhere to our [code of conduct].
Promotion
---------
All current thoughtbot employees are committers to rcm.
Contributors with two merged patches are welcome to request committer access by
emailing support@thoughtbot.com.
Existing contributors become a maintainer by taking on more work and
responsibility.
|
