Merge pull request #2155 from ttmc/clarify-contributing-docs
Problem: Docs re contributing needed editing & reorg
This commit is contained in:
Troy McConaghy
GitHub
commit
3f2d40f670
|
|
@ -2,6 +2,6 @@
|
|||
|
||||
There are many ways you can contribute to the BigchainDB project, some very easy and others more involved.
|
||||
|
||||
All of that is documented elsewhere: go to the "[Contributing to BigchainDB" docs on ReadTheDocs](https://docs.bigchaindb.com/en/latest/). Note: that link goes to the root docs, but you can click from there to get to the "Contributing to BigchainDB" docs, once they get published on ReadTheDocs.
|
||||
All of that is documented elsewhere: go to the "[Contributing to BigchainDB" docs on ReadTheDocs](https://docs.bigchaindb.com/projects/contributing/en/latest/index.html).
|
||||
|
||||
Note: GitHub automatically links to this file (`.github/CONTRIBUTING.md`) when a contributor creates a new issue or pull request, so you shouldn't delete it. Just use it to point people to full and proper help elsewhere.
|
||||
|
|
|
|||
|
|
@ -1,20 +1,19 @@
|
|||
You can create a new issue but it must be a proper and complete bug report. Nothing else is a valid issue. See the "Issue Rules" in the docs about "Contributing to BigchainDB". A link is coming soon. For now, go to:
|
||||
# Do you want to:
|
||||
|
||||
https://docs.bigchaindb.com/en/latest/
|
||||
- make a bug report? Then read below about what should go in a bug report.
|
||||
- make a feature request or proposal? Then read [the page about how to make a feature request or proposal](https://docs.bigchaindb.com/projects/contributing/en/latest/ways-can-contribute/make-a-feature-request-or-proposal.html).
|
||||
- ask a question about BigchainDB? Then [go to Gitter](https://gitter.im/bigchaindb/bigchaindb) (our chat room) and ask it there.
|
||||
- share your neat idea or realization? Then [go to Gitter](https://gitter.im/bigchaindb/bigchaindb) (our chat room) and share it there.
|
||||
|
||||
and follow the links from there.
|
||||
# What Should Go in a Bug Report
|
||||
|
||||
Describe everything in detail:
|
||||
|
||||
+ What computer are you on (hardware)?
|
||||
+ What operating system are you using, including version. e.g. Ubuntu 14.04? Fedora 23? If it's not a Linux distro, then that's probably the problem.
|
||||
+ What version of BigchainDB software were you using? Did you update it to the latest?
|
||||
+ What, exactly, did you do to get to the point where you got stuck? Describe all the steps so we can get there too.
|
||||
+ Show screenshots or copy-and-paste text to GitHub
|
||||
+ Say what you expected to happen
|
||||
+ Show what actually happened
|
||||
+ Say what you tried to do to resolve the problem
|
||||
+ Provide details to convince us that it matters to you. Is it for a school project, a job, a contract with a deadline, a child who needs it for Christmas?
|
||||
- What computer are you on (hardware)?
|
||||
- What operating system are you using, including version. e.g. Ubuntu 14.04? Fedora 23?
|
||||
- What version of BigchainDB software were you using? Is that the latest version?
|
||||
- What, exactly, did you do to get to the point where you got stuck? Describe all the steps so we can get there too. Show screenshots or copy-and-paste text to GitHub.
|
||||
- Show what actually happened.
|
||||
- Say what you tried to do to resolve the problem.
|
||||
- Provide details to convince us that it matters to you. Is it for a school project, a job, a contract with a deadline, a child who needs it for Christmas?
|
||||
|
||||
We will do our best but please understand that we don't have time to help everyone, especially people who don't care to help us help them. "It doesn't work." is not going to get any reaction from us. We need _details_.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,18 @@
|
|||
There are very few valid reasons to create a pull request. To learn what they are (e.g. a BEP, or a short & specific solution to a well-defined problem), and how to structure the pull request, see the BigchainDB docs about "Contributing to BigchainDB". A link is coming soon. For now, go to:
|
||||
Make sure the title of this pull request has the form:
|
||||
|
||||
https://docs.bigchaindb.com/en/latest/
|
||||
**Problem: A short statement of the problem.**
|
||||
|
||||
and follow the links from there.
|
||||
## Solution
|
||||
|
||||
A short statement about how this PR solves the **Problem**.
|
||||
|
||||
## Issues Resolved
|
||||
|
||||
What issues does this PR resolve, if any? Please include lines like the following (i.e. "Resolves #NNNN), so that when this PR gets merged, GitHub will automatically close those issues.
|
||||
|
||||
Resolves #NNNN
|
||||
Resolves #MMMM
|
||||
|
||||
## BEPs Implemented
|
||||
|
||||
What [BEPs](https://github.com/bigchaindb/beps) does this pull request implement, if any?
|
||||
|
|
|
|||
|
|
@ -92,3 +92,6 @@ terraform.tfstate.backup
|
|||
# tendermint data
|
||||
tmdata/data
|
||||
network/*/data
|
||||
|
||||
# Docs that are fetched at build time
|
||||
docs/contributing/source/cross-project-policies/*.md
|
||||
|
|
|
|||
|
|
@ -1,50 +0,0 @@
|
|||
# Contributor Code of Conduct
|
||||
|
||||
As contributors and maintainers of this project, and in the interest of
|
||||
fostering an open and welcoming community, we pledge to respect all people who
|
||||
contribute to the project.
|
||||
|
||||
We are committed to making participation in this project a harassment-free
|
||||
experience for everyone, regardless of level of experience, gender, gender
|
||||
identity and expression, sexual orientation, disability, personal appearance,
|
||||
body size, race, ethnicity, age, religion, nationality, or species--no picking on Wrigley for being a buffalo!
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
* The use of sexualized language or imagery
|
||||
* Personal attacks
|
||||
* Trolling or insulting/derogatory comments
|
||||
* Public or private harassment
|
||||
* Publishing other's private information, such as physical or electronic
|
||||
addresses, without explicit permission
|
||||
* Deliberate intimidation
|
||||
* Other unethical or unprofessional conduct
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or
|
||||
reject comments, commits, code, wiki edits, issues, and other contributions
|
||||
that are not aligned to this Code of Conduct, or to ban temporarily or
|
||||
permanently any contributor for other behaviors that they deem inappropriate,
|
||||
threatening, offensive, or harmful.
|
||||
|
||||
By adopting this Code of Conduct, project maintainers commit themselves to
|
||||
fairly and consistently applying these principles to every aspect of managing
|
||||
this project. Project maintainers who do not follow or enforce the Code of
|
||||
Conduct may be permanently removed from the project team.
|
||||
|
||||
This Code of Conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community.
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior directed at yourself or another community member may be
|
||||
reported by contacting a project maintainer at [conduct@bigchaindb.com](mailto:conduct@bigchaindb.com). All
|
||||
complaints will be reviewed and investigated and will result in a response that
|
||||
is appropriate to the circumstances. Maintainers are
|
||||
obligated to maintain confidentiality with regard to the reporter of an
|
||||
incident.
|
||||
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
|
||||
version 1.3.0, available at
|
||||
[http://contributor-covenant.org/version/1/3/0/][version]
|
||||
|
||||
[homepage]: http://contributor-covenant.org
|
||||
[version]: http://contributor-covenant.org/version/1/3/0/
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,90 +0,0 @@
|
|||
# Python Style Guide
|
||||
|
||||
This guide starts out with our general Python coding style guidelines and ends with a section on how we write & run (Python) tests.
|
||||
|
||||
## General Python Coding Style Guidelines
|
||||
|
||||
Our starting point is [PEP8](https://www.python.org/dev/peps/pep-0008/), the standard "Style Guide for Python Code." Many Python IDEs will check your code against PEP8. (Note that PEP8 isn't frozen; it actually changes over time, but slowly.)
|
||||
|
||||
BigchainDB uses Python 3.5+, so you can ignore all PEP8 guidelines specific to Python 2.
|
||||
|
||||
We use [pre-commit](http://pre-commit.com/) to check some of the rules below before every commit but not everything is realized yet.
|
||||
The hooks we use can be found in the [.pre-commit-config.yaml](https://github.com/bigchaindb/bigchaindb/blob/master/.pre-commit-config.yaml) file.
|
||||
|
||||
### Python Docstrings
|
||||
|
||||
PEP8 says some things about docstrings, but not what to put in them or how to structure them. [PEP257](https://www.python.org/dev/peps/pep-0257/) was one proposal for docstring conventions, but we prefer [Google-style docstrings](https://google.github.io/styleguide/pyguide.html?showone=Comments#Comments) instead: they're easier to read and the [napoleon extension](http://www.sphinx-doc.org/en/stable/ext/napoleon.html) for Sphinx lets us turn them into nice-looking documentation. Here are some references on Google-style docstrings:
|
||||
|
||||
* [Google's docs on Google-style docstrings](https://google.github.io/styleguide/pyguide.html?showone=Comments#Comments)
|
||||
* [napoleon's docs include an overview of Google-style docstrings](http://sphinxcontrib-napoleon.readthedocs.org/en/latest/index.html)
|
||||
* [Example Google-style docstrings](http://sphinxcontrib-napoleon.readthedocs.org/en/latest/example_google.html) (from napoleon's docs)
|
||||
|
||||
### Maximum Line Length
|
||||
|
||||
PEP8 has some [maximum line length guidelines](https://www.python.org/dev/peps/pep-0008/#id17), starting with "Limit all lines to a maximum of 79 characters" but "for flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters."
|
||||
|
||||
We discussed this at length, and it seems that the consensus is: _try_ to keep line lengths less than 79/72 characters, unless you have a special situation where longer lines would improve readability. (The basic reason is that 79/72 works for everyone, and BigchainDB is an open source project.) As a hard limit, keep all lines less than 119 characters (which is the width of GitHub code review).
|
||||
|
||||
### Single or Double Quotes?
|
||||
|
||||
Python lets you use single or double quotes. PEP8 says you can use either, as long as you're consistent. We try to stick to using single quotes, except in cases where using double quotes is more readable. For example:
|
||||
```python
|
||||
print('This doesn\'t look so nice.')
|
||||
print("Doesn't this look nicer?")
|
||||
```
|
||||
|
||||
### Breaking Strings Across Multiple Lines
|
||||
|
||||
Should we use parentheses or slashes (`\`) to break strings across multiple lines, i.e.
|
||||
```python
|
||||
my_string = ('This is a very long string, so long that it will not fit into just one line '
|
||||
'so it must be split across multiple lines.')
|
||||
# or
|
||||
my_string = 'This is a very long string, so long that it will not fit into just one line ' \
|
||||
'so it must be split across multiple lines.'
|
||||
```
|
||||
|
||||
It seems the preference is for slashes, but using parentheses is okay too. (There are good arguments either way. Arguing about it seems like a waste of time.)
|
||||
|
||||
### How to Format Long import Statements
|
||||
|
||||
If you need to `import` lots of names from a module or package, and they won't all fit in one line (without making the line too long), then use parentheses to spread the names across multiple lines, like so:
|
||||
```python
|
||||
from Tkinter import (
|
||||
Tk, Frame, Button, Entry, Canvas, Text,
|
||||
LEFT, DISABLED, NORMAL, RIDGE, END,
|
||||
)
|
||||
|
||||
# Or
|
||||
|
||||
from Tkinter import (Tk, Frame, Button, Entry, Canvas, Text,
|
||||
LEFT, DISABLED, NORMAL, RIDGE, END)
|
||||
```
|
||||
|
||||
For the rationale, see [PEP 328](https://www.python.org/dev/peps/pep-0328/#rationale-for-parentheses).
|
||||
|
||||
### Using the % operator or `format()` to Format Strings
|
||||
|
||||
Given the choice:
|
||||
```python
|
||||
x = 'name: %s; score: %d' % (name, n)
|
||||
# or
|
||||
x = 'name: {}; score: {}'.format(name, n)
|
||||
```
|
||||
|
||||
we use the `format()` version. The [official Python documentation says](https://docs.python.org/2/library/stdtypes.html#str.format), "This method of string formatting is the new standard in Python 3, and should be preferred to the % formatting described in String Formatting Operations in new code."
|
||||
|
||||
|
||||
## Running the Flake8 Style Checker
|
||||
|
||||
We use [Flake8](http://flake8.pycqa.org/en/latest/index.html) to check our Python code style. Once you have it installed, you can run it using:
|
||||
```text
|
||||
flake8 --max-line-length 119 bigchaindb/
|
||||
```
|
||||
|
||||
|
||||
## Writing and Running (Python) Tests
|
||||
|
||||
The content of this section was moved to [`bigchaindb/tests/README.md`](./tests/README.md).
|
||||
|
||||
Note: We automatically run all tests on all pull requests (using Travis CI), so you should definitely run all tests locally before you submit a pull request. See the above-linked README file for instructions.
|
||||
|
|
@ -1,81 +0,0 @@
|
|||
# Our Release Process
|
||||
|
||||
## Notes
|
||||
|
||||
This process hasn't been updated to the C4 way yet. That will simplify it a lot. Stay tuned! Until then, the basic idea is that there's only one branch: `master`. All releases are just Git tags of specific commits on the `master` branch.
|
||||
|
||||
This is the _BigchainDB Server_ release process. The process to release other BigchainDB software will be similar but not identical.
|
||||
|
||||
<hr>
|
||||
|
||||
The release process for BigchainDB server differs slightly depending on whether it's a minor or a patch release.
|
||||
|
||||
BigchainDB follows
|
||||
[the Python form of Semantic Versioning](https://packaging.python.org/tutorials/distributing-packages/#choosing-a-versioning-scheme)
|
||||
(i.e. MAJOR.MINOR.PATCH),
|
||||
which is almost identical
|
||||
to [regular semantic versioning](http://semver.org/)
|
||||
except release candidates are labelled like
|
||||
`3.4.5rc2` not `3.4.5-rc2` (with no hyphen).
|
||||
|
||||
|
||||
## Minor release
|
||||
|
||||
A minor release is preceeded by a feature freeze and created from the 'master' branch. This is a summary of the steps we go through to release a new minor version of BigchainDB Server.
|
||||
|
||||
1. Update the `CHANGELOG.md` file in master
|
||||
1. In `k8s/bigchaindb/bigchaindb-dep.yaml` AND in `k8s/dev-setup/bigchaindb.yaml`, find the line of the form `image: bigchaindb/bigchaindb:0.8.1` and change the version number to the new version number, e.g. `0.9.0`. (This is the Docker image that Kubernetes should pull from Docker Hub.) Commit that change to master
|
||||
1. Create and checkout a new branch for the minor release, named after the minor version, without a preceeding 'v', e.g. `git checkout -b 0.9` (*not* 0.9.0, this new branch will be for e.g. 0.9.0, 0.9.1, 0.9.2, etc. each of which will be identified by a tagged commit)
|
||||
1. Push the new branch to GitHub, e.g. `git push origin 0.9`
|
||||
1. Create and checkout a new branch off of the 0.9 branch. Let's call it branch T for now
|
||||
1. In `bigchaindb/version.py`, update `__version__` and `__short_version__`, e.g. to `0.9` and `0.9.0` (with no `.dev` on the end)
|
||||
1. Commit those changes, push the new branch T to GitHub, and use the pushed branch T to create a new pull request merging the T branch into the 0.9 branch.
|
||||
1. Wait for all the tests to pass! Then merge T into 0.9.
|
||||
1. Follow steps outlined in [Common Steps](#common-steps)
|
||||
1. In 'master' branch, Edit `bigchaindb/version.py`, increment the minor version to the next planned release, e.g. `0.10.0.dev`. (Exception: If you just released `X.Y.Zrc1` then increment the minor version to `X.Y.Zrc2`.) This step is so people reading the latest docs will know that they're for the latest (master branch) version of BigchainDB Server, not the docs at the time of the most recent release (which are also available).
|
||||
1. Go to [Docker Hub](https://hub.docker.com/), sign in, go to bigchaindb/bigchaindb, go to Settings - Build Settings, and under the build with Docker Tag Name equal to `latest`, change the Name to the number of the new release, e.g. `0.9`
|
||||
|
||||
Congratulations, you have released BigchainDB!
|
||||
|
||||
## Patch release
|
||||
|
||||
A patch release is similar to a minor release, but piggybacks on an existing minor release branch:
|
||||
|
||||
1. Check out the minor release branch, e.g. `0.9`
|
||||
1. Apply the changes you want, e.g. using `git cherry-pick`.
|
||||
1. Update the `CHANGELOG.md` file
|
||||
1. Increment the patch version in `bigchaindb/version.py`, e.g. `0.9.1`
|
||||
1. Commit that change
|
||||
1. In `k8s/bigchaindb/bigchaindb-dep.yaml` AND in `k8s/dev-setup/bigchaindb.yaml`, find the line of the form `image: bigchaindb/bigchaindb:0.9.0` and change the version number to the new version number, e.g. `0.9.1`. (This is the Docker image that Kubernetes should pull from Docker Hub.)
|
||||
1. Commit that change
|
||||
1. Push the updated minor release branch to GitHub
|
||||
1. Follow steps outlined in [Common Steps](#common-steps)
|
||||
1. Cherry-pick the `CHANGELOG.md` update commit (made above) to the `master` branch
|
||||
|
||||
## Common steps
|
||||
|
||||
These steps are common between minor and patch releases:
|
||||
|
||||
1. Go to the [bigchaindb/bigchaindb Releases page on GitHub](https://github.com/bigchaindb/bigchaindb/releases)
|
||||
and click the "Draft a new release" button
|
||||
1. Fill in the details:
|
||||
- Tag version: version number preceeded by 'v', e.g. "v0.9.1"
|
||||
- Target: the release branch that was just pushed
|
||||
- Title: Same as tag name above, e.g "v0.9.1"
|
||||
- Description: The body of the changelog entry (Added, Changed, etc.)
|
||||
1. Click "Publish release" to publish the release on GitHub
|
||||
1. Make sure your local Git is in the same state as the release: e.g. `git fetch <remote-name>` and `git checkout v0.9.1`
|
||||
1. Make sure you have a `~/.pypirc` file containing credentials for PyPI
|
||||
1. Do a `make release` to build and publish the new `bigchaindb` package on PyPI
|
||||
1. [Login to readthedocs.org](https://readthedocs.org/accounts/login/) and go to the **BigchainDB Server** project (*not* **BigchainDB**), then:
|
||||
- Go to Admin --> Advanced Settings
|
||||
and make sure that "Default branch:" (i.e. what "latest" points to)
|
||||
is set to the new release's tag, e.g. `v0.9.1`.
|
||||
(Don't miss the 'v' in front.)
|
||||
- Go to Admin --> Versions
|
||||
and under **Choose Active Versions**, do these things:
|
||||
1. Make sure that the new version's tag is "Active" and "Public"
|
||||
2. Make sure the new version's branch
|
||||
(without the 'v' in front) is _not_ active.
|
||||
3. Make sure the **stable** branch is _not_ active.
|
||||
4. Scroll to the bottom of the page and click the Submit button.
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
# Shared Workspace Protocol
|
||||
|
||||
|
||||
- Name: Shared Workspace Protocol
|
||||
- Status: raw
|
||||
- Editor: Alberto Granzotto <alberto@bigchaindb.com>
|
||||
|
||||
## Abstract
|
||||
Focusing in a shared workspace (or in the office in general) can be a really challenging task. Working from home solves the problem, but it is not an ideal solution if forced by the difficulty to focus in the office.
|
||||
|
||||
The "Shared Workspace Protocol" ("SWP" henceforth) provides a simple set of rules for people working in the same workspace.
|
||||
|
||||
## Language
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) \[[RFC2119](https://tools.ietf.org/html/rfc2119)\] \[[RFC8174](https://tools.ietf.org/html/rfc8174)\] when, and only when, they appear in all capitals, as shown here.
|
||||
|
||||
## Goals
|
||||
SWP provides a reusable collaboration model for people working in the same workspace. It has these specific goals:
|
||||
|
||||
1. To maximize focus and productivity, by reducing the sources of distraction.
|
||||
1. To reduce the burden to ask people to "behave" or "leave the room", by having an explicit protocol people agree before entering the room.
|
||||
|
||||
## Design
|
||||
1. When implemented, this protocol MUST be visible at the entrance of the shared workspace.
|
||||
1. A person SHOULD write a message to another person before speaking with them.
|
||||
1. A person SHOULD NOT be loud.
|
||||
1. A person SHOULD NOT talk to more than one person at a time.
|
||||
1. One-on-one conversations MUST be short and occasional.
|
||||
1. A person MUST NOT have calls unless everyone in the room is involved.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
Developer Setup, Coding & Contribution Process
|
||||
==============================================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
setup-dev-environment
|
||||
write-code
|
||||
vanshdeep-notes
|
||||
|
|
@ -128,7 +128,7 @@ $ pip install -e .[dev] # or pip install -e '.[dev]' # for zsh
|
|||
```
|
||||
|
||||
|
||||
## Running tests
|
||||
## Running All Tests
|
||||
|
||||
To execute tests when developing a feature or fixing a bug one could use the following command,
|
||||
|
||||
|
|
@ -1,12 +1,14 @@
|
|||
Write Code
|
||||
==========
|
||||
|
||||
What are you Doing???
|
||||
---------------------
|
||||
Know What You Want to Write Code to Do
|
||||
--------------------------------------
|
||||
|
||||
Tell us what you're doing somewhere so we don't do it too. You can tell us on Gitter or by email.
|
||||
If you're not sure how to proceed, see the :ref:`Issue Rules` and :ref:`Write a BEP <Write a BigchaindB Enhancement Proposal (BEP)>`
|
||||
for inspiration.
|
||||
Do you want to write code to resolve an open issue (bug)? Which one?
|
||||
|
||||
Do you want to implement a BigchainDB Enhancement Proposal (BEP)? Which one?
|
||||
|
||||
You should know why you want to write code before you go any farther.
|
||||
|
||||
|
||||
Refresh Yourself about the C4 Process
|
||||
|
|
@ -17,5 +17,6 @@ Contents
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
ways-to-contribute/index
|
||||
dev-setup-coding-and-contribution-process/index
|
||||
cross-project-policies/index
|
||||
ways-can-contribute/index
|
||||
|
|
|
|||
|
|
@ -1,44 +0,0 @@
|
|||
# Issue Rules
|
||||
|
||||
## Bad Issues Are Things Like This
|
||||
|
||||
We would be very sad to see you make an issue that is:
|
||||
|
||||
- Your latest brain fart.
|
||||
- An idea you had to maybe do in two years.
|
||||
- "Consider this..."
|
||||
- Something nobody really cares about, not even you.
|
||||
- Showing off your knowledge and understanding of something.
|
||||
- A "feature request." Make a [BEP](write-a-bep.html) for that. Or a small pull request with a well-defined _problem_ and _solution_ as desribed in C4. If you really _want_ something, make it happen! Don't try to trick others into thinking your idea is "interesting." Get the ball rolling.
|
||||
- A proposal of any length. Write a BEP.
|
||||
|
||||
If you do any of the above, we will just delete your issue. We don't have time for a long cluttered list of issues.
|
||||
|
||||
|
||||
## Good Issues Are Bug Reports
|
||||
|
||||
There is one good issue type: a proper bug report.
|
||||
|
||||
1. Go to the repository with the source code for the bug. Possibilities include:
|
||||
|
||||
- [BigchainDB Server](https://github.com/bigchaindb/bigchaindb)
|
||||
- [BigchainDB Python Driver](https://github.com/bigchaindb/bigchaindb-driver)
|
||||
- [BigchainDB JavaScript Driver](https://github.com/bigchaindb/js-bigchaindb-driver)
|
||||
- [cryptoconditions](https://github.com/bigchaindb/cryptoconditions) (a Python package by us)
|
||||
- [py-abci](https://github.com/davebryson/py-abci) (a Python package we use)
|
||||
|
||||
1. Click on the **Issues** tab.
|
||||
1. Click the button to create a **New Issue**.
|
||||
1. Describe everything in detail:
|
||||
|
||||
- What computer are you on (hardware)
|
||||
- What operating system are you using, including version. e.g. Ubuntu 14.04? Fedora 23? If it's not a Linux distro, then that's probably the problem.
|
||||
- What version of BigchainDB software were you using? Did you update it to the latest?
|
||||
- What, exactly, did you do to get to the point where you got stuck? Describe all the steps so we can get there too.
|
||||
- Show screenshots or copy-and-paste text to GitHub
|
||||
- Say what you expected to happen
|
||||
- Show what actually happened
|
||||
- Say what you tried to do to resolve the problem
|
||||
- Provide details to convince us that it matters to you. Is it for a school project, a job, a contract with a deadline, a child who needs it for Christmas?
|
||||
|
||||
We will do our best but please understand that we don't have time to help everyone, especially people who don't care to help us help them. "It doesn't work." is not going to get any reaction from us. We need _details_.
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
# Write a BigchaindB Enhancement Proposal (BEP)
|
||||
|
||||
This is the main way to get new BigchainDB code into the project.
|
||||
|
||||
There are two general paths:
|
||||
|
||||
1. Create a BEP. Then create a pull request to implement it. And so on.
|
||||
1. Create a new pull request straight away. This is less likely to work. It is only going to be permitted if the problem being solved is clear, obvious, small and well-defined in the pull request. If it's not, then a BEP was needed and you need to go back and write a BEP first.
|
||||
|
||||
|
||||
## Tips
|
||||
|
||||
- Review [1/C4](https://github.com/bigchaindb/BEPs/tree/master/1), the process we use to accept any new code or PR of any kind, including one that adds a BEP to `bigchaindb/BEPs`.
|
||||
- Review [2/COSS](https://github.com/bigchaindb/BEPs/tree/master/2). Maybe print it for reference. It outlines what can go in a BEP.
|
||||
- Don't spend weeks on your BEP. Version 1 should take a few hours to write up, maximum. You can add to it in the future. The process is iterative. If you need more than a few hours, then consider writing multiple BEPs.
|
||||
- Do not start writing code before you think about it. You should always write a BEP first. Once you do that, you _can_ start implementing it. To do that, make a pull request and say it implements your BEP.
|
||||
- If you're thinking of writing a new _issue_, think again. See the page [Issue Rules](issue-rules.html).
|
||||
|
||||
|
|
@ -1,15 +1,12 @@
|
|||
Ways to Contribute
|
||||
==================
|
||||
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
issue-rules
|
||||
report-a-bug
|
||||
write-an-issue
|
||||
make-a-feature-request-or-proposal
|
||||
write-a-bep
|
||||
setup-dev-environment
|
||||
write-code
|
||||
vanshdeep-notes
|
||||
write-docs
|
||||
answer-questions
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
# Make a Feature Request or Proposal
|
||||
|
||||
To make a feature request or proposal, [write a BigchainDB Enhancement Proposal (BEP)](write-a-bep.html).
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
# Report a Bug
|
||||
|
||||
To report a bug, go to the relevant GitHub repository, click on the **Issues** tab, click on the **New issue** button, and read the instructions.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
# Write a BigchaindB Enhancement Proposal (BEP)
|
||||
|
||||
- Review [1/C4](https://github.com/bigchaindb/BEPs/tree/master/1), the process we use to accept any new code or PR of any kind, including one that adds a BEP to `bigchaindb/BEPs`.
|
||||
- Review [2/COSS](https://github.com/bigchaindb/BEPs/tree/master/2). Maybe print it for reference. It outlines what can go in a BEP.
|
||||
- Don't spend weeks on your BEP. Version 1 should take up to a few hours to write. You can add to it in the future. The process is iterative. If you need more than a few hours, then consider writing multiple BEPs.
|
||||
- Do _not_ start writing code before you think about it. You should always write a BEP first. Once you do that, you can start implementing it. To do that, make a pull request and say it implements your BEP.
|
||||
- Do _not_ write your BEP as an issue (i.e. a GitHub issue).
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
# Write an Issue
|
||||
|
||||
To write an issue, go to the relevant GitHub repository, click on the **Issues** tab, click on the **New issue** button, and read the instructions.
|
||||
Loading…
Reference in New Issue