From e2e9c9f8ac0f6b77bb7dfc0de6b17d46a2fd1c8d Mon Sep 17 00:00:00 2001 From: Nan Zhu Date: Sun, 7 Jul 2019 21:18:02 -0700 Subject: [PATCH 1/3] add community doc --- doc/contrib/community.rst | 33 +++++++++++++++++++++++++++++++++ doc/contrib/index.rst | 14 ++++++++++++++ doc/contrib/release.rst | 15 +++++++++++++++ doc/index.rst | 1 + 4 files changed, 63 insertions(+) create mode 100644 doc/contrib/community.rst create mode 100644 doc/contrib/index.rst create mode 100644 doc/contrib/release.rst diff --git a/doc/contrib/community.rst b/doc/contrib/community.rst new file mode 100644 index 000000000000..b32e80a3d70c --- /dev/null +++ b/doc/contrib/community.rst @@ -0,0 +1,33 @@ +.. _community_guide: + +XGBoost Community Guideline +======================= + +XGBoost adopts the Apache style model and governs by merit. We believe that it is important to create an inclusive community where everyone can use, contribute to, and influence the direction of the project. See `CONTRIBUTORS.md `_ for the current list of contributors. + + + +General Development Process +--------------------------- +Everyone in the community is welcomed to send patches, documents, and propose new directions to the project. The key guideline here is to enable everyone in the community to get involved and participate the decision and development. When major changes are proposed, an RFC should be sent to allow discussion by the community. We encourage public discussion, archivable channels such as issues, discuss forum and mailing-list, so that everyone in the community can participate and review the process later. + +Code reviews are one of the key ways to ensure the quality of the code. High-quality code reviews prevent technical debt for long-term and are crucial to the success of the project. A pull request needs to be reviewed before it gets merged. A committer who has the expertise of the corresponding area would moderate the pull request and the merge the code when it is ready. The corresponding committer could request multiple reviewers who are familiar with the area of the code. We encourage contributors to request code reviews themselves and help review each other's code -- remember everyone is volunteering their time to the community, high-quality code review itself costs as much as the actual code contribution, you could get your code quickly reviewed if you do others the same favor. + +The community should strive to reach a consensus on technical decisions through discussion. We expect committers and PMCs to moderate technical discussions in a diplomatic way, and provide suggestions with clear technical reasoning when necessary. + + + +Committers +---------- +Committers are individuals who are granted the write access to the project. A committer is usually responsible for a certain area or several areas of the code where they oversee the code review process. The area of contribution can take all forms, including code contributions and code reviews, documents, education, and outreach. Committers are essential for a high quality and healthy project. The community actively look for new committers from contributors. Here is a list of useful traits that help the community to recognize potential committers: + +- Sustained contribution to the project, demonstrated by discussion over RFCs, code reviews and proposals of new features, and other development activities. Being familiar with, and being able to take ownership on one or several areas of the project. +- Quality of contributions: High-quality, readable code contributions indicated by pull requests that can be merged without a substantial code review. History of creating clean, maintainable code and including good test cases. Informative code reviews to help other contributors that adhere to a good standard. +- Community involvement: active participation in the discussion forum, promote the projects via tutorials, talks and outreach. We encourage committers to collaborate broadly, e.g. do code reviews and discuss designs with community members that they do not interact physically. + +The Project Management Committee(PMC) consists group of active committers that moderate the discussion, manage the project release, and proposes new committer/PMC members. Potential candidates are usually proposed via an internal discussion among PMCs, followed by a consensus approval, i.e. least 3 +1 votes, and no vetoes. Any veto must be accompanied by reasoning. PMCs should serve the community by upholding the community practices and guidelines TVM a better community for everyone. PMCs should strive to only nominate new candidates outside of their own organization. + + +Reviewers +--------- +Reviewers are individuals who actively contributed to the project and are willing to participate in the code review of new contributions. We identify reviewers from active contributors. The committers should explicitly solicit reviews from reviewers. High-quality code reviews prevent technical debt for long-term and are crucial to the success of the project. A pull request to the project has to be reviewed by at least one reviewer in order to be merged. diff --git a/doc/contrib/index.rst b/doc/contrib/index.rst new file mode 100644 index 000000000000..b7354b5c9b31 --- /dev/null +++ b/doc/contrib/index.rst @@ -0,0 +1,14 @@ +################### +Contribute to XGBoost +################### + + +******** +Contents +******** + +.. toctree:: + :maxdepth: 2 + + XGBoost Community Guidance + Release Policy diff --git a/doc/contrib/release.rst b/doc/contrib/release.rst new file mode 100644 index 000000000000..f0a64c29bd63 --- /dev/null +++ b/doc/contrib/release.rst @@ -0,0 +1,15 @@ +.. _release: + +XGBoost Release Policy +======================= + +Versioning Policy +--------------------------- + +Starting from XGBoost 1.0.0, each XGBoost release will be versioned as [MAJOR].[FEATURE].[MAINTENANCE] + +* MAJOR: We gurantee the API compatibility across releases with the same major version umber. We expect to have a 1+ years development period for a new MAJOR release version. +* FEATURE: We ship new features, improvements and bug fixes through feature releases. The cycle length of a feature is decided by the size of feature roadmap. The roadmap is decided right after the previous release. + + +MAINTENANCE: Maintenance releases will occur more frequently and depend on specific patches introduced (e.g. bug fixes) and their urgency. In general these releases are designed to patch bugs. However, higher level libraries may introduce small features, such as a new algorithm, provided they are entirely additive and isolated from existing code paths. Spark core may not introduce any features. diff --git a/doc/index.rst b/doc/index.rst index 01592ce4d7b4..212c3d79415e 100644 --- a/doc/index.rst +++ b/doc/index.rst @@ -15,6 +15,7 @@ Contents :maxdepth: 2 :titlesonly: + community build get_started tutorials/index From b55c125845a312d3a001090cc0f679381fba633e Mon Sep 17 00:00:00 2001 From: Nan Zhu Date: Mon, 8 Jul 2019 07:01:17 -0700 Subject: [PATCH 2/3] update --- doc/contrib/community.rst | 4 ++-- doc/contrib/release.rst | 4 +--- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/doc/contrib/community.rst b/doc/contrib/community.rst index b32e80a3d70c..7ecac4a5f856 100644 --- a/doc/contrib/community.rst +++ b/doc/contrib/community.rst @@ -9,7 +9,7 @@ XGBoost adopts the Apache style model and governs by merit. We believe that it i General Development Process --------------------------- -Everyone in the community is welcomed to send patches, documents, and propose new directions to the project. The key guideline here is to enable everyone in the community to get involved and participate the decision and development. When major changes are proposed, an RFC should be sent to allow discussion by the community. We encourage public discussion, archivable channels such as issues, discuss forum and mailing-list, so that everyone in the community can participate and review the process later. +Everyone in the community is welcomed to send patches, documents, and propose new directions to the project. The key guideline here is to enable everyone in the community to get involved and participate the decision and development. When major changes are proposed, an RFC should be sent to allow discussion by the community. We encourage public discussion, archivable channels such as issues and discuss forum, so that everyone in the community can participate and review the process later. Code reviews are one of the key ways to ensure the quality of the code. High-quality code reviews prevent technical debt for long-term and are crucial to the success of the project. A pull request needs to be reviewed before it gets merged. A committer who has the expertise of the corresponding area would moderate the pull request and the merge the code when it is ready. The corresponding committer could request multiple reviewers who are familiar with the area of the code. We encourage contributors to request code reviews themselves and help review each other's code -- remember everyone is volunteering their time to the community, high-quality code review itself costs as much as the actual code contribution, you could get your code quickly reviewed if you do others the same favor. @@ -25,7 +25,7 @@ Committers are individuals who are granted the write access to the project. A co - Quality of contributions: High-quality, readable code contributions indicated by pull requests that can be merged without a substantial code review. History of creating clean, maintainable code and including good test cases. Informative code reviews to help other contributors that adhere to a good standard. - Community involvement: active participation in the discussion forum, promote the projects via tutorials, talks and outreach. We encourage committers to collaborate broadly, e.g. do code reviews and discuss designs with community members that they do not interact physically. -The Project Management Committee(PMC) consists group of active committers that moderate the discussion, manage the project release, and proposes new committer/PMC members. Potential candidates are usually proposed via an internal discussion among PMCs, followed by a consensus approval, i.e. least 3 +1 votes, and no vetoes. Any veto must be accompanied by reasoning. PMCs should serve the community by upholding the community practices and guidelines TVM a better community for everyone. PMCs should strive to only nominate new candidates outside of their own organization. +The Project Management Committee(PMC) consists group of active committers that moderate the discussion, manage the project release, and proposes new committer/PMC members. Potential candidates are usually proposed via an internal discussion among PMCs, followed by a consensus approval, i.e. least 3 +1 votes, and no vetoes. Any veto must be accompanied by reasoning. PMCs should serve the community by upholding the community practices and guidelines XGBoost a better community for everyone. PMCs should strive to only nominate new candidates outside of their own organization. Reviewers diff --git a/doc/contrib/release.rst b/doc/contrib/release.rst index f0a64c29bd63..0ccd8ce7d8cf 100644 --- a/doc/contrib/release.rst +++ b/doc/contrib/release.rst @@ -10,6 +10,4 @@ Starting from XGBoost 1.0.0, each XGBoost release will be versioned as [MAJOR].[ * MAJOR: We gurantee the API compatibility across releases with the same major version umber. We expect to have a 1+ years development period for a new MAJOR release version. * FEATURE: We ship new features, improvements and bug fixes through feature releases. The cycle length of a feature is decided by the size of feature roadmap. The roadmap is decided right after the previous release. - - -MAINTENANCE: Maintenance releases will occur more frequently and depend on specific patches introduced (e.g. bug fixes) and their urgency. In general these releases are designed to patch bugs. However, higher level libraries may introduce small features, such as a new algorithm, provided they are entirely additive and isolated from existing code paths. Spark core may not introduce any features. +* MAINTENANCE: Maintenance version only contains bug fixes. This type of release only occurs when we found significant correctness and/or performance bugs and barrier for users to upgrade to a new version of XGBoost smoothly. From 12f78c7cf47218de774ea2ae30636c3724f452b6 Mon Sep 17 00:00:00 2001 From: Nan Zhu Date: Mon, 8 Jul 2019 07:02:39 -0700 Subject: [PATCH 3/3] update --- doc/contrib/release.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/contrib/release.rst b/doc/contrib/release.rst index 0ccd8ce7d8cf..7b198cf249b3 100644 --- a/doc/contrib/release.rst +++ b/doc/contrib/release.rst @@ -8,6 +8,6 @@ Versioning Policy Starting from XGBoost 1.0.0, each XGBoost release will be versioned as [MAJOR].[FEATURE].[MAINTENANCE] -* MAJOR: We gurantee the API compatibility across releases with the same major version umber. We expect to have a 1+ years development period for a new MAJOR release version. +* MAJOR: We gurantee the API compatibility across releases with the same major version number. We expect to have a 1+ years development period for a new MAJOR release version. * FEATURE: We ship new features, improvements and bug fixes through feature releases. The cycle length of a feature is decided by the size of feature roadmap. The roadmap is decided right after the previous release. * MAINTENANCE: Maintenance version only contains bug fixes. This type of release only occurs when we found significant correctness and/or performance bugs and barrier for users to upgrade to a new version of XGBoost smoothly.