Skip to content

Latest commit

 

History

History
106 lines (77 loc) · 6.01 KB

README.md

File metadata and controls

106 lines (77 loc) · 6.01 KB
Raw


Actions Status Actions Status Actions Status Docs License: MIT Code style: black All-time uptime 100.00% Response time 773


Starting from version 1.0.0, this project is using semantic versioning. For more infos about the features supported, see the releases.

Installation & Setup

This project is part of the cs-insights-ecosystem. Please refer to the readme here to spin up the development and production system.

Code quality and tests

To maintain a consistent and well-tested repository, we use unit tests, linting, and typing checkers with GitHub actions. We use pytest for testing, pylint for linting, and pyright for typing. Every time code gets pushed to our repository these checks are executed and have to fullfill certain requirements before you can merge the code to our master branch.

We also use naming conventions for branches, commits, and pull requests to leverage GitHub workflow automation and keep the repository clean.

In the following we will describe how to run checks locally and which naming conventions we use.

CI

Whenever you create a pull request against the default branch, GitHub actions will create a CI job executing unit tests and linting.

Pre-commit

To make sure the code requirements are satisfied before you push code to the repository, we use pre-commit hooks.

Install the pre-commit hooks using:

poetry run pre-commit install

These hooks are automatically checked before you make a commit. To manually run the pre-commit checks, run:

poetry run pre-commit run --all-files

Replicate CI locally

You can run each of the commands checked in .github/workflows/main.yml:

poetry run poe lint
poetry run poe type
poetry run poe test

Repository and naming conventions

Each feature request, bug, enhancement, etc. has to be related to an issue. We have templates for bugs and features requests when you create an issue on GitHub. An issue should be a closed component that can be implemented by one developer in 1 day. If the issue is larger than that, split it into smaller components.

We group issues using a task list in another issue that has the Epic label. These issues are larger components that need to be developed. Each issue with the Epic label has a task list with each element of the task list being a issue (e.g., this one #47). Whenever a pull request with the above convention gets merged, the corresponding issue gets closed, and the task in the Epic gets checked.

When a branch is assigned to you, a new issue will be created from the dev branch including the issue number.

To indicate whether the PR is a patch, minor, or major update, please use #patch, #minor, #major in the last commit message of the PR and in the PR description. See here for more information.

To build changelogs, each pull-request needs one of the labels "fix", "feature", or "test". See here for more information.

Contributing

Fork the repo, make changes and send a PR. We'll review it together!

Commit messages should follow Angular's conventions.

License

This project is licensed under the terms of Apache 2.0 license. For more information, please see the LICENSE file.

Citation

If you use this repository, or use our tool for analysis, please cite our work:

@inproceedings{Wahle2022c,
  title        = {D3: A Massive Dataset of Scholarly Metadata for Analyzing the State of Computer Science Research},
  author       = {Wahle, Jan Philip and Ruas, Terry and Mohammad, Saif M. and Gipp, Bela},
  year         = {2022},
  month        = {July},
  booktitle    = {Proceedings of The 13th Language Resources and Evaluation Conference},
  publisher    = {European Language Resources Association},
  address      = {Marseille, France},
  doi          = {},
}