-
Notifications
You must be signed in to change notification settings - Fork 26
Documentation improvements #29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 7 commits
e696f6d
4958971
61fddfc
5802981
de5eab2
11e343c
3bf6ed2
518f546
a8e4e68
434ff2e
2f7527b
363178f
e23160c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,73 @@ | ||
# Contributor Covenant Code of Conduct | ||
|
||
## Our Pledge | ||
|
||
In the interest of fostering an open and welcoming environment, we as | ||
contributors and maintainers pledge to making participation in our project and | ||
our community a harassment-free experience for everyone, regardless of age, body | ||
size, disability, ethnicity, gender identity and expression, level of experience, | ||
education, socio-economic status, nationality, personal appearance, race, | ||
religion, or sexual identity and orientation. | ||
|
||
## Our Standards | ||
|
||
Examples of behavior that contributes to creating a positive environment | ||
include: | ||
|
||
* Using welcoming and inclusive language | ||
* Being respectful of differing viewpoints and experiences | ||
* Gracefully accepting constructive criticism | ||
* Focusing on what is best for the community | ||
* Showing empathy towards other community members | ||
|
||
Examples of unacceptable behavior by participants include: | ||
|
||
* The use of sexualized language or imagery and unwelcome sexual attention or | ||
advances | ||
* Trolling, insulting/derogatory comments, and personal or political attacks | ||
* Public or private harassment | ||
* Publishing others' private information, such as a physical or electronic | ||
address, without explicit permission | ||
* Other conduct which could reasonably be considered inappropriate in a | ||
professional setting | ||
|
||
## Our Responsibilities | ||
|
||
Project maintainers are responsible for clarifying the standards of acceptable | ||
behavior and are expected to take appropriate and fair corrective action in | ||
response to any instances of unacceptable behavior. | ||
|
||
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. | ||
|
||
## Scope | ||
|
||
This Code of Conduct applies both within project spaces and in public spaces | ||
when an individual is representing the project or its community. Examples of | ||
representing a project or community include using an official project e-mail | ||
address, posting via an official social media account, or acting as an appointed | ||
representative at an online or offline event. Representation of a project may be | ||
further defined and clarified by project maintainers. | ||
|
||
## Enforcement | ||
|
||
Instances of abusive, harassing, or otherwise unacceptable behavior may be | ||
reported by contacting the project team at conduct@sourced.tech. All | ||
complaints will be reviewed and investigated and will result in a response that | ||
is deemed necessary and appropriate to the circumstances. The project team is | ||
obligated to maintain confidentiality with regard to the reporter of an incident. | ||
Further details of specific enforcement policies may be posted separately. | ||
|
||
Project maintainers who do not follow or enforce the Code of Conduct in good | ||
faith may face temporary or permanent repercussions as determined by other | ||
members of the project's leadership. | ||
|
||
## Attribution | ||
|
||
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, | ||
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html | ||
|
||
[homepage]: https://www.contributor-covenant.org |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,86 @@ | ||
# Contributing Guidelines | ||
|
||
source{d} code annotation tool project is [GPLv3 licensed](LICENSE) and accept | ||
contributions via GitHub pull requests. This document outlines some of the | ||
conventions on development workflow, commit message formatting, contact points, | ||
and other resources to make it easier to get your contribution accepted. | ||
|
||
## Certificate of Origin | ||
|
||
By contributing to this project you agree to the [Developer Certificate of | ||
Origin (DCO)](DCO). This document was created by the Linux Kernel community and is a | ||
simple statement that you, as a contributor, have the legal right to make the | ||
contribution. | ||
|
||
In order to show your agreement with the DCO you should include at the end of commit message, | ||
the following line: `Signed-off-by: John Doe <john.doe@example.com>`, using your real name. | ||
|
||
This can be done easily using the [`-s`](https://github.com/git/git/blob/b2c150d3aa82f6583b9aadfecc5f8fa1c74aca09/Documentation/git-commit.txt#L154-L161) flag on the `git commit`. | ||
|
||
## Support Channels | ||
|
||
The official support channels, for both users and contributors, are: | ||
|
||
* GitHub [issues](https://github.com/src-d/code-annotation/issues)\* | ||
|
||
\*Before opening a new issue or submitting a new pull request, it's helpful to | ||
search the project - it's likely that another user has already reported the | ||
issue you're facing, or it's a known issue that we're already aware of. | ||
|
||
## How to Contribute | ||
|
||
Pull Requests (PRs) are the main and exclusive way to contribute to the code-annotation project. | ||
In order for a PR to be accepted it needs to pass a list of requirements: | ||
|
||
* If the PR is a bug fix, it has to include a new unit test that fails before the patch is merged. | ||
* If the PR is a new feature, it has to come with a suite of unit tests, that tests the new functionality. | ||
* In any case, all the PRs have to pass the personal evaluation of at least one of the [maintainers](MAINTAINERS) of code-annotation project. | ||
|
||
### Format of the commit message | ||
|
||
Every commit message should describe what was changed, under which context and, if applicable, the GitHub issue it relates to: | ||
|
||
``` | ||
plumbing: packp, Skip argument validations for unknown capabilities. Fixes #623 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In a single line? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It comes from the template in the guide: https://github.com/src-d/guide/blob/master/engineering/documents/CONTRIBUTING.md |
||
``` | ||
|
||
## Development | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this section needs a bit more detail. For example: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. about frontend is it more clear in #36 in description? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, in that comment the steps are more clearly put |
||
|
||
> Please note: you will need a .env file configured with working GitHub OAuth credentials to run the application in development mode. | ||
> Please follow the [README Installation section](./README.md#installation) for instructions on how to do it. | ||
To build and run the tool, execute: | ||
|
||
```bash | ||
$ go get -d -u github.com/src-d/code-annotation/... | ||
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does #33 being merged change any of these, here and below? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. no. |
||
$ cd $GOPATH/github.com/src-d/code-annotation | ||
$ make serve | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is a missing step, setting .env. Otherwise make serve will complain. Also make serve will not inform that the server is listening on :8080 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is exactly the same than wrote in the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the same than wrote in |
||
``` | ||
|
||
### Frontend: | ||
|
||
If you want to benifit from frontend hot reloading feature put this line in your `.env` file: | ||
|
||
|
||
```bash | ||
UI_DOMAIN=http://127.0.0.1:3000 | ||
``` | ||
|
||
Run server. Execute: | ||
|
||
```bash | ||
$ make gorun | ||
``` | ||
|
||
And then run frontend in dev mode. Execute: | ||
|
||
```bash | ||
$ yarn start | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This can be confusing, as make server does not stop until it is killed. It should be mentioned that "yarn start" needs to be executed in another terminal |
||
``` | ||
|
||
### Backend: | ||
|
||
Shortcut to run `go run` with environment variables | ||
|
||
```bash | ||
$ make gorun | ||
``` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ```bash I think we should also have a common style to put (or not) a $ before commands that are supposed to be run in the shell. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
Developer Certificate of Origin | ||
Version 1.1 | ||
|
||
Copyright (C) 2004, 2006 The Linux Foundation and its contributors. | ||
660 York Street, Suite 102, | ||
San Francisco, CA 94110 USA | ||
|
||
Everyone is permitted to copy and distribute verbatim copies of this | ||
license document, but changing it is not allowed. | ||
|
||
|
||
Developer's Certificate of Origin 1.1 | ||
|
||
By making a contribution to this project, I certify that: | ||
|
||
(a) The contribution was created in whole or in part by me and I | ||
have the right to submit it under the open source license | ||
indicated in the file; or | ||
|
||
(b) The contribution is based upon previous work that, to the best | ||
of my knowledge, is covered under an appropriate open source | ||
license and I have the right under that license to submit that | ||
work with modifications, whether created in whole or in part | ||
by me, under the same open source license (unless I am | ||
permitted to submit under a different license), as indicated | ||
in the file; or | ||
|
||
(c) The contribution was provided directly to me by some other | ||
person who certified (a), (b) or (c) and I have not modified | ||
it. | ||
|
||
(d) I understand and agree that this project and the contribution | ||
are public and that a record of the contribution (including all | ||
personal information I submit with it, including my sign-off) is | ||
maintained indefinitely and may be redistributed consistent with | ||
this project or the open source license(s) involved. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,60 +1,92 @@ | ||
# Source Code Annotation application | ||
[](https://travis-ci.org/src-d/code-annotation) | ||
 | ||
|
||
# Source Code Annotation Tool | ||
|
||
In order to evaluate quality of ML models, as well as to create “ImageNet for source core” there is a need for tools to automate the data collection/labeling/annotation. | ||
|
||
|
||
 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure what this screenshot shows. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it shows the interface of the tool. There are 2 files, the difference is in 1 line. We ask a user to mark it as identical/similar/different. It is what this tool does. |
||
|
||
## Installation | ||
|
||
### Github OAuth tokens | ||
|
||
First you need OAuth application on github. [Read how to create it](https://developer.github.com/apps/building-oauth-apps/creating-an-oauth-app/). | ||
1. You need OAuth application on github. [Read how to create it](https://developer.github.com/apps/building-oauth-apps/creating-an-oauth-app/). | ||
|
||
|
||
`Authorization callback URL: http://127.0.0.1:8080/oauth-callback` | ||
|
||
|
||
On a [page](https://github.com/settings/developers) with your application you will need `Client ID` and `Client Secret` | ||
2. Copy `.env.tpl` to `.env`. | ||
|
||
Copy `.env.tpl` to `.env` and set tokens there. | ||
3. On a [page](https://github.com/settings/developers) with your application find `Client ID` and `Client Secret` and put them in `.env` file. | ||
|
||
|
||
### Docker | ||
|
||
|
||
```bash | ||
docker build -t srcd/code-annotation . | ||
docker run --env-file .env --rm -p 8080:8080 srcd/code-annotation | ||
$ docker build -t srcd/code-annotation . | ||
|
||
$ docker run --env-file .env --rm -p 8080:8080 srcd/code-annotation | ||
|
||
``` | ||
|
||
### Non-docker | ||
|
||
```bash | ||
go get github.com/src-d/code-annotation/... | ||
cd $GOPATH/github.com/src-d/code-annotation | ||
make serve | ||
$ go get github.com/src-d/code-annotation/... | ||
$ cd $GOPATH/github.com/src-d/code-annotation | ||
$ make serve | ||
``` | ||
|
||
## Development | ||
## Importing and Exporting Data | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Importing a DB should be part of the installation process because otherwise, the application would not work. The exporting process could be part of another section like "gathering the result of the annotation process". |
||
|
||
Backend: | ||
### Import File Pairs for Annotation | ||
|
||
``` | ||
make gorun | ||
``` | ||
The file pairs must be initially provided via an [SQLite](https://sqlite.org/) database. The database **must follow the expected schema**, please [follow this link](./cli/examples/import/example.sql) to see an example. | ||
|
||
|
||
Frontend: | ||
The `import` command will use those file pairs to create a new [SQLite](https://sqlite.org/) or [PostgreSQL](https://www.postgresql.org/) database that will be used internally by the Annotation Tool. The destination database does not need to be empty, new imported file pairs can be added to previous imports. | ||
|
||
If you want to benifit from frontend hot reloading feature this line in your `.env` file: | ||
_Please note_: if a file pair is identical to an existing one it will not be detected. A new pair entry will be created with the same contents. | ||
|
||
|
||
To use it, run it as: | ||
|
||
```bash | ||
$ import <path-to-sqlite.db> <destination-DSN> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. With the current content of this go build ./cli/import/... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I ran the following: sqlite3 sample.db < cli/import/examples/example.sql
import sample.db sqlite://$GOPATH/src/github.com/src-d/code-annotation/sample.internal.db and it failed import: no encode delegate for this image format `SQLITE' @ warning/constitute.c/WriteImage/1171.
import: unable to open image `sqlite:///projects/src/github.com/src-d/code-annotation/sample.internal.db': No such file or directory @ error/blob.c/OpenBlob/2712. Did I missed any dependency or something else? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The documentation says:
So, if the purpose of the import <path-to-input-sqlite.db> <application-internal-db-DSN> There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In my personal opinion, we should try to have a clear and small argument hint, leaving the complete explanation to the docs and the --help output. Unless other people agree with your suggestion, I'd skip this. |
||
``` | ||
UI_DOMAIN=http://127.0.0.1:3000 | ||
``` | ||
|
||
And then restart server. | ||
Where the `DSN` (Data Source Name) argument must be one of: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it a wrong idea to link to a DSN definition?
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd skip it. The readme already explains the acronym, and all the possible options available to the user. No further link is needed to understand the argument. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In the export section, it was added a hint about the command parameters:
I think it would be a good idea to do so here:
|
||
|
||
* `sqlite:///path/to/db.db` | ||
* `postgresql://[user[:password]@][netloc][:port][,...][/dbname]` | ||
|
||
To run frontend in dev mode: | ||
Some usage examples: | ||
|
||
```bash | ||
$ import ./input.db sqlite:///home/user/internal.db | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is there any output expected? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, there is. I've added the output to the usage examples, a few lines below. |
||
|
||
$ import /home/user/input.db postgres://testing:testing@localhost:5432/input?sslmode=disable | ||
``` | ||
yarn | ||
yarn start | ||
|
||
For a complete reference of the PostgreSQL connection string, see the [documentation for the lib/pq Go package](https://godoc.org/github.com/lib/pq#hdr-Connection_String_Parameters). | ||
|
||
### Export Annotation Results | ||
|
||
To work with the annotation results, the internal data can be extracted into a new SQLite database using the `export` command. | ||
|
||
```bash | ||
$ export <origin-DSN> <path-to-sqlite.db> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since it is said that:
I'd use the same argument hint for the input than used in the export <application-internal-db-DSN> <path-to-output-sqlite.db> |
||
``` | ||
|
||
The DSN argument uses the same format as the `import` tool, see the previous section. | ||
|
||
In this case, origin will be the internal database, and destination the new database. This new database will have the same contents as the internal one. | ||
|
||
To study the user annotation results, focus on the **`assignments`** table. | ||
|
||
|
||
## Contributing | ||
|
||
Please take a look at [CONTRIBUTING](CONTRIBUTING.md) file to see how to contribute in this project, get more information about the dashboard [architecture](CONTRIBUTING.md#Architecture) and how to launch it for [development](CONTRIBUTING.md#Development) purposes. | ||
[Contributions](https://github.com/src-d/code-annotation/issues) are more than welcome, if you are interested please take a look to | ||
our [Contributing Guidelines](CONTRIBUTING.md). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd add:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure we should change template There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The template is only a guideline, not a mandatory thing to follow. I understood we can things to improve it, especially when linking to other places of our docs There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since links to other internal docs are welcomed, could you add it? :D |
||
|
||
# Code of Conduct | ||
|
||
All activities source{d} projects are governed by the [source{d} code of conduct](CODE_OF_CONDUCT.md). | ||
|
||
|
||
## License | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for such effort of improving the documentation!!!
Let me suggest some things; here is a list of the main ones:
README.md
:Contributing.md