|
1 | | -.. highlight:: shell |
2 | | - |
3 | 1 | ============ |
4 | 2 | Contributing |
5 | 3 | ============ |
6 | 4 |
|
7 | | -Contributions are welcome, and they are greatly appreciated! Every little bit |
8 | | -helps, and credit will always be given. |
9 | | - |
10 | | -You can contribute in many ways: |
11 | | - |
12 | | -Types of Contributions |
13 | | ----------------------- |
14 | | - |
15 | | -Report Bugs |
16 | | -~~~~~~~~~~~ |
17 | | - |
18 | | -Report bugs at the `GitHub Issues page`_. |
19 | | - |
20 | | -If you are reporting a bug, please include: |
21 | | - |
22 | | -* Your operating system name and version. |
23 | | -* Any details about your local setup that might be helpful in troubleshooting. |
24 | | -* Detailed steps to reproduce the bug. |
25 | | - |
26 | | -Fix Bugs |
27 | | -~~~~~~~~ |
28 | | - |
29 | | -Look through the GitHub issues for bugs. Anything tagged with "bug" and "help |
30 | | -wanted" is open to whoever wants to implement it. |
31 | | - |
32 | | -Implement Features |
33 | | -~~~~~~~~~~~~~~~~~~ |
34 | | - |
35 | | -Look through the GitHub issues for features. Anything tagged with "enhancement" |
36 | | -and "help wanted" is open to whoever wants to implement it. |
37 | | - |
38 | | -Write Documentation |
39 | | -~~~~~~~~~~~~~~~~~~~ |
40 | | - |
41 | | -CTGAN could always use more documentation, whether as part of the |
42 | | -official CTGAN docs, in docstrings, or even on the web in blog posts, |
43 | | -articles, and such. |
44 | | - |
45 | | -Submit Feedback |
46 | | -~~~~~~~~~~~~~~~ |
47 | | - |
48 | | -The best way to send feedback is to file an issue at the `GitHub Issues page`_. |
49 | | - |
50 | | -If you are proposing a feature: |
51 | | - |
52 | | -* Explain in detail how it would work. |
53 | | -* Keep the scope as narrow as possible, to make it easier to implement. |
54 | | -* Remember that this is a volunteer-driven project, and that contributions |
55 | | - are welcome :) |
56 | | - |
57 | | -Get Started! |
58 | | ------------- |
59 | | - |
60 | | -Ready to contribute? Here's how to set up `CTGAN` for local development. |
61 | | - |
62 | | -1. Fork the `CTGAN` repo on GitHub. |
63 | | -2. Clone your fork locally:: |
64 | | - |
65 | | - $ git clone [email protected]:your_name_here/CTGAN.git |
66 | | - |
67 | | -3. Install your local copy into a virtualenv. Assuming you have virtualenvwrapper installed, |
68 | | - this is how you set up your fork for local development:: |
69 | | - |
70 | | - $ mkvirtualenv CTGAN |
71 | | - $ cd CTGAN/ |
72 | | - $ make install-develop |
73 | | - |
74 | | -4. Create a branch for local development:: |
75 | | - |
76 | | - $ git checkout -b name-of-your-bugfix-or-feature |
77 | | - |
78 | | - Try to use the naming scheme of prefixing your branch with ``gh-X`` where X is |
79 | | - the associated issue, such as ``gh-3-fix-foo-bug``. And if you are not |
80 | | - developing on your own fork, further prefix the branch with your GitHub |
81 | | - username, like ``githubusername/gh-3-fix-foo-bug``. |
82 | | - |
83 | | - Now you can make your changes locally. |
84 | | - |
85 | | -5. While hacking your changes, make sure to cover all your developments with the required |
86 | | - unit tests, and that none of the old tests fail as a consequence of your changes. |
87 | | - For this, make sure to run the tests suite and check the code coverage:: |
88 | | - |
89 | | - $ make lint # Check code styling |
90 | | - $ make test # Run the tests |
91 | | - $ make coverage # Get the coverage report |
92 | | - |
93 | | -6. When you're done making changes, check that your changes pass all the styling checks and |
94 | | - tests, including other Python supported versions, using:: |
95 | | - |
96 | | - $ make test-all |
97 | | - |
98 | | -7. Make also sure to include the necessary documentation in the code as docstrings following |
99 | | - the `Google docstrings style`_. |
100 | | - If you want to view how your documentation will look like when it is published, you can |
101 | | - generate and view the docs with this command:: |
102 | | - |
103 | | - $ make view-docs |
104 | | - |
105 | | -8. Commit your changes and push your branch to GitHub:: |
106 | | - |
107 | | - $ git add . |
108 | | - $ git commit -m "Your detailed description of your changes." |
109 | | - $ git push origin name-of-your-bugfix-or-feature |
110 | | - |
111 | | -9. Submit a pull request through the GitHub website. |
112 | | - |
113 | | -Pull Request Guidelines |
114 | | ------------------------ |
115 | | - |
116 | | -Before you submit a pull request, check that it meets these guidelines: |
117 | | - |
118 | | -1. It resolves an open GitHub Issue and contains its reference in the title or |
119 | | - the comment. If there is no associated issue, feel free to create one. |
120 | | -2. Whenever possible, it resolves only **one** issue. If your PR resolves more than |
121 | | - one issue, try to split it in more than one pull request. |
122 | | -3. The pull request should include unit tests that cover all the changed code |
123 | | -4. If the pull request adds functionality, the docs should be updated. Put |
124 | | - your new functionality into a function with a docstring, and add the |
125 | | - feature to the documentation in an appropriate place. |
126 | | -5. The pull request should work for all the supported Python versions. Check the `Travis Build |
127 | | - Status page`_ and make sure that all the checks pass. |
128 | | - |
129 | | -Unit Testing Guidelines |
130 | | ------------------------ |
131 | | - |
132 | | -All the Unit Tests should comply with the following requirements: |
133 | | - |
134 | | -1. Unit Tests should be based only in unittest and pytest modules. |
135 | | - |
136 | | -2. The tests that cover a module called ``ctgan/path/to/a_module.py`` |
137 | | - should be implemented in a separated module called |
138 | | - ``tests/ctgan/path/to/test_a_module.py``. |
139 | | - Note that the module name has the ``test_`` prefix and is located in a path similar |
140 | | - to the one of the tested module, just inside the ``tests`` folder. |
141 | | - |
142 | | -3. Each method of the tested module should have at least one associated test method, and |
143 | | - each test method should cover only **one** use case or scenario. |
144 | | - |
145 | | -4. Test case methods should start with the ``test_`` prefix and have descriptive names |
146 | | - that indicate which scenario they cover. |
147 | | - Names such as ``test_some_methed_input_none``, ``test_some_method_value_error`` or |
148 | | - ``test_some_method_timeout`` are right, but names like ``test_some_method_1``, |
149 | | - ``some_method`` or ``test_error`` are not. |
150 | | - |
151 | | -5. Each test should validate only what the code of the method being tested does, and not |
152 | | - cover the behavior of any third party package or tool being used, which is assumed to |
153 | | - work properly as far as it is being passed the right values. |
154 | | - |
155 | | -6. Any third party tool that may have any kind of random behavior, such as some Machine |
156 | | - Learning models, databases or Web APIs, will be mocked using the ``mock`` library, and |
157 | | - the only thing that will be tested is that our code passes the right values to them. |
158 | | - |
159 | | -7. Unit tests should not use anything from outside the test and the code being tested. This |
160 | | - includes not reading or writing to any file system or database, which will be properly |
161 | | - mocked. |
162 | | - |
163 | | -Tips |
164 | | ----- |
165 | | - |
166 | | -To run a subset of tests:: |
167 | | - |
168 | | - $ python -m pytest tests.test_ctgan |
169 | | - $ python -m pytest -k 'foo' |
170 | | - |
171 | | -Release Workflow |
172 | | ----------------- |
173 | | - |
174 | | -The process of releasing a new version involves several steps combining both ``git`` and |
175 | | -``bumpversion`` which, briefly: |
176 | | - |
177 | | -1. Merge what is in ``main`` branch into ``stable`` branch. |
178 | | -2. Update the version in ``setup.cfg``, ``ctgan/__init__.py`` and |
179 | | - ``HISTORY.md`` files. |
180 | | -3. Create a new git tag pointing at the corresponding commit in ``stable`` branch. |
181 | | -4. Merge the new commit from ``stable`` into ``main``. |
182 | | -5. Update the version in ``setup.cfg`` and ``ctgan/__init__.py`` |
183 | | - to open the next development iteration. |
184 | | - |
185 | | -.. note:: Before starting the process, make sure that ``HISTORY.md`` has been updated with a new |
186 | | - entry that explains the changes that will be included in the new version. |
187 | | - Normally this is just a list of the Pull Requests that have been merged to main |
188 | | - since the last release. |
189 | | - |
190 | | -Once this is done, run of the following commands: |
191 | | - |
192 | | -1. If you are releasing a patch version:: |
193 | | - |
194 | | - make release |
195 | | - |
196 | | -2. If you are releasing a minor version:: |
197 | | - |
198 | | - make release-minor |
199 | | - |
200 | | -3. If you are releasing a major version:: |
201 | | - |
202 | | - make release-major |
203 | | - |
204 | | -Release Candidates |
205 | | -~~~~~~~~~~~~~~~~~~ |
206 | | - |
207 | | -Sometimes it is necessary or convenient to upload a release candidate to PyPi as a pre-release, |
208 | | -in order to make some of the new features available for testing on other projects before they |
209 | | -are included in an actual full-blown release. |
210 | | - |
211 | | -In order to perform such an action, you can execute:: |
212 | | - |
213 | | - make release-candidate |
214 | | - |
215 | | -This will perform the following actions: |
216 | | - |
217 | | -1. Build and upload the current version to PyPi as a pre-release, with the format ``X.Y.Z.devN`` |
218 | | - |
219 | | -2. Bump the current version to the next release candidate, ``X.Y.Z.dev(N+1)`` |
220 | | - |
221 | | -After this is done, the new pre-release can be installed by including the ``dev`` section in the |
222 | | -dependency specification, either in ``pyproject.toml``:: |
223 | | - |
224 | | - dependencies = [ |
225 | | - ... |
226 | | - 'ctgan>=X.Y.Z.dev', |
227 | | - ... |
228 | | - ] |
| 5 | +We love our community’s interest in the SDV ecosystem. The SDV software |
| 6 | +(and its related libraries) is owned and maintained by DataCebo, Inc. |
| 7 | +It is available under the `Business Source License`_ for you to browse. |
229 | 8 |
|
230 | | -or in command line:: |
| 9 | +We support a large set of users with enterprise-specific intricacies and |
| 10 | +reliability needs. This has required us to be deliberate about setting |
| 11 | +the roadmap for SDV libraries. As a result, we are unable to prioritize |
| 12 | +reviewing and accepting external pull requests. As a policy, we will |
| 13 | +not be able to accept external contributions. |
231 | 14 |
|
232 | | - pip install 'ctgan>=X.Y.Z.dev' |
| 15 | +**Would you like a bug or feature request to be addressed?** If you haven't |
| 16 | +already, we would greatly appreciate it if you could `file an issue`_ |
| 17 | +instead with the overall description of your problem. We can determine |
| 18 | +whether it’s aligned with our framework. Once discussed, our team |
| 19 | +typically resolves smaller issues within a few release cycles. |
| 20 | +We appreciate your understanding. |
233 | 21 |
|
234 | 22 |
|
235 | | -.. _GitHub issues page: https://github.com/sdv-dev/CTGAN/issues |
236 | | -.. _Travis Build Status page: https://travis-ci.org/sdv-dev/CTGAN/pull_requests |
237 | | -.. _Google docstrings style: https://google.github.io/styleguide/pyguide.html?showone=Comments#Comments |
| 23 | +.. _Business Source License: https://github.com/sdv-dev/CTGAN/blob/main/LICENSE |
| 24 | +.. _file an issue: https://github.com/sdv-dev/CTGAN/issues |
0 commit comments