From 040f34ac8b1b70792fbd1af407a9b9dcc78efa24 Mon Sep 17 00:00:00 2001 From: rbalan Date: Mon, 25 Feb 2019 10:56:47 +0200 Subject: [PATCH] Added directory to store templates --- .github/CHANGELOGTemplate.md | 39 +++++++++++++++++++ .github/CONTRIBUTINGTemplate.md | 66 +++++++++++++++++++++++++++++++++ .github/ISSUE_TEMPLATE.md | 40 ++++++++++++++++++++ .github/PULLREQUESTTemplate.md | 45 ++++++++++++++++++++++ .github/READMETemplate.md | 62 +++++++++++++++++++++++++++++++ 5 files changed, 252 insertions(+) create mode 100644 .github/CHANGELOGTemplate.md create mode 100644 .github/CONTRIBUTINGTemplate.md create mode 100644 .github/ISSUE_TEMPLATE.md create mode 100644 .github/PULLREQUESTTemplate.md create mode 100644 .github/READMETemplate.md diff --git a/.github/CHANGELOGTemplate.md b/.github/CHANGELOGTemplate.md new file mode 100644 index 0000000..50eec4e --- /dev/null +++ b/.github/CHANGELOGTemplate.md @@ -0,0 +1,39 @@ +# Changelog +All notable changes to this project will be documented in this file. + +The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), +and this project adheres to [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html). + +## [Unreleased] +### Changed +- Add changes that are not released yet. + +## [1.0.0] - 2017-06-20 +### Added +- Added Feature 1, Link to feature +- Added Feature 2, Link to feature + +### Changed +- Modified Feature 1, Link to feature + + +### Removed +- Removed Feature 1, Link to feature + +## [0.3.0] - 2015-12-03 +### Added +- Add feature + +## [0.0.8] - 2015-02-17 +### Changed +- Changed feature, link to it + +### Fixed +- Bug fix 1, Link to ticket + +## 0.0.1 - 2014-05-31 +### Added +- This CHANGELOG file to hopefully serve as an evolving example of a + standardized open source project CHANGELOG. + + diff --git a/.github/CONTRIBUTINGTemplate.md b/.github/CONTRIBUTINGTemplate.md new file mode 100644 index 0000000..38eb648 --- /dev/null +++ b/.github/CONTRIBUTINGTemplate.md @@ -0,0 +1,66 @@ +# Contributing to {put-your-project-name} + +## Welcome contributors to the project +Admit that you are eager for contributions and so happy they found themselves here. + +## Table of Contents +If your CONTRIBUTING.md file is long, you might consider including a table of contents with links to different headings in your document. In GitHub, each heading is given a URL by default, so you can link to that URL in the appropriate section of the Table of Contents for each heading. Do this in Markdown by wrapping the heading in [ ] and following with a parenthetical that includes the URL or header after # like [Reporting Bugs](#How_to_file_a_bug). +## Short Links to Important Resources + **docs**: handbook / roadmap (you'll learn more about this in the roadmapping session). + **bugs**: issue tracker / bug report tool. + **comms**: forum link, developer list, IRC/email. +## Testing +How to test the project, where the tests are located in your directories. +* What plugins integrated in the Continous Integration pipeline are in place. +* Code Coverage Quality Gate and the percent of unit tests neeed for +* Provide local instructions to run code formatters, linters, test coverage suites with coverage reports before Pull Request. +## Environment details +How to set up the development environment. This might exist in the README.md/INSTALL.md depending on the project. If so include a link. An important part is the local build of the project. Documentation should be clear on how to build the project locally and what are the project dependencies to have a build run successfully. +## Design decisions +Provide a place (Distribution Lists, Slack channel, Github discussions) where you keep all the design decisions made in a transparent way. If a design decision is not clear or not enough documented, provide a hint on how to start a discussion around it. + +Is important to point out what is the way of starting a conversation around a change that can be submited by a contributor and that change has an impact on Design of the application. What is needed for a contributor to figure out if is on track and the change/adition won't conflict at a latter stage when sending a Pull Request. +There are multiple posibilities here: +* Start the conversation at the whiteboard. +* Have a call +* A more formal process by opening a GitHub issue or starting a new design review thread in the tool agreed for the project. + +Provide clear documentation in these area to avoid rework and increase predictibility(As a maintainer you will know that you will have to review an important change and include this in the Software Development Lifecycle). + +## How to submit changes +Pull Request protocol, Code Review process. You might also include what response they'll get back from the team on submission, or any caveats about the speed of response. Providing a timeframe for a response in general improves collaboration. This repository provides a template for [Pull Requests](https://github.com/adobe/open-development-template/blob/master/.github/PULLREQUESTTemplate.md) that can be [configured as default template for your repository in Github](https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/) and customised according to your needs. Segregation based on type can be configured to initiate a pull request that includes performance improvements, bug fixing, feature modification or documentation change. +## How to file a bug +Bugs are problems in code, in the functionality of an application or in its UI design; you can submit them through "bug trackers" and most projects invite you to do so, so that they may "debug" with more efficiency and the input of a contributor. The process of file a bug is mainly break into two steps: before submitting and submit a Bug Report. Guidance can be found below. + +### Before Submitting a Bug Report +1. Check the **debugging guide** for the project - E.g., how to activate verbose mode. Provide link to debugging guide that is specific to your project. +2. Check the **FAQs** for a list of common questions and problems. Provide link to FAQs +3. Check if the issue was already reported and the status of if. Provide search examples and where issues are raised (GitHub issues, JIRA tickets). +4. Determine which component/repository the issue should be reported in. + +### How do I submit a (good) Bug Report. +After deciding which component the bug relates to and where to raise the bug, next step will be to use a template, [ISSUE_TEMPLATE.md](https://github.com/adobe/open-development-template/blob/master/.github/ISSUE_TEMPLATE.md), that guides the reporter to help identifying faster where the problem is. + + +## How to request an "enhancement" +Enhancements are features that you might like to suggest to a project, but aren't necessarily bugs/problems with the existing code; there is a "label" for enhancements in Github's Issues (where you report bugs), so you can tag issues as "enhancement," and thereby allow contributors to prioritise issues/bugs reported to the project. If you are using a different tool to capture enhancements, for example JIRA, please provide documentation on label used to do that. +## Style Guide/Coding conventions +The aim of this section is to provide guidance on coding styles for different languages that are part of the project (You can use a default one or inherit the default one and decorate with project specifics). Besides source code style guide, style guides for writing Git commit messages, pull requests, documentation must be provided. +* Git Commit Messages Style guide. +* Java Style guide. +* Python Style guide. +* Documentation Style guide. + +If you are adopting a default style guide for example [Google Style Guide](https://github.com/google/styleguide) make it clear from the start and decorate only with the deltas if any. + +## Code of Conduct +You can make this part of CONTRIBUTING.md to set the tone for contributions. You can also make this a separate Markdown file and link to it in CONTRIBUTING.md. You can also extend this section to link to your LICENSE.md or any details for project consumers on permissions and license details you have established for building on your work. +## Recognition model +Provide a pre-emptive "thank you" for contributing and list any recognition contributors might receive for participating in your project. +## Who is involved? +It might be nice to have a more personal/friendly individual to attract to a project and reach out to with questions. You might list the core contributors and their preferred methods of contact here, or link to a **humans.txt** file in your root directory (same place as your CONTRIBUTING.md file), which lets people know who they are working. Here is an example of a [humans.txt](http://humanstxt.org/humans.txt) file. +## Where can I ask for help? +A nice extension to the previous section, with links to good comms channels for anyone with questions. + + + diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md new file mode 100644 index 0000000..fcf8665 --- /dev/null +++ b/.github/ISSUE_TEMPLATE.md @@ -0,0 +1,40 @@ + + +### Prerequisites + +* [ ] Put an X between the brackets on this line if you have done all of the following: + * Reproduced the problem in Safe Mode/Isolation: {Link to running in safemode/isolation} + * Followed all applicable steps in the debugging guide: {Link to debugging guide} + * Checked the FAQs on the message board for common solutions: {Link to FAQs, message boards} + * Checked that your issue isn't already filed: {Link to search criteria to identify similar issues} + * Checked that there is not already a component that provides the described functionality: {Link to features provided by the project} + +### Description + +[Description of the issue] + +### Steps to Reproduce + +1. [First Step] +2. [Second Step] +3. [and so on...] + +**Expected behavior:** [What you expect to happen] + +**Actual behavior:** [What actually happens] + +**Reproduces how often:** [What percentage of the time does it reproduce?] + +### Versions + +Provide detailed information for the contributor on how to find the version of the application, APIs version, the version of the execution environment. + +### Additional Information + +Any additional information, configuration or data that might be necessary to reproduce the issue. \ No newline at end of file diff --git a/.github/PULLREQUESTTemplate.md b/.github/PULLREQUESTTemplate.md new file mode 100644 index 0000000..9254489 --- /dev/null +++ b/.github/PULLREQUESTTemplate.md @@ -0,0 +1,45 @@ +## Pull Request Template + +Please use this to create a roadmap for your project or to track bugs. A pull request template improves development quality and provides a common guideline for contributors to follow. It also enables to you to reference issues and shows others your development progress. + + + +### Description + + +### Related Issue + + + + + + +### Motivation and Context + + +### How Has This Been Tested? + + + + + +### Screenshots (if appropriate): + +### Types of changes + +- [ ] Bug fix (non-breaking change which fixes an issue) +- [ ] New feature (non-breaking change which adds functionality) +- [ ] Breaking change (fix or feature that would cause existing functionality to change) + +### Checklist: + + +- [ ] This Pull Request is covered up by a Design Review. Provide link here or more details. +- [ ] My code follows the code style of this project. +- [ ] My change requires a change to the documentation. +- [ ] I have updated the documentation accordingly. +- [ ] I have read the **CONTRIBUTING** document. +- [ ] I have added tests to cover my changes. +- [ ] All new and existing tests passed. + + diff --git a/.github/READMETemplate.md b/.github/READMETemplate.md new file mode 100644 index 0000000..cdb1ee1 --- /dev/null +++ b/.github/READMETemplate.md @@ -0,0 +1,62 @@ +# Project Title + +Simple overview of use/purpose. + +## Description + +An in-depth paragraph about your project and overview of use. + +## Getting Started + +### Dependencies + +* Describe any prerequisites, libraries, OS version, etc., needed before installing program. +* ex. Windows 10, Execution Environment + +### Installing + +* How/where to download your program +* Any modifications needed to be made to files/folders + +### Executing program + +* How to run the program +* Step-by-step bullets +``` +code blocks for commands +``` + +## Help + +Any advise for common problems or issues. +``` +command to run if program contains helper info +``` + +## Authors + +Contributors names and contact info + +ex. +ex. + +## Version History + +* 0.2 + * Various bug fixes and optimizations + * See [commit change]() or See [release history]() +* 0.1 + * Initial Release + +## License + +This project is licensed under the [NAME HERE] License - see the LICENSE.md file for details + +## Acknowledgments + +Inspiration, code snippets, etc. +* [awesome-readme](https://github.com/matiassingers/awesome-readme) +* [PurpleBooth](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) +* [dbader](https://github.com/dbader/readme-template) +* [zenorocha](https://gist.github.com/zenorocha/4526327) +* [fvcproductions](https://gist.github.com/fvcproductions/1bfc2d4aecb01a834b46) \ No newline at end of file