Minor changes to ZEP0000 and add a new page for ZIC

active/ZEP0000.md

@@ -10,16 +10,20 @@ parent: active ZEPs
 nav_order: 1
 ---
 
-## ZEP 0 — Purpose and process
+# ZEP 0 — Purpose and process
 
-Author: Sanket Verma <svsanketverma5@gmail.com>
+Author: Sanket Verma [(@MSanKeys963)](https://github.com/msankeys963), Zarr
+
+Email address: <svsanketverma5@gmail.com>
 
 Status: Active
 
 Type: Process
 
 Created: 2022-14-03
 
+Discussion: <https://github.com/zarr-developers/governance/pull/16>
+
 ## What is ZEP?
 
 ZEP stands for Zarr Enhancement Proposal. A ZEP is a design document providing
@@ -54,40 +58,40 @@ that require collaboration across multiple projects.
 
 ## ZEP types
 
-- Specification ZEP
+- **Specification ZEP**
 
 Specification ZEPs deal with the changes related to [Zarr Specifications].
 The SPEC ZEP (abbreviation of Specification ZEP) for now introduces changes in
 the core specification of Zarr. The changes related to core specification follow a
 strict and thorough review process and should be adopted by everyone in the
 Zarr community.
 
-- Core protocol ZEP
+- **Core protocol ZEP**
 
 Describes a ZEP which involves changes in the core specification of Zarr. Core
-protocol ZEPs (commonly known as Core ZEPs) are a part of SPEC ZEPs and apply to
-[Zarr Specifications] and its various implementations under the
-[zarr_implementations] GitHub repo. The core protocol ZEPs should be adopted by
-every implementation of Zarr and, in general, the overall Zarr community. Core
-ZEPs must go through a thorough review process, including involvement,
-discussion, and voting from the author of the proposed ZEP, Zarr Steering
-Council, author(s) of various Zarr implementations, and open-source
-projects/research groups using Zarr and the general Zarr community. The general
-advice is that everyone should be made aware of changes introduced by core
-ZEPs. Core protocol ZEPs require community consensus, and developers or users
-are typically not free to ignore them.
+protocol ZEPs (commonly known as Core ZEPs) are a part of SPEC ZEPs and apply
+to [Zarr Specifications] and its various implementations under the
+[zarr-developers/zarr_implementations] GitHub repo. The core protocol ZEPs
+should be adopted by every implementation of Zarr and, in general, the overall
+Zarr community. Core ZEPs must go through a thorough review process, including
+involvement, discussion, and voting from the author of the proposed ZEP, Zarr
+Steering Council, author(s) of various Zarr implementations (ZIC), and
+open-source projects/research groups using Zarr and the general Zarr community.
+The general advice is that everyone should be made aware of changes introduced
+by core ZEPs. Core protocol ZEPs require community consensus, and developers or
+users are typically not free to ignore them.
 
 Note: Currently, Specification ZEPs only deal with the core specification of Zarr.
 The scope of SPEC ZEPs will be extended in the future.
 
-- Informational ZEP
+- **Informational ZEP**
 
 Describes a ZEP design issue or provides general guidelines or information to
 the Zarr community but does not propose a new feature. Informational ZEPs do
 not necessarily represent Zarr community consensus or recommendation, so users
 and implementers are free to ignore informational ZEPS or follow their advice.
 
-- Process ZEP
+- **Process ZEP**
 
 Describes a new process around Zarr and its implementations or proposes a
 change to (or an event in) a process. They may propose an implementation, but
@@ -100,19 +104,22 @@ is also considered a Process ZEP.
 
 ## ZEP Workflow
 
-The ZEP process begins with a new idea for Zarr. It is highly recommended that
-a single ZEP contain a single key proposal or new idea. Small enhancements or
+The ZEP process begins with a new idea for Zarr. It is highly recommended that a
+single ZEP contain a single key proposal or new idea. Small enhancements or
 patches often don’t need a ZEP and can be injected into the Zarr development
-workflow with a pull request to the Zarr ZEP repo. The more focused the ZEP,
-the more successful it tends to be. If in doubt, split your ZEP into several
-well-focused ones.
+workflow with a pull request to the [ZEPs] or [zarr-specs] repo. The more
+focused the ZEP, the more successful it tends to be. If in doubt, split your
+ZEP into several well-focused ones.
 
 Each ZEP must have a champion -- someone who writes the ZEP using the style and
 format described below, shepherds the discussions in the appropriate forums,
 and attempts to build community consensus around the idea. The ZEP champion
 (a.k.a. Author) should first attempt to ascertain whether the idea is suitable
-for a ZEP. Posting to [Gitter] or creating an issue on the [community] repository
-or posting on the organization [discussions] are the best ways to go about doing this.
+for a ZEP.
+
+**Asking around during the [ZEPs meetings]/creating an issue in the
+[ZEPs] repository/posting to [Gitter]/posting on the organization [discussions]
+are the best ways to do this.**
 
 The ZEP champion is the lead author of the ZEP. A ZEP should have a lead
 author and can have multiple co-author(s).
@@ -130,33 +137,29 @@ mentioned below. This allows the author to flesh out the draft ZEP to make it
 properly formatted, of high quality, and address initial concerns about the
 proposal.
 
-After the PR for the ZEP is in place, a post should be made on the GitHub
-organisation [discussions], containing the sections up to “Backward
-compatibility” to limit discussion there to usage and impact. Discussion on the
-pull request will have a broader scope, including details of implementation.
-
 Spec ZEPs consist of two parts, a PR to the [zarr-specs] repository containing
-changes to the spec and a narrative document explaining the need, importance and
-use-case for the change. It is also highly recommended that the specification
-ZEP be accompanied by an implementation PR in at least one of the repositories
-represented in the [zarr_implementations].
+changes to the spec and a PR to the [ZEPs] repository containing a narrative
+document explaining the need, importance and use-case for the change. It is
+also highly recommended that the specification ZEP be accompanied by an
+implementation PR in at least one of the repositories represented in the
+[zarr-developers/zarr_implementations].
 
-### Submitting a ZEP
+## Submitting a ZEP
 
-For Spec ZEPs, the proposal should be submitted as a draft ZEP via two GitHub
+For SPEC ZEPs, the proposal should be submitted as a draft ZEP via two GitHub
 pull requests, one to the [ZEPs] repo and the other to the [zarr-specs] repository.
 
 The first PR should contain the narrative text of the ZEP and should be
-submitted in the zep repository with the name `zep-<n>.md` under /zeps/draft/
+submitted in the zep repository with the name `zep-<n>.md` under [/zeps/draft/]
 where `<n>` is an appropriately assigned four-digit number. The draft ZEP must
 use the [ZEP X - Template and Instructions][template.md] file.
 
 The second PR should contain actual changes and should be submitted in the
-[zarr-specs] repository. That PR repository should mention the assigned
-four-digit ZEP number from the zarr-developers/zep repository.
+[zarr-specs] repository. The PR should mention the assigned four-digit ZEP
+number from the [zarr-developers/zeps] repository.
 
-For ZEPs other than spec, the proposal should be submitted as a draft ZEP via a
-GitHub pull request to the zarr-developers/zep repository with the name
+For ZEPs other than SPEC, the proposal should be submitted as a draft ZEP via a
+GitHub pull request to the [zarr-developers/zeps] repository with the name
 `zep-<n>.md` where `<n>` is an appropriately assigned four-digit number (e.g.,
 zep-0000.md). The draft ZEP must use the
 [ZEP X - Template and Instructions][template.md] file.
@@ -167,21 +170,26 @@ A few points to consider while submitting your ZEP:
 - The title should accurately describe the content.
 - The ZEP’s language (spelling, grammar, sentence structure etc.) and code style should be correct and conformant.
 
-The [Zarr Steering Council]
-and the Zarr Implementations Council will not unreasonably deny publication of
-a ZEP. Reasons for denying ZEP include duplication of effort, being technically
-unsound, not providing proper motivation or addressing backwards compatibility,
-or not taking care of Zarr [CODE OF CONDUCT].
-
-### Discussing a ZEP
-
-As soon as the draft ZEP is committed to the ZEP repository, the author(s)
-should create a discussion thread for the ZEP to provide a central place to
-discuss and review its contents. The ZEP author(s) may select the GitHub
-discussion feature in the organisation [discussions] or the ZEP repository and
-similarly use the discussion feature in the [zarr-specs] repository for
-specification ZEPs. Alternatively, the author(s) may open a new issue in the
-Zarr [community] repository or start the discussion in the Zarr [Gitter] channel.
+The [Zarr Steering Council] and the [Zarr Implementations Council] will not
+unreasonably deny publication of a ZEP. Reasons for denying ZEP include
+duplication of effort, being technically unsound, not providing proper
+motivation or addressing backwards compatibility, or not taking care of Zarr
+[CODE OF CONDUCT].
+
+→ **In conclusion: The submission of SPEC ZEPs needs two PRs, and other ZEPs need one PR.**
+
+## Discussing a ZEP
+
+As soon as the draft ZEP is committed to the ZEP repository, the author
+(s) should create a discussion thread for the ZEP to provide a central place to
+discuss and review its contents. The ZEP author(s) may create an issue in
+[ZEPs] repository for informational and process ZEPs and or similarly create an
+issue in [zarr-specs] repository for specifications ZEPs. 
+
+If the author prefers to hold the discussion for SPEC ZEPs in the second PR
+submitted in the [zarr-specs] repository (as mentioned above), there's no need
+to create an issue.
+
 The discussion regarding the ZEP should follow Zarr’s [CODE OF CONDUCT] at all
 times.
 
@@ -199,7 +207,7 @@ avoids fragmenting the discussion, and makes sure it is fully considered as
 part of the ZEP review process. Comments, support, concerns and other feedback
 on this designated thread are a critical part when reviewing the ZEP.
 
-### Review and Resolution
+## Review and Resolution
 
 The possible paths of the status of ZEPs are as follows:
 
@@ -211,10 +219,14 @@ Eventually, after the discussion, there may be a consensus that the ZEP should
 be accepted - see the next section for details. At this point, the status
 becomes `Accepted`.
 
-Once a Specification ZEP has been Accepted, the second PR which was submitted in
+**Once a Specification ZEP has been Accepted**, the second PR which was submitted in
 the [zarr-specs] repository must be merged. After that, the status will be
 changed to `Final`.
 
+**Once an informational or process ZEP has been Accepted**, the author should
+implement changes in the procedure, guidelines, decision-making process, etc.
+ASAP.
+
 To allow the gathering of additional design and interface feedback before
 committing to long term stability for specification change or standard library
 API, ZEP may also be marked as `“Provisional”`. This is short for
@@ -250,25 +262,26 @@ obsolete. The `Replaced-By` and `Replaces` headers should be added to the
 original and new ZEPs respectively. Process ZEPs may also have a status of
 `Active` if they are never meant to be completed, e.g. ZEP 0 (this ZEP).
 
-### How does a ZEP become accepted?
+## How does a ZEP become accepted?
 
 A ZEP is `Accepted` by the consensus of all interested contributors. We need a
 concrete way to tell whether the agreement has been reached. 
 
-> For Core ZEPs:
+→ **For Core ZEPs**
 
 We believe Core ZEPs are of utmost importance and should follow a thorough
 review before acceptance. Core ZEPs introduce changes in the core
 specification, which are necessary for every other implementation and everyone
-in the general community to follow. The [Zarr Steering Council] and
-Implementations Council closely review the Core ZEPs, while the author(s) should
-simultaneously engage the community in their ZEP at several discussion forums
-mentioned previously. The ZSC and ZIC would take community consensus into account
-while taking the final decision on the Core ZEPs. Author(s) should ensure that
-the involvement and discussion form the consensus on the ZEP from the author of
-various Zarr implementations, open-source projects/research groups using Zarr,
-the general Zarr community, and anyone else they, ZSC and ZIC think should be
-included in the discussions. The Core ZEPs are accepted by:
+in the general community to follow. The [Zarr Steering Council] (ZSC) and
+[Zarr Implementations Council] (ZIC) closely review the Core ZEPs, while the
+author(s) should simultaneously engage the community in their ZEP at several
+discussion forums mentioned previously. The ZSC and ZIC would take community
+consensus into account while taking the final decision on the Core ZEPs. Author
+(s) should ensure that the involvement and discussion form the consensus on the
+ZEP from the author of various Zarr implementations, open-source
+projects/research groups using Zarr, the general Zarr community, and anyone
+else they, ZSC and ZIC think should be included in the discussions. The Core
+ZEPs are accepted by:
 
 - Unanimous approval of the [Zarr Steering Council]
 
@@ -286,26 +299,25 @@ included in the discussions. The Core ZEPs are accepted by:
 Read more about [Zarr Implementations Council].
 
 
-> For other ZEPs
+→ **For other ZEPs**
 
 For ZEPs, other than specifications, the author(s) must form a consensus around
 their proposal. They may refer to [Discussing a ZEP]( #discussing-a-zep ) section to pick an avenue
 for discussion and engaging the community.
 
-When you think ZEP is ready to accept, create a new discussion in [zarr-specs]
-for Specifications ZEPs using ‘General’ and in zarr-developers/zep for other
-ZEPs and as the category with a subject like:
+**When you think ZEP is ready to accept**, create a new issue in [zarr-developers/zeps]
+with a subject like:
 
 > `Proposal to accept ZEP <number>: <title>`
 
-In the body of your discussion, you should:
+**In the body of your discussion**, you should:
 
 - Link to the latest version of ZEP,
 - Briefly describe any major points of contention and how they were resolved,
-- Include a sentence like: “If there are no substantive objections within 7 days
-  from this post, then the ZEP will be accepted;
+- Include a sentence like: **“If there are no substantive objections within 7 days
+  from this post, then the ZEP will be accepted**;
 
-After you create the discussion, you should make sure to link the newly created
+After you create the issue, you should make sure to link the newly created
 thread in the `Discussion` section of the ZEP, so that people can find it later.
 
 Generally, the ZEP author will be the one to create this post, but anyone can
@@ -320,10 +332,10 @@ There may be a case that a ZEP didn’t attract needed attention towards it, the
 engagement from the community is low, and `7 days` pass by. In this case,
 the author(s) of the ZEP must make necessary efforts to spread the word about
 the ZEP through [Gitter] or using the organisation [discussions] feature of
-GitHub or, if needed, creating an additional PR in the [community] repository.
-In addition, the author(s) should get in touch with the [Zarr Steering Council]
-to prevent the case that the ZEP was accepted due to less participation from the
-community.
+GitHub or, if needed, creating an additional issue in the [community] or [ZEPs]
+repository. In addition, the author(s) should get in touch with the
+[Zarr Steering Council] to prevent the case that the ZEP was accepted due to
+less participation from the community.
 
 If all the above options are exhausted by the author(s), then it’s the
 responsibility of the [Zarr Steering Council] to take the final decision on the
@@ -335,10 +347,10 @@ side of asking for more feedback and looking for opportunities to compromise.
 
 If the final comment period passes without any substantive objections, then the
 ZEP can officially be marked `Accepted`. You should create a follow-up
-discussion thread in zarr-developers/zep repository notifying everyone
+issue in [zarr-developers/zeps] repository notifying everyone
 (celebratory emoji optional but encouraged 🎉✨), and then update the ZEP by
 setting its `:Status:` to `Accepted`, and it's `:Resolution:` header to a link
-to your follow-up discussion thread.
+to your follow-up discussion (the last issue created) thread.
 
 If there are substantive objections, then the ZEP remains in `Draft` state,
 discussion continues as normal, and it can be proposed for acceptance again
@@ -347,7 +359,7 @@ later once the objections are resolved.
 In unusual cases, the [Zarr Steering Council] may be asked to decide whether a
 controversial ZEP is `Accepted`.
 
-### Maintenance
+## Maintenance
 
 In general, SPEC ZEPs are no longer modified after they have reached the Final
 state. The changes made to the Zarr’s core specification in the
@@ -364,7 +376,7 @@ ZEPs are UTF-8 encoded text files using the [GitHub flavoured markdown] format.
 Please see the [ZEP X - Template and Instructions][template.md] file and the
 [GitHub Markdown Spec] for more information.
 
-### Header Preamble
+## Header Preamble
 
 ```
 Author: <list of authors’ real names and email addresses>
@@ -400,16 +412,19 @@ This document has been placed in the public domain.
 [GitHub flavoured markdown]: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax
 [GitHub Markdown Spec]: https://github.github.com/gfm/
 [template.md]: https://zarr.dev/zeps/template/template.html
+[ZEPs meetings]: https://zarr.dev/zeps/meetings/
 
 <!-- governance specific links -->
 [CODE OF CONDUCT]: https://github.com/zarr-developers/.github/blob/main/CODE_OF_CONDUCT.md
 [Zarr Steering Council]: https://github.com/zarr-developers/governance/blob/main/GOVERNANCE.md#zarr-steering-council
-[Zarr Implementations Council]: https://github.com/zarr-developers/governance/blob/main/GOVERNANCE.md#zarr-implementation-council-zic
+[Zarr Implementations Council]: https://zarr.dev/zeps/zic/
 
 <!-- github links: capitalization matches that of the repo -->
 [community]: https://github.com/zarr-developers/community
 [discussions]: https://github.com/orgs/zarr-developers/discussions
-[zarr_implementations]: https://github.com/zarr-developers/zarr_implementations
+[zarr-developers/zarr_implementations]: https://github.com/zarr-developers/zarr_implementations
 [zarr-specs]: https://github.com/zarr-developers/zarr-specs
 [ZEPs]: https://github.com/zarr-developers/zeps
 [https://github.com/zarr-developers/governance/pull/16]: https://github.com/zarr-developers/governance/pull/16
+[zarr-developers/zeps]: https://github.com/zarr-developers/zeps
+[/zeps/draft/]: https://github.com/zarr-developers/zeps/tree/main/draft

join-community.markdown

@@ -1,5 +1,5 @@
 ---
-layout: page
+layout: default
 title: join the community
 permalink: /join-community/
 ---

meetings/meetings.md

@@ -2,7 +2,7 @@
 layout: default
 title: ZEP meetings
 description: Information about bi-weekly ZEP meetings
-nav_order: 4
+nav_order: 5
 has_children: true
 permalink: /meetings/
 ---