From 1f637cc7d966c0ede903041ed0d5c6b5483020ea Mon Sep 17 00:00:00 2001 From: Sebastian Ehlert <28669218+awvwgk@users.noreply.github.com> Date: Thu, 3 Sep 2020 14:44:01 +0200 Subject: Add contributing guidelines - adds a draft for contributing guidelines for fpm --- CONTRIBUTING.md | 131 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 CONTRIBUTING.md (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..b890980 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,131 @@ +# Contributing to the Fortran Package Manager + +First off, thank you for considering contributing to the Fortran Package Manager (fpm). +Please take a moment to review this guidelines to make the contribution process simple and effective for all involved. + +Respecting these guidelines helps communicate that you respect the time of the developers who manage and develop this open source project. +In return, they should return this respect by addressing your problem, evaluating changes, and helping you handle your pull requests. + +We encourage and enforce high quality code. +Generally, follow the +[style guide of the Fortran stdlib](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md) +for any contributed Fortran code. +This allows code review discussions to focus on semantics and substance rather than pedantry. + + +## Reporting a Bug + +A bug is a _demonstratable problem_ caused by the code in this repository. +Good bug reports are extremely valuable for us - thank you! + +Before opening a bug report: + +1. Check if the issue has already been reported. +2. Check if it still is an issue or has already been fixed? + Try to reproduce it with the latest version from the default branch. +3. Isolate the problem and create a reduced test case. + +A good bug report should not leave others needing to chase you up for more information. +So please try to be as detailed as possible in your report, answer at least these questions: + +1. Which version of fpm are you using? + The current version is always a subject to change, so be more specific. +2. What steps will reproduce the issue? + We have to reproduce the issue, so we need all the input files. +3. What would be the expected outcome? +4. What did you see instead? + +All these details will help people to fix any potential bugs. + + +## Suggesting a New Feature + +Feature requests are welcome. +But take a moment to find out if your idea fits the scope and goals of the project. +It is up to you to provide a strong argument to convince the project's developers of the benefits of this feature. +Please provide as much detail and context as possible. + + +## Implementing a New Feature + +Contributions are welcome via GitHub pull requests. +But suggest a new feature in an issue first to discuss the scope of the necessary changes or the required functionality before submitting a pull request. +You can always choose from one of the +[existing issues](https://github.com/fortran-lang/fpm/issues). + +- Each pull request should implement _one_ feature or fix _one_ bug. + If you want to add or fix more than one thing, submit more than one pull request. +- Do not commit changes to files that are irrelevant to your feature or bugfix (_e.g._ `.gitignore`). +- Add tests for your new features or fixed bugs such that we can ensure that they stay functional and useful +- Be willing to accept criticism and work on improving your code. + Have one to three maintainers review your contribution. +- Generally, follow the [style guide of the Fortran stdlib](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md) for any contributed Fortran code. + + +### For New Contributors + +If you never created a pull request before, welcome :tada:. +You can learn how from +[this great tutorial](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github). + +Don't know where to start? +You can start by looking through these +[help-wanted issues](https://github.com/fortran-lang/fpm/issues?q=label%3A%22help+wanted%22+is%3Aissue+is%3Aopen). + + +## Sign Your Work + +The sign-off is a simple line at the end of the explanation for a commit. +All commits needs to be signed. +Your signature certifies that you wrote the patch or otherwise have the right to contribute the material. +The rules are pretty simple, if you can certify the below +(from [developercertificate.org](https://developercertificate.org/)): + +``` +Developer Certificate of Origin +Version 1.1 + +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. +1 Letterman Drive +Suite D4700 +San Francisco, CA, 94129 + +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. +``` + +Then you just add a line to every git commit message: + +``` +Signed-off-by: Joe Smith +``` + +Use your real name (sorry, no pseudonyms or anonymous contributions.) + +If you set your `user.name` and `user.email` git configs, you can sign your commit automatically with `git commit -s`. -- cgit v1.2.3 From 63f6b077b76bf9d4380fbbd71a9211f61e642000 Mon Sep 17 00:00:00 2001 From: Sebastian Ehlert <28669218+awvwgk@users.noreply.github.com> Date: Thu, 3 Sep 2020 23:28:02 +0200 Subject: Remove DCO and signed commit requirement from guidelines --- CONTRIBUTING.md | 58 --------------------------------------------------------- 1 file changed, 58 deletions(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b890980..bdc1547 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -71,61 +71,3 @@ You can learn how from Don't know where to start? You can start by looking through these [help-wanted issues](https://github.com/fortran-lang/fpm/issues?q=label%3A%22help+wanted%22+is%3Aissue+is%3Aopen). - - -## Sign Your Work - -The sign-off is a simple line at the end of the explanation for a commit. -All commits needs to be signed. -Your signature certifies that you wrote the patch or otherwise have the right to contribute the material. -The rules are pretty simple, if you can certify the below -(from [developercertificate.org](https://developercertificate.org/)): - -``` -Developer Certificate of Origin -Version 1.1 - -Copyright (C) 2004, 2006 The Linux Foundation and its contributors. -1 Letterman Drive -Suite D4700 -San Francisco, CA, 94129 - -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. -``` - -Then you just add a line to every git commit message: - -``` -Signed-off-by: Joe Smith -``` - -Use your real name (sorry, no pseudonyms or anonymous contributions.) - -If you set your `user.name` and `user.email` git configs, you can sign your commit automatically with `git commit -s`. -- cgit v1.2.3 From 15953e0cd3c0a526bfdfe3149df65a986a64beca Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Sat, 5 Sep 2020 13:49:19 -0400 Subject: add workflow and edit text throughout --- CONTRIBUTING.md | 153 ++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 100 insertions(+), 53 deletions(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index bdc1547..e5eca7d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,68 +1,115 @@ # Contributing to the Fortran Package Manager -First off, thank you for considering contributing to the Fortran Package Manager (fpm). -Please take a moment to review this guidelines to make the contribution process simple and effective for all involved. - -Respecting these guidelines helps communicate that you respect the time of the developers who manage and develop this open source project. -In return, they should return this respect by addressing your problem, evaluating changes, and helping you handle your pull requests. - -We encourage and enforce high quality code. -Generally, follow the -[style guide of the Fortran stdlib](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md) -for any contributed Fortran code. -This allows code review discussions to focus on semantics and substance rather than pedantry. - - -## Reporting a Bug - -A bug is a _demonstratable problem_ caused by the code in this repository. -Good bug reports are extremely valuable for us - thank you! +Thank you for considering contributing to the Fortran Package Manager (fpm). +Please review and follow these guidelines to make the contribution process +simple and effective for all involved. +It will help communicate that you respect the time of the community +developers. +In return, the community will help address your problem, evaluate changes, and +guide you through your pull requests. + +* [Style](#style) +* [Reporting a bug](#reporting-a-bug) +* [Suggesting a feature](#suggesting-a-feature) +* [Workflow](#workflow) +* [General guidelines](#general-guidelines) +* [For new contributors](#for-new-contributors) + +## Style + +We require high-quality code. +Please follow the +[Fortran stdlib style guide](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md) +for any Fortran code that you contribute. +This allows us to focus on substance rather than style. + +## Reporting a bug + +A bug is a _demonstrable problem_ caused by the code in this repository. +Good bug reports are extremely valuable to us—thank you! Before opening a bug report: 1. Check if the issue has already been reported. -2. Check if it still is an issue or has already been fixed? - Try to reproduce it with the latest version from the default branch. -3. Isolate the problem and create a reduced test case. - -A good bug report should not leave others needing to chase you up for more information. -So please try to be as detailed as possible in your report, answer at least these questions: + ([issues](https://github.com/fortran-lang/fpm/issues)) +2. Check if it's still an issue or it has been fixed? + Try to reproduce it with the latest version from the master branch. +3. Isolate the problem and create a minimal test case. -1. Which version of fpm are you using? - The current version is always a subject to change, so be more specific. -2. What steps will reproduce the issue? - We have to reproduce the issue, so we need all the input files. -3. What would be the expected outcome? -4. What did you see instead? +A good bug report should include all information needed to reproduce the bug. +Please be as detailed as possible: -All these details will help people to fix any potential bugs. +1. Which version of fpm are you using? Please be specific. +2. What are the steps to reproduce the issue? +3. What is the expected outcome? +4. What happens instead? +This information will help the community diagnose the issue quickly and with +minimal back-and-forth. -## Suggesting a New Feature +## Suggesting a feature -Feature requests are welcome. -But take a moment to find out if your idea fits the scope and goals of the project. -It is up to you to provide a strong argument to convince the project's developers of the benefits of this feature. +Before suggesting a new feature, take a moment to find out if it fits +the scope of the project, or if it has already been discussed. +It's up to you to provide a strong argument to convince the community of the +benefits of this feature. Please provide as much detail and context as possible. - - -## Implementing a New Feature - -Contributions are welcome via GitHub pull requests. -But suggest a new feature in an issue first to discuss the scope of the necessary changes or the required functionality before submitting a pull request. -You can always choose from one of the -[existing issues](https://github.com/fortran-lang/fpm/issues). - -- Each pull request should implement _one_ feature or fix _one_ bug. - If you want to add or fix more than one thing, submit more than one pull request. -- Do not commit changes to files that are irrelevant to your feature or bugfix (_e.g._ `.gitignore`). -- Add tests for your new features or fixed bugs such that we can ensure that they stay functional and useful -- Be willing to accept criticism and work on improving your code. - Have one to three maintainers review your contribution. -- Generally, follow the [style guide of the Fortran stdlib](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md) for any contributed Fortran code. - - -### For New Contributors +If possible, include a mocked-up snippet of what the output or behavior would +look like with this feature implemented. +"Crazy", out-of-the-box ideas are especially welcome. +It's quite possible that we're not considering an unusually creative solution. + +## Workflow + +fpm is a community project. +There is no one single person making final decisions. +This the workflow that we follow: + +1. Open a [new issue](https://github.com/fortran-lang/fpm/issues/new) to + describe a bug or propose a new feature. + Refer to the earlier sections on how to write a good bug report or feature + request. +2. Discuss with the community and reach majority consensus about what should be + done about the bug or feature request. + We define "majority" loosely as 80%. + This means that at least 4 of 5 people engaged in the discussion should be + able to agree on the next step. + This allows us to have the community mostly agree while not getting stuck if + one person disagrees. + At this stage, the scope of the fix/feature, its behavior, and API if + applicable should be defined. + Only when you have community concensus on these items you should proceed + to step 3. +3. Open a new Pull Request (PR) with your contribution. + The body of the PR should at least include a bullet-point summary of the + changes, and a detailed description is encouraged. + If the PR completely addresses the issue you opened in step 1, include in + the PR description the following line: `Fixes #`. +4. Request reviewers to your PR. + For small bug fixes or documentation improvements, 1 to 2 reviewers is + sufficient. + For implementation of bigger features, request 3 to 4 or more reviewers. + Ideally, request reviewers that participated in step 2. +5. If your PR implements a feature that adds or changes the behavior of fpm, + your PR must also include appropriate changes to the documentation. + +This workflow can evolve and change over time as we learn how best to work +together. +If you have an idea on how to improve the workflow itself, please open an issue +and we'll discuss it. + +## General guidelines + +* A PR should implement _only one_ feature or bug fix. +* Do not commit changes to files that are irrelevant to your feature or bug fix. +* Smaller PRs are better than large PRs, and will lead to a shorter review and + merge cycle +* Add tests for your feature or bug fix to be sure that it stays functional and useful +* Be open to constructive criticism and requests for improving your code. +* Again, please follow the + [Fortran stdlib style guide](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md). + +## For New Contributors If you never created a pull request before, welcome :tada:. You can learn how from -- cgit v1.2.3 From d63c6365dd8fd80f60b78026fd5f70947458927f Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Sat, 5 Sep 2020 13:54:28 -0400 Subject: minor grammar and style fix --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e5eca7d..ce62dbe 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -54,7 +54,7 @@ the scope of the project, or if it has already been discussed. It's up to you to provide a strong argument to convince the community of the benefits of this feature. Please provide as much detail and context as possible. -If possible, include a mocked-up snippet of what the output or behavior would +If applicable, include a mocked-up snippet of what the output or behavior would look like with this feature implemented. "Crazy", out-of-the-box ideas are especially welcome. It's quite possible that we're not considering an unusually creative solution. @@ -63,7 +63,7 @@ It's quite possible that we're not considering an unusually creative solution. fpm is a community project. There is no one single person making final decisions. -This the workflow that we follow: +This is the workflow that we follow: 1. Open a [new issue](https://github.com/fortran-lang/fpm/issues/new) to describe a bug or propose a new feature. -- cgit v1.2.3 From 900e439be00e31d77e1e9e4fd929c589ebfcb417 Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Sat, 5 Sep 2020 14:41:09 -0400 Subject: add developer certification --- CONTRIBUTING.md | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ce62dbe..abce974 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -8,6 +8,10 @@ developers. In return, the community will help address your problem, evaluate changes, and guide you through your pull requests. +By contributing to fpm, you certify that you own or are allowed to share the +content of your contribution under the +[fpm license](https://github.com/fortran-lang/fpm/blob/master/LICENSE). + * [Style](#style) * [Reporting a bug](#reporting-a-bug) * [Suggesting a feature](#suggesting-a-feature) -- cgit v1.2.3 From 20c37324fa7ed6ef65392704b577ba2f77fecae8 Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Mon, 7 Sep 2020 12:18:51 -0400 Subject: Update CONTRIBUTING.md Co-authored-by: Laurence Kedward --- CONTRIBUTING.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index abce974..690fa23 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -83,7 +83,10 @@ This is the workflow that we follow: At this stage, the scope of the fix/feature, its behavior, and API if applicable should be defined. Only when you have community concensus on these items you should proceed - to step 3. + to writing code and opening a PR. + __When actively working on code towards a PR, please assign yourself to the issue on github.__ + This is good collaborative practice to avoid duplicated effort and also inform others what you + are currently working on. 3. Open a new Pull Request (PR) with your contribution. The body of the PR should at least include a bullet-point summary of the changes, and a detailed description is encouraged. -- cgit v1.2.3 From 78bf536251c03c4d7c7fb6134b59e0bcfa4a1bb6 Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Mon, 7 Sep 2020 12:20:06 -0400 Subject: Update CONTRIBUTING.md Co-authored-by: Laurence Kedward --- CONTRIBUTING.md | 1 - 1 file changed, 1 deletion(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 690fa23..0e0aa8d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -21,7 +21,6 @@ content of your contribution under the ## Style -We require high-quality code. Please follow the [Fortran stdlib style guide](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md) for any Fortran code that you contribute. -- cgit v1.2.3 From 61c2a7dc438f716d4b85a584fb4ed0f4046c9bb5 Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Mon, 7 Sep 2020 12:20:21 -0400 Subject: Update CONTRIBUTING.md Co-authored-by: Laurence Kedward --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0e0aa8d..1d6f6fa 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -117,7 +117,7 @@ and we'll discuss it. ## For New Contributors -If you never created a pull request before, welcome :tada:. +If you have never created a pull request before, welcome :tada:. You can learn how from [this great tutorial](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github). -- cgit v1.2.3 From a8ea9830c1bb64705688ac6b431aee7d8cee779b Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Mon, 7 Sep 2020 12:23:37 -0400 Subject: Update CONTRIBUTING.md --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1d6f6fa..afe81ca 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -122,5 +122,5 @@ You can learn how from [this great tutorial](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github). Don't know where to start? -You can start by looking through these -[help-wanted issues](https://github.com/fortran-lang/fpm/issues?q=label%3A%22help+wanted%22+is%3Aissue+is%3Aopen). +You can start by looking through the list of +[open issues](https://github.com/fortran-lang/fpm/issues). -- cgit v1.2.3 From 4c68956ada155ff15a0b22c1ac28f9c824c45091 Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Tue, 8 Sep 2020 14:50:07 -0400 Subject: Update CONTRIBUTING.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Ondřej Čertík --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index afe81ca..7ec202a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -35,7 +35,7 @@ Before opening a bug report: 1. Check if the issue has already been reported. ([issues](https://github.com/fortran-lang/fpm/issues)) -2. Check if it's still an issue or it has been fixed? +2. Check if it is still an issue or it has been fixed? Try to reproduce it with the latest version from the master branch. 3. Isolate the problem and create a minimal test case. -- cgit v1.2.3 From ec959b665f478787ade0ac29697d25ebd5bfac56 Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Tue, 8 Sep 2020 14:50:19 -0400 Subject: Update CONTRIBUTING.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Ondřej Čertík --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7ec202a..d6f0c23 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -54,7 +54,7 @@ minimal back-and-forth. Before suggesting a new feature, take a moment to find out if it fits the scope of the project, or if it has already been discussed. -It's up to you to provide a strong argument to convince the community of the +It is up to you to provide a strong argument to convince the community of the benefits of this feature. Please provide as much detail and context as possible. If applicable, include a mocked-up snippet of what the output or behavior would -- cgit v1.2.3 From 83c528cc04821e9817e5d5d8cadaa164fb067fe8 Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Tue, 8 Sep 2020 14:50:27 -0400 Subject: Update CONTRIBUTING.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Ondřej Čertík --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d6f0c23..1332278 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -60,7 +60,7 @@ Please provide as much detail and context as possible. If applicable, include a mocked-up snippet of what the output or behavior would look like with this feature implemented. "Crazy", out-of-the-box ideas are especially welcome. -It's quite possible that we're not considering an unusually creative solution. +It's quite possible that we are not considering an unusually creative solution. ## Workflow -- cgit v1.2.3