- Use the pandas contributing document as a guide.
- Define versioning logic
- Implement release plans with group of features to add before version number updated
- Explain how to set up dev environment
Early contributing guidance:
-
I'm using http://semver.org/ and this stack overflow post as a model for versioning; I'm using four schemed number (0.0.0.0):
- major version (changes when all planned features are added)
- minor version (changes when new classes or modules are added that change the results or analysis on GDELT data returned)
- minor-minor version (changes with smaller enhancements like classes or modules that just return unaltered data, new parameters to existing classes/modules, etc.)
- Bug fixes - Last number is the bug fix count for current build; no changes to existing functionality but fixes a MAJOR bug that stops the entire module for working. Simple little bug fixes don't get counted. Resets to zero on minor-minor change. Only counts bugs so if no bugs...stays at zero. Eventually will drop this number off when the unit test suite has 80% coverage.
-
Small one or two-line entry in CHANGES (gdeltPyR --> CHANGES). Just a date line and description that says something like "added support to translated GDELT data" you can add your github username if you want too.
-
Add short bullet to README.md and README.rst. (gdeltPyR --> README.md (rst)). This just announces the new feature on the first page.
This looks good. Thanks for adding the unittests.
Administrative changes before any merge.
-
Small one or two-line entry in CHANGES explaining what you did (gdeltPyR --> CHANGES). Just a date line and description that says something like "Added support to translated GDELT data" you can add your github username if you want too.
-
Add short bullet to README.md and README.rst. (gdeltPyR --> README.md (rst)). This just announces the new feature on the first page.
-
Add issue that defines what bug or feature you plan to do. Reference the issue in commits and close it if you commit addresses the issue whether it's an enhancement, bug fix, or documentation update, etc.
-
(Optional) ** Add your name or github user name (or combo) to the AUTHORS.rst** (gdeltPyR --> AUTHORS.rst). Keep track of all contributors to show power of open source. Feel free to add your country as well.
Early contributing guidance:
I'm using http://semver.org/ and this stack overflow post as a model for versioning; I'm using four schemed number (0.0.0.0):
Small one or two-line entry in CHANGES (gdeltPyR --> CHANGES). Just a date line and description that says something like "added support to translated GDELT data" you can add your github username if you want too.
Add short bullet to README.md and README.rst. (gdeltPyR --> README.md (rst)). This just announces the new feature on the first page.
This looks good. Thanks for adding the unittests.
Administrative changes before any merge.
Small one or two-line entry in CHANGES explaining what you did (gdeltPyR --> CHANGES). Just a date line and description that says something like "Added support to translated GDELT data" you can add your github username if you want too.
Add short bullet to README.md and README.rst. (gdeltPyR --> README.md (rst)). This just announces the new feature on the first page.
Add issue that defines what bug or feature you plan to do. Reference the issue in commits and close it if you commit addresses the issue whether it's an enhancement, bug fix, or documentation update, etc.
(Optional) ** Add your name or github user name (or combo) to the AUTHORS.rst** (gdeltPyR --> AUTHORS.rst). Keep track of all contributors to show power of open source. Feel free to add your country as well.