Add some style guidelines for contributors
This commit is contained in:
parent
42146c5e8a
commit
9ef5986288
|
|
@ -15,18 +15,21 @@ can work on.
|
|||
writing new ones, or providing usage examples.
|
||||
* **Testing**: Test coverage is important for a library. Writing tests is not only helpful, but is also a great way
|
||||
to get a feel for how tanya works.
|
||||
* **Adding new features**: Tanya is a growing library. If you think some feature is missing, you can suggest
|
||||
and implement this.
|
||||
|
||||
|
||||
## Opening an issue
|
||||
|
||||
If you have found a bug, an error, have some question, or suggestion, open in issue. Tanya uses an external
|
||||
If you have found a bug, an error, have some question, or suggestion, open in issue. I'll try to answer as soon
|
||||
as I can. Tanya uses an external
|
||||
[bug tracker](https://issues.caraus.io/projects/tanya/issues). You should
|
||||
[register](https://issues.caraus.io/account/register) before you can report your issue. There is also a list
|
||||
of open issues that mirror the current development process and progress. If you're looking for a challenge, just
|
||||
pick an issue you are interested in and start working on it. Fill free to comment on the issue to get more
|
||||
information.
|
||||
|
||||
Some issues have a category assigned to it. Such issues belongs mostly to a larger part of the library that is
|
||||
Some issues have a category assigned to them. Such issues belong mostly to a larger part of the library that is
|
||||
currently in development. The category specifies then the git branch development happens on. The remaining issues
|
||||
can be fixed directly in master.
|
||||
|
||||
|
|
@ -35,9 +38,11 @@ to be fixed till a specific release. Version numbers refer to the versions in th
|
|||
[git repository](https://github.com/caraus-ecms/tanya/releases).
|
||||
|
||||
|
||||
## Creating a pull request
|
||||
## Contribution process
|
||||
|
||||
I accept GitHub pull requests. Creating a pull request is like sending a patch with a suggested change.
|
||||
### Creating a pull request
|
||||
|
||||
I accept GitHub pull requests. Creating a pull request is like sending a patch with the suggested change.
|
||||
First you have to [fork](https://guides.github.com/activities/forking/) the repository. Clone your fork locally
|
||||
with `git clone` and create a new branch where you want to work, for example:
|
||||
|
||||
|
|
@ -47,16 +52,39 @@ git checkout -b bugfix-x
|
|||
Commit your changes to your fork:
|
||||
|
||||
```shell
|
||||
git commit -m "Fix Bug X"
|
||||
git commit -m "Fix X"
|
||||
git push -u origin bugfix-x
|
||||
```
|
||||
|
||||
After that if you visit your fork on GitHub, GitHub will suggest to create pull request. Just follow the steps
|
||||
described on GitHub to finish the process.
|
||||
described on GitHub to finish the process. See
|
||||
[Using Pull Requests](https://help.github.com/articles/about-pull-requests/) for more information.
|
||||
|
||||
Please ensure that you fork is even with the upstream (original) repository. If not, you have to rebase your branch
|
||||
on upstream master before submitting a pull request. See https://help.github.com/articles/syncing-a-fork/ for a
|
||||
on upstream/master before submitting a pull request. See https://help.github.com/articles/syncing-a-fork/ for a
|
||||
step-by-step guide.
|
||||
|
||||
### Fixing a bug
|
||||
|
||||
Add a unittest that demonstrates the bug along with a short description:
|
||||
|
||||
```d
|
||||
// Issue ###: https://issues.caraus.io/issues/###.
|
||||
private unittest
|
||||
{
|
||||
}
|
||||
```
|
||||
|
||||
### Adding new features
|
||||
|
||||
* Use Ddoc to document the feature.
|
||||
* Add some unittests that demonstrate how the feature is supposed to work and prevent new bugs.
|
||||
|
||||
### Style guide
|
||||
|
||||
Make sure your changes follow [The D Style](https://dlang.org/dstyle.html) (including
|
||||
[Additional Requirements for Phobos](https://dlang.org/dstyle.html#phobos).
|
||||
|
||||
|
||||
## Questions and suggestions
|
||||
|
||||
|
|
|
|||
18
README.md
18
README.md
|
|
@ -19,9 +19,10 @@ data structures and utilities that depend on the Garbage Collector in Phobos.
|
|||
* [Documentation](https://docs.caraus.io/tanya)
|
||||
* [Contribution guidelines](CONTRIBUTING.md)
|
||||
|
||||
|
||||
## Overview
|
||||
|
||||
Tanya consists of the following packages:
|
||||
Tanya consists of the following packages and (top-level) modules:
|
||||
|
||||
* `async`: Event loop (epoll, kqueue and IOCP).
|
||||
* `container`: Queue, Array, Singly and doubly linked lists, Buffers, UTF-8
|
||||
|
|
@ -29,8 +30,14 @@ string, Hash set.
|
|||
* `format`: Formatting and conversion functions.
|
||||
* `math`: Arbitrary precision integer and a set of functions.
|
||||
* `memory`: Tools for manual memory management (allocators, smart pointers).
|
||||
* `net`: URL-Parsing, sockets, utilities.
|
||||
* `net`: URL-Parsing, network programming.
|
||||
* `network`: Socket implementation. `network` is currently under rework.
|
||||
After finishing the new socket implementation will land in the `net` package and
|
||||
`network` will be deprecated.
|
||||
* `os`: Platform-independent interfaces to operating system functionality.
|
||||
* `typecons`: Templates that allow to build new types based on the available
|
||||
ones.
|
||||
|
||||
|
||||
## Basic usage
|
||||
|
||||
|
|
@ -125,6 +132,7 @@ int i = arr[7]; // Access 7th element.
|
|||
|
||||
There are more containers in the `tanya.container` package.
|
||||
|
||||
|
||||
## Development
|
||||
|
||||
### Supported compilers
|
||||
|
|
@ -160,3 +168,9 @@ Deprecated features are removed after one release (in approximately 6 weeks afte
|
|||
is being tested on Windows and FreeBSD as well.
|
||||
|
||||
* The library isn't thread-safe yet.
|
||||
|
||||
|
||||
## Feedback
|
||||
|
||||
Any feedback about your experience with tanya would be greatly appreciated. Feel free to
|
||||
[contact me](mailto:info@caraus.de).
|
||||
|
|
|
|||
Loading…
Reference in New Issue