elharo commented on code in PR #588: URL: https://github.com/apache/maven-site/pull/588#discussion_r1877991750
########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. Review Comment: The --> A delete "when you would like" ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. + +The GitHub Issue can be created if you would like to discuss a proposition of change before start working on it. +In such cases developer mailing list can also be used instead of issue. + +When you provide a Pull Request - creating separate issue is not necessary as you can describe your proposition in Pull Request. Review Comment: is this really what we want? It sounds diffeerent than what's been proposed before. ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. + +The GitHub Issue can be created if you would like to discuss a proposition of change before start working on it. Review Comment: delete "if you would like" delete "proposition of" start working on it --> starting work. ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. + +The GitHub Issue can be created if you would like to discuss a proposition of change before start working on it. +In such cases developer mailing list can also be used instead of issue. + +When you provide a Pull Request - creating separate issue is not necessary as you can describe your proposition in Pull Request. + Review Comment: should be referenced in the commit message by `#issue-number`. --> reference the issue in the commit message by `#issue-number`. ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. + +The GitHub Issue can be created if you would like to discuss a proposition of change before start working on it. +In such cases developer mailing list can also be used instead of issue. + +When you provide a Pull Request - creating separate issue is not necessary as you can describe your proposition in Pull Request. + +When fixing the issue by providing Pull Request, should be referenced in the commit message by `#issue-number`. + +The GitHub Issue and Pull Request should have a label with type, like `bug`, `enhancement` and so on. +Pull Request without labels will be not categorized in Release Notes. + +Closed GitHub Issue and Pull Request should have milestone in which was resolved. + +Pull Request title is used to generate Release Notes - should be similar or the same as merged commit. + +We should always provide changes by Pull Request. Direct commits will be not visible in Release Notes. + +## Release Notes + +Only Pull Requests wits status **Merged** will be visible in Release Notes. + +We use GitHub Release Notes. + +We use the [Release Drafter Action](https://github.com/marketplace/actions/release-drafter) +to prepare Release Notes. + +Default labels configurations are in the [maven-gh-actions-shared](https://github.com/apache/maven-gh-actions-shared/blob/main/.github/release-drafter.yml) project. + +## How To Use Issue and Pull Request Details? + +### Assignee + +Committers can assign a GitHub Issue, Pull Request to a specific committer if that person seems +to be well-placed to address it. + +Merged Pull Request should be assigned to committer who merge it. + +### Reviewers + +We should invite persons to review for every change, even it is simply one, review can increase code quality. + +### Priority + +For priority, we can use labels: + +- `priority:low` +- `priority:medium` +- `priority:high` +- `priority:critical` + +### Type + +For GitHub Issue and Pull Request we use labels, like: Review Comment: Pull Requests ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,106 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issue, Pull Request - Recommendations. + +**Minor changes** such as code reformatting, documentation fixes, etc. that aren't going to impact other users +can be committed without a GitHub Issue, but Pull Request is recommended. + +**Larger changes** such as bug fixes, API changes, significant refactoring, new classes, and pretty much any change +of more than 100 lines, and **New feature** should have GitHub Issue in order to first discus planed change. + +GitHub Issue should be referenced in commit message by `#issue-number`. + +GitHub Issue and Pull Request should have a label with type, like `bug`, `enhancement` and so on. +Pull Request without labels will be not categorized in Release Notes. Review Comment: Enforcement is a major problem for non-comimtter contributors who cannot change labels. Let's not enforce. We can always clean uop labels later before generating release notes. ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. + +The GitHub Issue can be created if you would like to discuss a proposition of change before start working on it. +In such cases developer mailing list can also be used instead of issue. + +When you provide a Pull Request - creating separate issue is not necessary as you can describe your proposition in Pull Request. + +When fixing the issue by providing Pull Request, should be referenced in the commit message by `#issue-number`. + +The GitHub Issue and Pull Request should have a label with type, like `bug`, `enhancement` and so on. +Pull Request without labels will be not categorized in Release Notes. + +Closed GitHub Issue and Pull Request should have milestone in which was resolved. + +Pull Request title is used to generate Release Notes - should be similar or the same as merged commit. + +We should always provide changes by Pull Request. Direct commits will be not visible in Release Notes. + +## Release Notes + +Only Pull Requests wits status **Merged** will be visible in Release Notes. + +We use GitHub Release Notes. + +We use the [Release Drafter Action](https://github.com/marketplace/actions/release-drafter) +to prepare Release Notes. + +Default labels configurations are in the [maven-gh-actions-shared](https://github.com/apache/maven-gh-actions-shared/blob/main/.github/release-drafter.yml) project. + +## How To Use Issue and Pull Request Details? + +### Assignee + +Committers can assign a GitHub Issue, Pull Request to a specific committer if that person seems +to be well-placed to address it. + +Merged Pull Request should be assigned to committer who merge it. + +### Reviewers + +We should invite persons to review for every change, even it is simply one, review can increase code quality. + +### Priority + +For priority, we can use labels: + +- `priority:low` +- `priority:medium` +- `priority:high` +- `priority:critical` + +### Type + +For GitHub Issue and Pull Request we use labels, like: + +- `bug` +- `dependencies` +- `documentation` +- `enhancement` + +### Component/s + +For assign an issue/PR to component we can use labels, like: `component:name` Review Comment: For --> To ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. + +The GitHub Issue can be created if you would like to discuss a proposition of change before start working on it. +In such cases developer mailing list can also be used instead of issue. + +When you provide a Pull Request - creating separate issue is not necessary as you can describe your proposition in Pull Request. + +When fixing the issue by providing Pull Request, should be referenced in the commit message by `#issue-number`. + +The GitHub Issue and Pull Request should have a label with type, like `bug`, `enhancement` and so on. +Pull Request without labels will be not categorized in Release Notes. + +Closed GitHub Issue and Pull Request should have milestone in which was resolved. + +Pull Request title is used to generate Release Notes - should be similar or the same as merged commit. + +We should always provide changes by Pull Request. Direct commits will be not visible in Release Notes. + +## Release Notes + +Only Pull Requests wits status **Merged** will be visible in Release Notes. Review Comment: wits --> with I might not even say this. It's pretty obvious ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. + +The GitHub Issue can be created if you would like to discuss a proposition of change before start working on it. +In such cases developer mailing list can also be used instead of issue. Review Comment: In such cases developer mailing list can also be used instead of issue. --> The developer mailing list can also be used to discuss proposed work. ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. + +The GitHub Issue can be created if you would like to discuss a proposition of change before start working on it. +In such cases developer mailing list can also be used instead of issue. + +When you provide a Pull Request - creating separate issue is not necessary as you can describe your proposition in Pull Request. + +When fixing the issue by providing Pull Request, should be referenced in the commit message by `#issue-number`. + +The GitHub Issue and Pull Request should have a label with type, like `bug`, `enhancement` and so on. +Pull Request without labels will be not categorized in Release Notes. + +Closed GitHub Issue and Pull Request should have milestone in which was resolved. + +Pull Request title is used to generate Release Notes - should be similar or the same as merged commit. + +We should always provide changes by Pull Request. Direct commits will be not visible in Release Notes. + +## Release Notes + +Only Pull Requests wits status **Merged** will be visible in Release Notes. + +We use GitHub Release Notes. + +We use the [Release Drafter Action](https://github.com/marketplace/actions/release-drafter) +to prepare Release Notes. + +Default labels configurations are in the [maven-gh-actions-shared](https://github.com/apache/maven-gh-actions-shared/blob/main/.github/release-drafter.yml) project. + +## How To Use Issue and Pull Request Details? + +### Assignee + +Committers can assign a GitHub Issue, Pull Request to a specific committer if that person seems Review Comment: , --> or ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. + +The GitHub Issue can be created if you would like to discuss a proposition of change before start working on it. +In such cases developer mailing list can also be used instead of issue. + +When you provide a Pull Request - creating separate issue is not necessary as you can describe your proposition in Pull Request. + +When fixing the issue by providing Pull Request, should be referenced in the commit message by `#issue-number`. + +The GitHub Issue and Pull Request should have a label with type, like `bug`, `enhancement` and so on. Review Comment: the type ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. + +The GitHub Issue can be created if you would like to discuss a proposition of change before start working on it. +In such cases developer mailing list can also be used instead of issue. + +When you provide a Pull Request - creating separate issue is not necessary as you can describe your proposition in Pull Request. + +When fixing the issue by providing Pull Request, should be referenced in the commit message by `#issue-number`. + +The GitHub Issue and Pull Request should have a label with type, like `bug`, `enhancement` and so on. +Pull Request without labels will be not categorized in Release Notes. + +Closed GitHub Issue and Pull Request should have milestone in which was resolved. + +Pull Request title is used to generate Release Notes - should be similar or the same as merged commit. + +We should always provide changes by Pull Request. Direct commits will be not visible in Release Notes. + +## Release Notes + +Only Pull Requests wits status **Merged** will be visible in Release Notes. + +We use GitHub Release Notes. + +We use the [Release Drafter Action](https://github.com/marketplace/actions/release-drafter) +to prepare Release Notes. + +Default labels configurations are in the [maven-gh-actions-shared](https://github.com/apache/maven-gh-actions-shared/blob/main/.github/release-drafter.yml) project. Review Comment: labels --> label ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. + +The GitHub Issue can be created if you would like to discuss a proposition of change before start working on it. +In such cases developer mailing list can also be used instead of issue. + +When you provide a Pull Request - creating separate issue is not necessary as you can describe your proposition in Pull Request. + +When fixing the issue by providing Pull Request, should be referenced in the commit message by `#issue-number`. + +The GitHub Issue and Pull Request should have a label with type, like `bug`, `enhancement` and so on. +Pull Request without labels will be not categorized in Release Notes. + +Closed GitHub Issue and Pull Request should have milestone in which was resolved. + +Pull Request title is used to generate Release Notes - should be similar or the same as merged commit. + +We should always provide changes by Pull Request. Direct commits will be not visible in Release Notes. + +## Release Notes + +Only Pull Requests wits status **Merged** will be visible in Release Notes. + +We use GitHub Release Notes. + +We use the [Release Drafter Action](https://github.com/marketplace/actions/release-drafter) +to prepare Release Notes. + +Default labels configurations are in the [maven-gh-actions-shared](https://github.com/apache/maven-gh-actions-shared/blob/main/.github/release-drafter.yml) project. + +## How To Use Issue and Pull Request Details? + +### Assignee + +Committers can assign a GitHub Issue, Pull Request to a specific committer if that person seems +to be well-placed to address it. + +Merged Pull Request should be assigned to committer who merge it. + +### Reviewers + +We should invite persons to review for every change, even it is simply one, review can increase code quality. + +### Priority + +For priority, we can use labels: + +- `priority:low` +- `priority:medium` +- `priority:high` +- `priority:critical` + +### Type + +For GitHub Issue and Pull Request we use labels, like: + +- `bug` +- `dependencies` +- `documentation` +- `enhancement` + +### Component/s + +For assign an issue/PR to component we can use labels, like: `component:name` + +### Fix Version/s + +We use `Milestones` for assign to fix versions. Review Comment: for --> to ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,99 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issues, Pull Request - Recommendations. + +The GitHub Issue should be created when you would like to report a bug or request a new feature. + +The GitHub Issue can be created if you would like to discuss a proposition of change before start working on it. +In such cases developer mailing list can also be used instead of issue. + +When you provide a Pull Request - creating separate issue is not necessary as you can describe your proposition in Pull Request. + +When fixing the issue by providing Pull Request, should be referenced in the commit message by `#issue-number`. + +The GitHub Issue and Pull Request should have a label with type, like `bug`, `enhancement` and so on. +Pull Request without labels will be not categorized in Release Notes. + +Closed GitHub Issue and Pull Request should have milestone in which was resolved. + +Pull Request title is used to generate Release Notes - should be similar or the same as merged commit. + +We should always provide changes by Pull Request. Direct commits will be not visible in Release Notes. Review Comment: Now this is something we should enforce. I have had problems with non-PR commits in our repos. ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,106 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issue, Pull Request - Recommendations. + +**Minor changes** such as code reformatting, documentation fixes, etc. that aren't going to impact other users +can be committed without a GitHub Issue, but Pull Request is recommended. + +**Larger changes** such as bug fixes, API changes, significant refactoring, new classes, and pretty much any change +of more than 100 lines, and **New feature** should have GitHub Issue in order to first discus planed change. + +GitHub Issue should be referenced in commit message by `#issue-number`. + +GitHub Issue and Pull Request should have a label with type, like `bug`, `enhancement` and so on. +Pull Request without labels will be not categorized in Release Notes. + +Closed GitHub Issue and Pull Request should have milestone in which was resolved. Review Comment: Honestly every project I've seen to date that tries to use Github milestones has de facto abandoned them. I don't quite understand why, but developers do seem to ignore milestones after the first few months, ########## content/markdown/developers/conventions/github.md: ########## @@ -0,0 +1,106 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Maven GitHub Conventions + +This document describes how Maven developers and contributors should use GitHub Issues and Pull Request. + +## GitHub Issue, Pull Request - Recommendations. + +**Minor changes** such as code reformatting, documentation fixes, etc. that aren't going to impact other users +can be committed without a GitHub Issue, but Pull Request is recommended. + +**Larger changes** such as bug fixes, API changes, significant refactoring, new classes, and pretty much any change +of more than 100 lines, and **New feature** should have GitHub Issue in order to first discus planed change. + +GitHub Issue should be referenced in commit message by `#issue-number`. + +GitHub Issue and Pull Request should have a label with type, like `bug`, `enhancement` and so on. +Pull Request without labels will be not categorized in Release Notes. + +Closed GitHub Issue and Pull Request should have milestone in which was resolved. + +Pull Request title is used to generate Release Notes - should be similar or the same as merged commit. + +Simply we should always provide changes by Pull Request. Direct commits will be not visible in Release Notes. + +## Release Notes + +Only Pull Request wits status **Merged** will be visible in Release Notes. + +We use GitHub Release Notes. + +We use the [Release Drafter Action](https://github.com/marketplace/actions/release-drafter) +for automatically preparing Release Notes. + +Default labels configurations are in [maven-gh-actions-shared](https://github.com/apache/maven-gh-actions-shared/blob/main/.github/release-drafter.yml) project. + +## How To Use Issue and Pull Request Details? + +### Assignee + +Committers can assign an GitHub Issue, Pull Request to a specific committer that person seems +to be well-placed to address it. + +Merged Pull Request should be assigned to committer who merge it. Review Comment: Automatic or not, I still don't understand the purpose this serves. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
