Consolidate the discussion avenues for ZEPs, minor formatting, and add a page for ZIC

Author: sanketverma1704

active/ZEP0000.md

@@ -54,15 +54,15 @@ 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
@@ -80,14 +80,14 @@ 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
@@ -130,16 +130,17 @@ 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.
+After the PR for the ZEP is in place, an issue should be created in the [ZEPs]
+repository, 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_implementations].
 
 ### Submitting a ZEP
 
@@ -156,7 +157,7 @@ The second PR should contain actual changes and should be submitted in the
 four-digit ZEP number from the zarr-developers/zep 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
+GitHub pull request to the [zarr-developers/zep] 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.
@@ -177,13 +178,10 @@ or not taking care of Zarr [CODE OF CONDUCT].
 
 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 discussion regarding the ZEP should follow Zarr’s [CODE OF CONDUCT] at all
-times.
+discuss and review its contents. The ZEP author(s) may create an issue in
+[ZEPs] repository and or similarly create an issue in [zarr-specs] repository
+for specifications ZEPs. The discussion regarding the ZEP should follow Zarr’s
+[CODE OF CONDUCT] at all times.
 
 ZEP authors are responsible for collecting community feedback on a ZEP.
 However, to avoid long-winded and open-ended discussions, strategies such as
@@ -255,13 +253,13 @@ original and new ZEPs respectively. Process ZEPs may also have a status of
 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
+[Zarr 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
@@ -286,26 +284,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/zep]
+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;
 
-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,7 +317,7 @@ 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.
+GitHub or, if needed, creating an additional issue 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.
@@ -335,10 +332,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/zep] 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
@@ -404,7 +401,7 @@ This document has been placed in the public domain.
 <!-- 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
@@ -413,3 +410,4 @@ This document has been placed in the public domain.
 [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/zep]: https://github.com/zarr-developers/zeps

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/
 ---

zarr-implementations-council.markdown

@@ -0,0 +1,42 @@
+---
+layout: default
+title: implementations council
+description: Representatives of various Zarr Implementations
+nav_order: 4
+permalink: /zic/
+---
+
+# Zarr Implementation Council 🚀
+
+The [ZSC](https://github.com/zarr-developers/governance/blob/main/GOVERNANCE.md#zarr-steering-council) have invited Zarr Implementations to participate in the management of the Zarr specification through the Zarr Implementation Council (ZIC). Implementations are selected based on the maturity of implementation as well as the activity of the developer community. Preference will be given to open-source and *open-process* implementations. Multiple implementations in a single programming language may be invited, or such implementations could work together as a single community.
+
+The current list of implementations which are participating in this process are (in alphabetical order):
+
+- [constantinpape/z5](https://github.com/constantinpape/z5) represented by [Constantin Pape](https://github.com/constantinpape) ([May 2022 – present](https://github.com/zarr-developers/governance/issues/26))
+
+- [google/tensorstore](https://github.com/google/tensorstore) represented by [Jeremy Maitin-Shepard](https://github.com/jbms) ([May 2022 – present](https://github.com/zarr-developers/governance/issues/22))
+
+- [freeman-lab/zarr-js](https://github.com/freeman-lab/zarr-js) represented by [Jeremy Freeman](https://github.com/freeman-lab) ([May 2022 – present](https://github.com/zarr-developers/governance/issues/27))
+
+- [gzuidhof/zarr.js](https://github.com/gzuidhof/zarr.js) represented by [Trevor Manz](https://github.com/manzt) ([May 2022 – present](https://github.com/zarr-developers/governance/issues/28))
+
+- [JuliaIO/Zarr.jl](https://github.com/JuliaIO/Zarr.jl) represented by [Fabian Gans](https://github.com/meggart) ([May 2022 – present](https://github.com/zarr-developers/governance/issues/18))
+
+- [saalfeldlab/n5-zarr](https://github.com/saalfeldlab/n5-zarr) represented by [Stephan Saalfeld](https://github.com/axtimwalde) ([May 2022 – present](https://github.com/zarr-developers/governance/issues/25))
+
+- [sci-rs/zarr](https://github.com/sci-rs/zarr) represented by [Andrew Champion](https://github.com/aschampion) ([May 2022 - present](https://github.com/zarr-developers/governance/issues/20))
+
+- [Unidata/netcdf-c](https://github.com/Unidata/netcdf-c) and [Unidata/netcdf-java](https://github.com/Unidata/netcdf-java) represented by [Ward Fisher](https://github.com/wardf) ([May 2022 - present](https://github.com/zarr-developers/governance/issues/21))
+
+- [xtensor-stack/xtensor-zarr](https://github.com/xtensor-stack/xtensor-zarr) represented by [David Brochart](https://github.com/davidbrochart) ([May 2022 - present](https://github.com/zarr-developers/governance/issues/23))
+
+- [zarr-developers/zarr-python](https://github.com/zarr-developers/zarr-python) represented by [Gregory Lee](https://github.com/grlee77) ([May 2022 - present](https://github.com/zarr-developers/governance/issues/19))
+
+
+The core developers of each implementation have selected a representative of the ZIC. It is up to each implementation to determine its process for selecting its representatives.
+
+This member will represent that implementation in decisions regarding the Zarr Specification and other Zarr-wide contexts which require input from implementations.
+
+An additional representative should also be selected to act as an alternate when the primary representative is unavailable.
+
+Continued ZIC membership depends on timely feedback and votes on relevant issues. The ZSC also reserves the right to remove implementations from the council.