From eacae04d6f121809bfd30cd7d2179e1e9c3dac10 Mon Sep 17 00:00:00 2001 From: Anatolii Kmetiuk Date: Fri, 26 Jan 2024 13:38:36 +0100 Subject: [PATCH] Following his resignation notice, remove Gabriele from the current SIP committee members. --- _sips/process-specification.md | 117 ++++++++++++++++----------------- 1 file changed, 58 insertions(+), 59 deletions(-) diff --git a/_sips/process-specification.md b/_sips/process-specification.md index a35aeaeef..8263fae13 100644 --- a/_sips/process-specification.md +++ b/_sips/process-specification.md @@ -4,14 +4,14 @@ title: Process Specification redirect_from: /sips/sip-submission.html --- -The Scala Improvement Process (sometimes called SIP process) is a process for +The Scala Improvement Process (sometimes called SIP process) is a process for submitting changes to the Scala language. This process aims to evolve Scala openly and collaboratively. -The SIP process covers the Scala language (syntax, type system and semantics) +The SIP process covers the Scala language (syntax, type system and semantics) and the core of the Scala standard library. The core is anything that is referenced from the language spec (such as primitive types or the definition -of `Seq`). The SIP process is not concerned with compiler changes that do not +of `Seq`). The SIP process is not concerned with compiler changes that do not affect the language (including but not limited to linting warnings, optimizations, quality of error messages). @@ -19,19 +19,19 @@ A proposed change requires a design document, called a Scala Improvement Proposal (SIP). The committee meets monthly to discuss, and eventually vote upon, proposals. -The committee follows the following process when evaluating SIP documents, +The committee follows the following process when evaluating SIP documents, from an idea to the inclusion in the language. ## Definitions - SIP (Scala Improvement Proposal): a particular proposal for changing the Scala language (additions, changes, and/or removals). -- Committee: a group of experienced Scala practitioners and language designers, +- Committee: a group of experienced Scala practitioners and language designers, who evaluate changes to the Scala programming language. It consists of a Secretary, a Chairperson, and Members. -- Chairperson: person in charge of executing the process. They organize and +- Chairperson: person in charge of executing the process. They organize and chair the meetings of the Committee, and generally make sure the process is - followed, but do not vote on proposals. The Chairperson is an appointed + followed, but do not vote on proposals. The Chairperson is an appointed employee of the Scala Center. - Committee Member: member of the Committee with voting rights. The Chairperson cannot be a Member at the same time. @@ -53,7 +53,7 @@ from an idea to the inclusion in the language. ## Stages -From being an idea to being part of the language, a SIP goes through several +From being an idea to being part of the language, a SIP goes through several Stages that indicate the "maturity" level of the SIP. The following table summarizes the intent of the various stages. @@ -102,49 +102,49 @@ summarizes the intent of the various stages. ### Pre-SIP Stage -To initiate a discussion, any individual opens a "Pre-SIP" post in the Scala -Contributors forum. The post should be in the +To initiate a discussion, any individual opens a "Pre-SIP" post in the Scala +Contributors forum. The post should be in the [Scala Improvement Process](https://contributors.scala-lang.org/c/sip/13) category, and its title should start with "Pre-SIP:". The purpose of the Pre-SIP post is to present an idea to the Scala community: a Pre-SIP should present a -problem that needs solving (i.e., motivate the changes) and present possible +problem that needs solving (i.e., motivate the changes) and present possible solutions with pros and cons. The community is encouraged to engage in the discussions by voicing support, comments and concerns. -During the Pre-SIP stage, the Committee is not required to be involved. -Committee Members and the Chairperson are expected to follow Pre-SIP +During the Pre-SIP stage, the Committee is not required to be involved. +Committee Members and the Chairperson are expected to follow Pre-SIP discussions, but not required to engage. -Once at least one month has passed and the author has built some community -support for their Pre-SIP, they can Submit a SIP for discussion by the +Once at least one month has passed and the author has built some community +support for their Pre-SIP, they can Submit a SIP for discussion by the Committee. "Community support" is loosely defined. It involves a mix of positive -comments, likes, etc. Generally, the Chairperson or a Committee member will post -a comment on the thread suggesting to submit a SIP when they see that a Pre-SIP +comments, likes, etc. Generally, the Chairperson or a Committee member will post +a comment on the thread suggesting to submit a SIP when they see that a Pre-SIP is ready to enter the process. ### Entry into the process (SIP Submission) -To submit a SIP, a SIP Author writes a pull request to the -[scala/improvement-proposals](https://github.com/scala/improvement-proposals) -repository, following the [tutorial]({% link _sips/sip-tutorial.md %}), and -pointing to the Pre-SIP discussion. If the proposal correctly follows the +To submit a SIP, a SIP Author writes a pull request to the +[scala/improvement-proposals](https://github.com/scala/improvement-proposals) +repository, following the [tutorial]({% link _sips/sip-tutorial.md %}), and +pointing to the Pre-SIP discussion. If the proposal correctly follows the template, and the Pre-SIP discussion seems to show some community support, the Chairperson will accept the SIP for review, assign a SIP number, assign 3 reviewers to the SIP among the Committee Members, and assign one of the reviewers to be the Manager of that SIP. Since "community support" is loosely defined, any Committee Member can also comment on the PR to accept the -SIP for review (this is meant mostly as an escape hatch to prevent the -Chairperson from unilaterally blocking a SIP from entering the process). From +SIP for review (this is meant mostly as an escape hatch to prevent the +Chairperson from unilaterally blocking a SIP from entering the process). From that point onwards, the SIP has entered the Design Stage. If the template has not been correctly followed, or if none of the Committee -Members nor the Chairperson think that the Pre-SIP has gathered enough support, +Members nor the Chairperson think that the Pre-SIP has gathered enough support, the PR may be closed after 2 weeks. ### PR states and GitHub labels -As soon as a SIP PR is opened, the GitHub labels `stage:pre-sip` and -`status:submitted` are applied to it. At any given moment, a SIP PR will have as +As soon as a SIP PR is opened, the GitHub labels `stage:pre-sip` and +`status:submitted` are applied to it. At any given moment, a SIP PR will have as labels one of the following possibilities: | | | | @@ -167,21 +167,21 @@ labels one of the following possibilities: Once a SIP has entered the Design Stage, the assigned reviewers will review (as a GitHub Review on the SIP PR) the proposal within 3 weeks. The authors may then address the concerns by pushing additional commits and ask for a new review. -This phase is iterative, like any pull request to an implementation repository. -After each request for a new review, the reviewers have 3 weeks to do another +This phase is iterative, like any pull request to an implementation repository. +After each request for a new review, the reviewers have 3 weeks to do another round. -When the reviewers are confident that the SIP is in good shape to be discussed -with the full Committee, the Manager sets its status to "Vote Requested" and decide on a -Vote Recommendation that they will bring to the Committee. A Vote Recommendation +When the reviewers are confident that the SIP is in good shape to be discussed +with the full Committee, the Manager sets its status to "Vote Requested" and decide on a +Vote Recommendation that they will bring to the Committee. A Vote Recommendation is either "Recommend Accept" or "Recommend Reject". The proposal is then -scheduled on the agenda of the next Committee meeting (which happens once a +scheduled on the agenda of the next Committee meeting (which happens once a month). At any time, the SIP Author may voluntarily Withdraw their SIP, in which case it exits the process. It is possible for someone else (or the same person) to -become the new SIP Author for that SIP, and therefore bring it back to the -process. If a SIP Author does not follow up on Reviewers' comments for 2 months, +become the new SIP Author for that SIP, and therefore bring it back to the +process. If a SIP Author does not follow up on Reviewers' comments for 2 months, the SIP will automatically be considered to be Withdrawn. ### Design Stage -- Vote @@ -194,11 +194,11 @@ the Implementation Stage. There are three possible outcomes: - Accept for implementation: the proposal then advances to the Implementation Stage, and therefore becomes a formal recommendation to be implemented as an Experimental feature into the compiler. -- Reject: the proposal is rejected and the PR closed. It exits the process at - this point. The reviewers will communicate on the PR the reason(s) for the +- Reject: the proposal is rejected and the PR closed. It exits the process at + this point. The reviewers will communicate on the PR the reason(s) for the rejection. -- Keep: the proposal remains in the Design Stage for further iterations. The - reviewers will communicate on the PR the current concerns raised by the +- Keep: the proposal remains in the Design Stage for further iterations. The + reviewers will communicate on the PR the current concerns raised by the Committee. In order to be accepted for implementation and advance to the next stage, a SIP @@ -207,7 +207,7 @@ must gather strictly more than 50% of "Advance" votes among the whole Committee. For instance, if the Committee is made of 11 members, at least 6 members have to vote "Advance" for the SIP to move to the next stage. If there was a strict majority in favor of "Advance", the PR for the SIP is Merged at this point by its Manager. -Otherwise, a second vote between +Otherwise, a second vote between Reject and Keep will be used. A proposal needs more than 50% "Reject" votes to be rejected in that case. Otherwise, it is kept. @@ -231,10 +231,10 @@ An implementation will be reviewed by the compiler team, and once the implementation is deemed good enough, it can ship as an Experimental feature in the next release of the compiler where it's practical to do so. At that point, the SIP Manager posts a follow-up comment on the Pre-SIP discussion to invite the community to test the feature and provide feedback. -The implementers may hit challenges that were not foreseen by the Committee. -Early users may also provide feedback based on practical experience with the -Experimental feature. This feedback can be sent back to the Committee by -implementers. This is done with a PR to the SIP repository, amending the +The implementers may hit challenges that were not foreseen by the Committee. +Early users may also provide feedback based on practical experience with the +Experimental feature. This feedback can be sent back to the Committee by +implementers. This is done with a PR to the SIP repository, amending the previously merged SIP document or raising questions for challenges. In that case, the SIP Author and Reviewers will work together with the implementers to address the feedback. This is again an iterative process. Reviewers may merge @@ -249,10 +249,10 @@ rejected, with the same rules as in the "Design Stage -- Vote" section. ### Completed Stage -Once a SIP is accepted for shipping, it will be enabled by default (as +Once a SIP is accepted for shipping, it will be enabled by default (as non-Experimental) in the next practical Minor release of the language. -From this point onwards, the feature is stable and cannot be changed anymore. +From this point onwards, the feature is stable and cannot be changed anymore. Any further changes would have to come as an entirely new SIP. ## The SIP Committee @@ -261,7 +261,6 @@ The current committee members are: - Björn Regnell ([@bjornregnell](https://github.com/bjornregnell)), Lund University - Chris Andrews ([@chrisandrews-ms](https://github.com/chrisandrews-ms)), Morgan Stanley -- Gabriele Petronella ([@gabro](https://github.com/gabro)), buildo - Guillaume Martres ([@smarter](https://github.com/smarter)), EPFL - Haoyi Li ([@lihaoyi](https://github.com/lihaoyi)), Databricks - Lukas Rytz ([@lrytz](https://github.com/lrytz)), Lightbend @@ -280,16 +279,16 @@ The current Secretary is: ### Committee Meetings -The plenary Committee Meetings are scheduled monthly by the Chairperson. They +The plenary Committee Meetings are scheduled monthly by the Chairperson. They have the following purposes: - Vote to accept, keep or reject SIPs that are in a "Vote Requested" state -- Be aware of the list of SIPs that are "Under review". If a SIP stays too long - under review, Committee Members may request for it to be put to discussion +- Be aware of the list of SIPs that are "Under review". If a SIP stays too long + under review, Committee Members may request for it to be put to discussion and/or vote in a subsequent plenary meeting, even if the Reviewers do not - think it is ready. This is meant primarily as an escape hatch, preventing + think it is ready. This is meant primarily as an escape hatch, preventing Reviewers from blocking a SIP by infinitely stalling it. -- Make any exception to the process that they judge necessary to unblock a +- Make any exception to the process that they judge necessary to unblock a situation. If a Committee Member cannot attend a meeting, they are welcome to share their feedback about the proposals listed in the agenda of the meeting with the Chairperson, who will relate it during the meeting. A Committee Member cannot give their voting power to someone else. If a Committee Member misses more than 2 meetings within a year, they lose their seat. @@ -313,18 +312,18 @@ the current state of the proposal, both its design and implementation. ### On what basis are proposals evaluated? -The Committee ultimately decides how to evaluate proposals, and on what grounds. -The Committee does not need to justify its decisions, although it is highly +The Committee ultimately decides how to evaluate proposals, and on what grounds. +The Committee does not need to justify its decisions, although it is highly encouraged to provide reasons. -Nevertheless, here is a non-exhaustive list of things that the Reviewers and +Nevertheless, here is a non-exhaustive list of things that the Reviewers and Committee are encouraged to take into account: - The proposal follows the "spirit" of Scala - The proposal is well motivated; it solves a recurring problem -- The proposal evaluates the pros and cons of its solution; the solution put +- The proposal evaluates the pros and cons of its solution; the solution put forward is believed to be the best one -- The proposal can be implemented in a way that does not break backward binary +- The proposal can be implemented in a way that does not break backward binary nor TASTy compatibility - The proposal makes an effort not to break backward source compatibility - The proposal does not change the meaning of existing programs @@ -332,9 +331,9 @@ Committee are encouraged to take into account: ## Exceptions and changes -The present document tries to account for most situations that could occur in -the lifetime of SIPs. However, it does not pretend to be an ultimate solution to -all cases. At any time, the Committee can decide, by consensus, to make +The present document tries to account for most situations that could occur in +the lifetime of SIPs. However, it does not pretend to be an ultimate solution to +all cases. At any time, the Committee can decide, by consensus, to make exceptions to the process, or to refine the process. ## How do I submit?