Skip to content
Merged
Binary file added .github/screenshot.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
73 changes: 73 additions & 0 deletions CODE_OF_CONDUCT.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
# Contributor Covenant Code of Conduct
Copy link
Contributor

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:
    • explain first the app purpose, and then its motivation,
    • refactor the installation section to cover the full process from the beginning to the end, explaining the two different alternatives: with/without docker, and how to setup the backend DB,
    • fix docker commands, that does not work,
    • simplify the import/export section to its minimum necesities,
    • add a Requirements section (example in landing)
    • add a link to the Contributing#Development
  • Contributing.md
    • simplify the Contributing#Development section,


## 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
86 changes: 86 additions & 0 deletions CONTRIBUTING.md
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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a single line?
Normally the Fixes #123 tends to be on its own.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

```

## Development
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this section needs a bit more detail.

For example:
I can run the frontend in dev mode with yarn start. Does that mean the backend is not needed? Or needs to be started in some other way?
If I run make gorun, do I need to build the frontend code before?
What about the github auth tokens mentioned in the REAME? Is also needed for development?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

about frontend is it more clear in #36 in description?
I'll add info about token.

Copy link
Contributor

Choose a reason for hiding this comment

The 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/...
Copy link
Contributor

@bzz bzz Jan 29, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does #33 being merged change any of these, here and below?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no. go get will download everything with vendors and you still need make serve to build FE.

$ cd $GOPATH/github.com/src-d/code-annotation
$ make serve
Copy link
Contributor

Choose a reason for hiding this comment

The 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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is exactly the same than wrote in the README.md under the "Non-docker" section.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the same than wrote in README.md under the "Installation section", so unnecessary here

```

### Frontend:

If you want to benifit from frontend hot reloading feature put this line in your `.env` file:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/benifit/benefit

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find a great idea to explain how to run the front in hot-reloading mode, but suggesting to add a different UI_DOMAIN into the .env file will ruin the server if it is launched with the recommended command (make serve). To avoid that problem, I would not recommend modifying the .env file, rewording this section as it follows:

### Running the frontend with hot reloading.

First, run the frontend:

yarn start

and then, serve the backend with a proper UI_DOMAIN value, running:

UI_DOMAIN=http://127.0.0.1:3000 make gorun


```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
Copy link
Contributor

Choose a reason for hiding this comment

The 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
```
Copy link
Contributor

Choose a reason for hiding this comment

The 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.

36 changes: 36 additions & 0 deletions DCO
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.
78 changes: 55 additions & 23 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,60 +1,92 @@
# Source Code Annotation application
[![Build Status](https://travis-ci.org/src-d/code-annotation.svg)](https://travis-ci.org/src-d/code-annotation)
![unstable](https://svg-badge.appspot.com/badge/stability/unstable?a)

# 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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ImageNet for Source Code


![Screenshot](.github/screenshot.png?raw=true)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what this screenshot shows.
Does it detect there's a new line of code? Is that line relevant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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/).
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try to write links that describe what they point to.

You need an OAuth application on GitHub. See how to create OAuth applications on GitHub.


`Authorization callback URL: http://127.0.0.1:8080/oauth-callback`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a development configuration value

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to change it to http(s)://<hostname:port>/oauth-callback? I think it's even more confusing.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Explain what this means.

In order to be able to use this token while running your application locally, make sure you add http://127.0.0.1:8080/oauth-callback to the authorization callback URL field.

Maybe add a screenshot of the form with the value in it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what token? README doesn't mention any token at this point.
I changed

In order to be able to use this application while running the tool locally

screenshot might be too much. The is already a screenshot of the field in github documentation we are pointing to.


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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Retrieve the values for your application's Client ID and Client Secret from the GitHub Developer Settings page and add them to the end of the corresponding lines in .env.


### Docker
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docker and Non-docker sections are self-excluding.

I think it can be easier understood if it would be:

### Run the server
The preferred way to run the server is with docker
commands here
If you prefer running the server without docker you need to satisfy the [app requirements](#requirements), and then run:
make serve

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the section about docker. A user should run the only image created by us. We don't have such image yet.
More info here: #36 (comment)


```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 .
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dep is not a built-in command in golang:1.8-alpine3.6 image, so it should be added to the Dockerfile; otherwise, the suggested docker build command will fail.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's solved by smacker#3

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the section about docker. A user should run the only image created by us. We don't have such image yet.
More info here: #36 (comment)

$ docker run --env-file .env --rm -p 8080:8080 srcd/code-annotation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This command fails because the container entrypoint is not correct.
The Dockerfile should be changed to

COPY --from=0 /go/src/code-annotation/bin/server .
CMD ["./server"]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's solved by smacker#3

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the section about docker. A user should run the only image created by us. We don't have such image yet.
More info here: #36 (comment)

```

### 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the README.md should be something understandable from the beginning to the end, so it should be avoided to include things without context.
If we agree on that, the following sentence:

the file pairs must be initially provided via an SQLite database.

What a file pairs is? Why is it needed in the context of this project?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drop the "initially", it implies that should have happened before this step.

Also since the schema is so important you should make it explicit and maybe paste the result of calling DESCRIBE TABLE here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

About the schema: it was actually removed as requested, see #29 (comment).
Pinging @bzz.


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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand this phrase.
Does this mean we can end up with duplicate results for files that are equal if we run more than the analysis more than once?

Please clarify

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@carlosms could you please handle it. It's a part about the import.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify: if a user logs in to annotate file pairs more than once, we will not end up with duplicate results. Previous annotation results are already saved for each user.

This only applies if you add new data to annotate to an already existing installation, using the "import" tool.

Let's say you decide to add new data, and one of those new file pairs is repoA repoB, src/A src/A.
If that very same file pair was existing from before, the DB will contain that previous pair, and the new one.

The only reason it works this way is because we decided not to guess too much. This can be changed easily when the ML team starts using the app and providing feedback.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it a super-useful implementation-detail notice for the internal users and developer of the project.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: duplicate entries are not filtered, so running an import multiple times will result in repeated rows.


To use it, run it as:

```bash
$ import <path-to-sqlite.db> <destination-DSN>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the current content of this README.md the import command does not exist.
It should be needed to compile the import tool before using it

go build ./cli/import/...

Copy link
Contributor

Choose a reason for hiding this comment

The 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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation says:

The import command will [...] create a new [...] database that will be used internally by the Annotation Tool.

So, if the purpose of the import command is to create the internal DB to be used by the Annotation Tool, I'd write the command this way:

import <path-to-input-sqlite.db> <application-internal-db-DSN>

Copy link
Contributor

Choose a reason for hiding this comment

The 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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it a wrong idea to link to a DSN definition?
For example:

Where the DSN ([Data Source Name](https://en.wikipedia.org/wiki/Data_source_name)) argument must be one of:

Copy link
Contributor

Choose a reason for hiding this comment

The 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.

Copy link
Contributor

Choose a reason for hiding this comment

The 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:

In this case, origin will be the internal database, and destination the new database.

I think it would be a good idea to do so here:

In this case, <path-to-sqlite.db> is the database with the pairs to import, and <destination-DSN> will be the DSN of the internal database.


* `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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there any output expected?

Copy link
Contributor

Choose a reason for hiding this comment

The 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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since it is said that:

the internal data can be extracted into a new SQLite database using the export command.

I'd use the same argument hint for the input than used in the input documentation:

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd reword:

The annotations made by the workers for each different FilePair will be stored in 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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd add:

If you're interested in running the application in development mode, take a look at the [development section](CONTRIBUTING.md#Development)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure we should change template

Copy link
Contributor

Choose a reason for hiding this comment

The 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

Copy link
Contributor

Choose a reason for hiding this comment

The 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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is "activities source{d} projects" right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry, I don't understand you. This text comes from the template.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there was a mistake on the template!

src-d/guide#123


## License

Expand Down