docs: added editorconfig, code of conduct and contributing docs
This commit is contained in:
+1338
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,45 @@
|
||||
# Code of Conduct
|
||||
|
||||
## Our Pledge
|
||||
|
||||
We as members, contributors, and leaders pledge to make participation in our project a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
|
||||
|
||||
## Our Standards
|
||||
|
||||
Examples of behaviour 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 behaviour by participants include:
|
||||
|
||||
- The use of sexualised language or imagery, and unwelcome sexual attention or advances
|
||||
- Trolling, insulting, or derogatory comments
|
||||
- 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
|
||||
|
||||
## Enforcement Responsibilities
|
||||
|
||||
Project maintainers are responsible for clarifying the standards of acceptable behaviour and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behaviour.
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that do not align with this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
|
||||
|
||||
## 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 email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
|
||||
|
||||
## Enforcement
|
||||
|
||||
Instances of abusive, harassing, or unacceptable behaviour may be reported by contacting the project team at [your-email@example.com]. 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.
|
||||
|
||||
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](https://www.contributor-covenant.org/), version 1.4, available at https://www.contributor-covenant.org/version/1/4/
|
||||
|
||||
@@ -0,0 +1,59 @@
|
||||
# Contributing to Java Dev Kit
|
||||
|
||||
We appreciate your interest in contributing to our Java Enterprise Utility Library. Contributions are welcome in various
|
||||
forms such as code, documentation, bug reports, and test cases. To ensure a smooth collaboration, please follow the
|
||||
guidelines outlined below.
|
||||
|
||||
## Getting Started
|
||||
|
||||
The Java Dev Kit is an open-source Java library designed to ease Java enterprise application development. It is built
|
||||
with Java 17, and we require contributors to use OpenJDK 17.
|
||||
|
||||
## Development Setup
|
||||
|
||||
There is no need for manual setup beyond ensuring you have JDK 17 and a stable internet connection. Our project uses
|
||||
Gradle Wrapper for building, simplifying the setup process.
|
||||
|
||||
```shell
|
||||
./gradlew build
|
||||
```
|
||||
|
||||
## Branching Strategy
|
||||
|
||||
We follow the `git-flow` branching model. Contributors should fork this repository and create their work on separate
|
||||
branches prefixed with `feature/` or `hotfix/` as appropriate.
|
||||
|
||||
## Code Style
|
||||
|
||||
Please adhere to the coding standards specified in our `.editorconfig` file in the root of the repository. Consistent
|
||||
style helps in maintaining readability and uniformity across the codebase.
|
||||
|
||||
## Commit Messages
|
||||
|
||||
We require that commit messages follow this structure:
|
||||
|
||||
```text
|
||||
type[(scope)]: subject
|
||||
|
||||
[body]
|
||||
|
||||
[BREAKING CHANGE: breaking changes]
|
||||
```
|
||||
|
||||
This format helps in auto-generating changelogs and understanding the purpose behind changes.
|
||||
|
||||
## Submitting Contributions
|
||||
|
||||
1. Fork the repository.
|
||||
2. Create a branch: `git checkout -b feature/my-new-feature` or `git checkout -b hotfix/my-fix`.
|
||||
3. Make your changes and commit them.
|
||||
4. Push to the branch: `git push origin feature/my-new-feature`.
|
||||
5. Create a Pull Request with a succinct subject and a detailed body.
|
||||
|
||||
## Testing
|
||||
|
||||
We encourage using JUnit Jupiter for unit and integration tests. Pull Requests with accompanying test reports are prioritised for review and merging.
|
||||
|
||||
## License
|
||||
|
||||
By contributing to the Java Dev Kit, you agree that your contributions will be licensed under the Apache 2.0 license. If you do not agree to this, please refrain from contributing.
|
||||
Reference in New Issue
Block a user