You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iceberg.apache.org by Jack Ye <ye...@gmail.com> on 2024/06/25 16:00:39 UTC
[Discussion] Apache Iceberg Community Guideline - Initial Version
Hi everyone,
Thanks for the feedback in the bylaws document discussion thread! As
suggested, I have removed all the topics that require further debates, and
created this new doc to serve as the initial version that we can review and
later vote.
https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit
I will organize new devlist threads to discuss other topics to amend the
guidelines step by step, once this initial version is in.
A few additional changes that I have already incorporated:
1. modified the name from "bylaws" to "community guidelines", following the
latest ASF guideline
2. renamed "lazy majority" and "lazy 2/3 majority" to "majority approval"
and "2/3 majority approval"
3. changed "Propose Removing Committer", "Propose Removing PMC Member" to
consensus approval, and added "Propose PMC Chair Change" decision following
the default Apache project community guidelines.
4. changed "Release Product" voting period to 5 days instead of 3 days
excluding weekends.
5. clarified the copyright of code in Apache Iceberg codebases
The most important thing is probably to agree upon the 2/3 majority
approval for modifying the project guidelines, so we can have a consistent
voting method going forward. This initial introduction of the bylaws will
be voted using consensus approval.
Please take a look and comment about any additional changes needed, and I
will host a vote in 3 days.
Best,
Jack Ye
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Jack,
I don't think we are ready for a vote already: the document has still
comments to be discussed imho.
I would give more time to everyone to take a look.
Generally speaking, if I understand the overall idea, I see a lot of
content similar to the ASF resources (so maybe just referencing the
ASF resources/links would be enough).
Also, I think we should emphasize the problem statement, because it
could be hard to see the values of some document proposals.
My $0.01 :)
Regards
JB
On Mon, Jul 1, 2024 at 4:01 PM Jack Ye <ye...@gmail.com> wrote:
>
> Hi everyone,
>
> Thanks for all the comments and feedback on the document, I am working with a few commenters on some additional changes and wording, and then will carry out the vote.
>
> Best,
> Jack Ye
>
> On Thu, Jun 27, 2024 at 11:02 AM Jack Ye <ye...@gmail.com> wrote:
>>
>> To provide an update here, I have consolidated most of the comments in the initial version, with the following changes:
>>
>> (1) condensed the section of roles and responsibilities, with pointers to different pages in ASF and existing Iceberg project pages.
>>
>> (2) clarified voting details, regrading things like partial votes, difference of voting on mailing lists vs voting on GitHub PRs
>>
>> (3) clarified the section regarding lazy consensus. There is a definition difference between the ASF definition (no +1 vote needed) vs the ORC definition (1 +1 vote). I renamed the ORC version as "minimum consensus" instead.
>>
>> (4) updated "Modify Code" vote type to minimum consensus. This is a bit different from ASF definition for code modification, but I think we are coming to an agreement that the ASF definition is outdated. Minimum consensus seems to make the most sense given the way we operate Iceberg so far, which is basically at least 1 committer other than the author needs to approve a PR before merging.
>>
>> (5) updated all decisions regarding committers and PMC members and guideline updates to majority approval, following the ASF guideline on voting for procedural issues.
>>
>> Let me know if there is anything else we see major disagreements with, and I will organize a vote after 24 hours.
>>
>> Best,
>> Jack Ye
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jun 26, 2024 at 11:04 AM Jack Ye <ye...@gmail.com> wrote:
>>>
>>> +1 for adding to the site.
>>>
>>> I am putting it as a doc for now since Google doc is easier to comment (I think?). My plan is to:
>>>
>>> (1) publish it as a PR after a vote has passed. We can do one more sanity check in the PR, but the information will be exactly as it is presented in the Google doc, maybe adding some additional links to more easily jump among the sections or to other pages in the site, fix some grammar issues that were overlooked.
>>>
>>> (2) keep a changelog within the document itself. Because we have moved the site multiple times in the past, I am not really confident that we could just track history with Git commit history, especially with such an important document. I would like to add a changelog section in the end, documenting what change has been approved when, with links to devlist discussions and votes.
>>>
>>> For how we tackle the other topics, my plan is to pass the initial version first, and then we just go through all the identified topics one by one. I have a list of all topics in the original feedback collection devlist thread.
>>>
>>> Let me know what you think about these plans!
>>>
>>> Best,
>>> Jack Ye
>>>
>>>
>>>
>>> On Wed, Jun 26, 2024 at 9:04 AM Ryan Blue <bl...@databricks.com.invalid> wrote:
>>>>
>>>> +1 for adding this to the site once we agree on the changes.
>>>>
>>>> One thing that has been raised several times but hasn't yet been addressed is how we want to tackle this. Many of us have asked to review the additional bylaws individually and discuss the purpose and merits of each one. It's great to have an overall doc (much like our integrated PRs to give context) but I think we should start having separate discussions about the rationale for each bylaw to make progress.
>>>>
>>>> Ryan
>>>>
>>>> On Wed, Jun 26, 2024 at 8:57 AM Micah Kornfield <em...@gmail.com> wrote:
>>>>>
>>>>> Hi Jack,
>>>>> I think it would make sense to convert this to a PR, so it can be version tracked in the future (and that way it avoids another review if the intent is to transitition github)?
>>>>>
>>>>> Thanks,
>>>>> Micah
>>>>>
>>>>> On Tue, Jun 25, 2024 at 9:07 AM Jack Ye <ye...@gmail.com> wrote:
>>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> Thanks for the feedback in the bylaws document discussion thread! As suggested, I have removed all the topics that require further debates, and created this new doc to serve as the initial version that we can review and later vote.
>>>>>>
>>>>>> https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit
>>>>>>
>>>>>> I will organize new devlist threads to discuss other topics to amend the guidelines step by step, once this initial version is in.
>>>>>>
>>>>>> A few additional changes that I have already incorporated:
>>>>>> 1. modified the name from "bylaws" to "community guidelines", following the latest ASF guideline
>>>>>> 2. renamed "lazy majority" and "lazy 2/3 majority" to "majority approval" and "2/3 majority approval"
>>>>>> 3. changed "Propose Removing Committer", "Propose Removing PMC Member" to consensus approval, and added "Propose PMC Chair Change" decision following the default Apache project community guidelines.
>>>>>> 4. changed "Release Product" voting period to 5 days instead of 3 days excluding weekends.
>>>>>> 5. clarified the copyright of code in Apache Iceberg codebases
>>>>>>
>>>>>> The most important thing is probably to agree upon the 2/3 majority approval for modifying the project guidelines, so we can have a consistent voting method going forward. This initial introduction of the bylaws will be voted using consensus approval.
>>>>>>
>>>>>> Please take a look and comment about any additional changes needed, and I will host a vote in 3 days.
>>>>>>
>>>>>> Best,
>>>>>> Jack Ye
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Ryan Blue
>>>> Databricks
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
My recommendation would be to not to call them bylaws.
Justin
> On 12 Jul 2024, at 1:30 am, Jack Ye <ye...@gmail.com> wrote:
>
> Update:
>
> Based on the conversations on the incubator list (https://lists.apache.org/thread/5ojxny76fr7n1y0hs2rxhr55g1fgcsln), I have updated the document title from "guidelines" back to "bylaws". Thanks for pointing this out Carl!
>
> I have also updated the document with a few suggested edits from some people, please let me know what everyone thinks!
>
> -Jack
>
>
> On Wed, Jul 3, 2024 at 8:30 PM Justin Mclean <justin@classsoftware.com <ma...@classsoftware.com>> wrote:
>> HI,
>>
>> For some historical context, it used to be that the board / Incubator asked projects to have a set of bylaws when they graduated. This fell out of favour more than ten years ago, and projects were expected to follow documented policy. Before this, things were not as well documented, so we asked for bylines. Once we had better documentation it was seen that bylaws were a duplicate of existing policy and no longer required. There was, however, some confusion around policy, so those short Incubator guidelines were adopted. Also, remember that most of our policies are, in fact, guidelines and document one way or what has been found to work well. That doesn't mean it’s the best fit for a particular project, and if you want to do something different for a good reason that still fits in with how ASF projects are governed, you can.
>>
>> Kind Regards,
>> Justin
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Jack Ye <ye...@gmail.com>.
Update:
Based on the conversations on the incubator list (
https://lists.apache.org/thread/5ojxny76fr7n1y0hs2rxhr55g1fgcsln), I have
updated the document title from "guidelines" back to "bylaws". Thanks for
pointing this out Carl!
I have also updated the document with a few suggested edits from some
people, please let me know what everyone thinks!
-Jack
On Wed, Jul 3, 2024 at 8:30 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> HI,
>
> For some historical context, it used to be that the board / Incubator
> asked projects to have a set of bylaws when they graduated. This fell out
> of favour more than ten years ago, and projects were expected to follow
> documented policy. Before this, things were not as well documented, so we
> asked for bylines. Once we had better documentation it was seen that bylaws
> were a duplicate of existing policy and no longer required. There was,
> however, some confusion around policy, so those short Incubator guidelines
> were adopted. Also, remember that most of our policies are, in fact,
> guidelines and document one way or what has been found to work well. That
> doesn't mean it’s the best fit for a particular project, and if you want to
> do something different for a good reason that still fits in with how ASF
> projects are governed, you can.
>
> Kind Regards,
> Justin
>
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
For some historical context, it used to be that the board / Incubator asked projects to have a set of bylaws when they graduated. This fell out of favour more than ten years ago, and projects were expected to follow documented policy. Before this, things were not as well documented, so we asked for bylines. Once we had better documentation it was seen that bylaws were a duplicate of existing policy and no longer required. There was, however, some confusion around policy, so those short Incubator guidelines were adopted. Also, remember that most of our policies are, in fact, guidelines and document one way or what has been found to work well. That doesn't mean it’s the best fit for a particular project, and if you want to do something different for a good reason that still fits in with how ASF projects are governed, you can.
Kind Regards,
Justin
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Carl Steinbach <cw...@gmail.com>.
> 1. modified the name from "bylaws" to "community guidelines", following
the latest ASF guideline
I want to make sure everyone is aware that there is a substantive
difference between the meaning of "bylaw" and "guideline." Here's how the
two words are defined in the Cambridge Dictionary:
- Bylaw: "a rule that GOVERNS the members of an organization." [1]
[emphasis added]
- Guideline: "information intended to advise people on how something SHOULD
BE done or what something SHOULD BE." [2] [emphasis added]
Wikipedia, while not an authoritative source, provides useful context on
how these terms are used in practice:
- "A bylaw ... is a set of rules or law established by an organization or
community so as to regulate itself, as allowed or provided for by some
higher authority." [3]
- "A guideline is similar to a rule, but are legally less binding as
justified deviations are possible." [4]
I am neither a lawyer nor a lexicographer, but it seems clear that a
guideline carries no more weight than an officially approved suggestion,
while a bylaw is a binding rule. It's up to the PMC to decide whether this
document is a set of non-binding suggestions that SHOULD BE [5] followed or
a set of binding laws that MUST BE followed, but in either case, I think
the PMC needs to clearly convey their intention by using the correct word.
[1] https://dictionary.cambridge.org/us/dictionary/english/bylaw
[2] https://dictionary.cambridge.org/us/dictionary/english/guideline
[3] https://en.wikipedia.org/w/index.php?title=By-law&oldid=1215430864
[4] https://en.wikipedia.org/w/index.php?title=Guideline&oldid=1185185478
[5] https://datatracker.ietf.org/doc/html/rfc2119
[6] https://lists.apache.org/thread/h15qjp35ghg446xr5bnmmlg06p3hdoj9
On Tue, Jul 2, 2024 at 9:26 AM Jack Ye <ye...@gmail.com> wrote:
> Yes I am totally aware of the situation of people on vacation and
> traveling, and was in the process of talking and resolving some people's
> comments in the doc, that's why I did not start the vote as originally
> planned. I think we are all aligned on this, sorry I did not make it very
> clear in the last reply.
>
> And thank you Owen, this would be a great idea! I also heard some concerns
> of me driving this since I am also backed by a vendor. I considered opening
> the access to all PMC members, but there are some technical challenges like
> people's devlist email are not exactly their Gmail and many people are
> still out of town, so things were also delayed at this front. Let us know
> what you think is the best way to proceed!
>
> Best,
> Jack Ye
>
>
>
>
> On Tue, Jul 2, 2024 at 9:14 AM Daniel Weeks <dw...@apache.org> wrote:
>
>> Thanks Owen, I really appreciate the offer to moderate the discussion.
>> I think that's a good idea and it would really benefit the community to
>> have someone facilitating the discussion and drafting docs that does not
>> have commercial interest.
>>
>> A number of PMC members have expressed that they're currently traveling
>> or on vacation, which makes me concerned that the discussion isn't really
>> reflective of the PMC.
>>
>> I'd love to hear your thoughts on how we might want to proceed.
>>
>> Thanks,
>> Dan
>>
>> On Tue, Jul 2, 2024 at 1:57 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> Hi Owen
>>>
>>> Sorry I missed your message before replying. I agree, I think we
>>> should take more time on the proposal.
>>>
>>> Regards
>>> JB
>>>
>>> On Mon, Jul 1, 2024 at 10:14 PM Owen O'Malley <ow...@gmail.com>
>>> wrote:
>>> >
>>> > Sorry for coming into this conversation late, but I have a lot of
>>> experience with writing the bylaws for Apache projects (Hadoop & ORC). As a
>>> neutral third party (not working for Databricks or a cloud provider) who
>>> has a lot of Apache experience, I'd like to offer my service as a moderator
>>> for the discussion. I don't think it is appropriate for a small group to
>>> come back with a finished product for a final vote, especially during the
>>> summer when lots of people are travelling, this process should be much more
>>> gradual and inclusive.
>>> >
>>> > .. Owen
>>> >
>>> > On Mon, Jul 1, 2024 at 7:21 AM Jack Ye <ye...@gmail.com> wrote:
>>> >>
>>> >> Hi everyone,
>>> >>
>>> >> Thanks for all the comments and feedback on the document, I am
>>> working with a few commenters on some additional changes and wording, and
>>> then will carry out the vote.
>>> >>
>>> >> Best,
>>> >> Jack Ye
>>> >>
>>> >> On Thu, Jun 27, 2024 at 11:02 AM Jack Ye <ye...@gmail.com> wrote:
>>> >>>
>>> >>> To provide an update here, I have consolidated most of the comments
>>> in the initial version, with the following changes:
>>> >>>
>>> >>> (1) condensed the section of roles and responsibilities, with
>>> pointers to different pages in ASF and existing Iceberg project pages.
>>> >>>
>>> >>> (2) clarified voting details, regrading things like partial votes,
>>> difference of voting on mailing lists vs voting on GitHub PRs
>>> >>>
>>> >>> (3) clarified the section regarding lazy consensus. There is a
>>> definition difference between the ASF definition (no +1 vote needed) vs the
>>> ORC definition (1 +1 vote). I renamed the ORC version as "minimum
>>> consensus" instead.
>>> >>>
>>> >>> (4) updated "Modify Code" vote type to minimum consensus. This is a
>>> bit different from ASF definition for code modification, but I think we are
>>> coming to an agreement that the ASF definition is outdated. Minimum
>>> consensus seems to make the most sense given the way we operate Iceberg so
>>> far, which is basically at least 1 committer other than the author needs to
>>> approve a PR before merging.
>>> >>>
>>> >>> (5) updated all decisions regarding committers and PMC members and
>>> guideline updates to majority approval, following the ASF guideline on
>>> voting for procedural issues.
>>> >>>
>>> >>> Let me know if there is anything else we see major disagreements
>>> with, and I will organize a vote after 24 hours.
>>> >>>
>>> >>> Best,
>>> >>> Jack Ye
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Wed, Jun 26, 2024 at 11:04 AM Jack Ye <ye...@gmail.com>
>>> wrote:
>>> >>>>
>>> >>>> +1 for adding to the site.
>>> >>>>
>>> >>>> I am putting it as a doc for now since Google doc is easier to
>>> comment (I think?). My plan is to:
>>> >>>>
>>> >>>> (1) publish it as a PR after a vote has passed. We can do one more
>>> sanity check in the PR, but the information will be exactly as it is
>>> presented in the Google doc, maybe adding some additional links to more
>>> easily jump among the sections or to other pages in the site, fix some
>>> grammar issues that were overlooked.
>>> >>>>
>>> >>>> (2) keep a changelog within the document itself. Because we have
>>> moved the site multiple times in the past, I am not really confident that
>>> we could just track history with Git commit history, especially with such
>>> an important document. I would like to add a changelog section in the end,
>>> documenting what change has been approved when, with links to devlist
>>> discussions and votes.
>>> >>>>
>>> >>>> For how we tackle the other topics, my plan is to pass the initial
>>> version first, and then we just go through all the identified topics one by
>>> one. I have a list of all topics in the original feedback collection
>>> devlist thread.
>>> >>>>
>>> >>>> Let me know what you think about these plans!
>>> >>>>
>>> >>>> Best,
>>> >>>> Jack Ye
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Wed, Jun 26, 2024 at 9:04 AM Ryan Blue
>>> <bl...@databricks.com.invalid> wrote:
>>> >>>>>
>>> >>>>> +1 for adding this to the site once we agree on the changes.
>>> >>>>>
>>> >>>>> One thing that has been raised several times but hasn't yet been
>>> addressed is how we want to tackle this. Many of us have asked to review
>>> the additional bylaws individually and discuss the purpose and merits of
>>> each one. It's great to have an overall doc (much like our integrated PRs
>>> to give context) but I think we should start having separate discussions
>>> about the rationale for each bylaw to make progress.
>>> >>>>>
>>> >>>>> Ryan
>>> >>>>>
>>> >>>>> On Wed, Jun 26, 2024 at 8:57 AM Micah Kornfield <
>>> emkornfield@gmail.com> wrote:
>>> >>>>>>
>>> >>>>>> Hi Jack,
>>> >>>>>> I think it would make sense to convert this to a PR, so it can be
>>> version tracked in the future (and that way it avoids another review if the
>>> intent is to transitition github)?
>>> >>>>>>
>>> >>>>>> Thanks,
>>> >>>>>> Micah
>>> >>>>>>
>>> >>>>>> On Tue, Jun 25, 2024 at 9:07 AM Jack Ye <ye...@gmail.com>
>>> wrote:
>>> >>>>>>>
>>> >>>>>>> Hi everyone,
>>> >>>>>>>
>>> >>>>>>> Thanks for the feedback in the bylaws document discussion
>>> thread! As suggested, I have removed all the topics that require further
>>> debates, and created this new doc to serve as the initial version that we
>>> can review and later vote.
>>> >>>>>>>
>>> >>>>>>>
>>> https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit
>>> >>>>>>>
>>> >>>>>>> I will organize new devlist threads to discuss other topics to
>>> amend the guidelines step by step, once this initial version is in.
>>> >>>>>>>
>>> >>>>>>> A few additional changes that I have already incorporated:
>>> >>>>>>> 1. modified the name from "bylaws" to "community guidelines",
>>> following the latest ASF guideline
>>> >>>>>>> 2. renamed "lazy majority" and "lazy 2/3 majority" to "majority
>>> approval" and "2/3 majority approval"
>>> >>>>>>> 3. changed "Propose Removing Committer", "Propose Removing PMC
>>> Member" to consensus approval, and added "Propose PMC Chair Change"
>>> decision following the default Apache project community guidelines.
>>> >>>>>>> 4. changed "Release Product" voting period to 5 days instead of
>>> 3 days excluding weekends.
>>> >>>>>>> 5. clarified the copyright of code in Apache Iceberg codebases
>>> >>>>>>>
>>> >>>>>>> The most important thing is probably to agree upon the 2/3
>>> majority approval for modifying the project guidelines, so we can have a
>>> consistent voting method going forward. This initial introduction of the
>>> bylaws will be voted using consensus approval.
>>> >>>>>>>
>>> >>>>>>> Please take a look and comment about any additional changes
>>> needed, and I will host a vote in 3 days.
>>> >>>>>>>
>>> >>>>>>> Best,
>>> >>>>>>> Jack Ye
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> Ryan Blue
>>> >>>>> Databricks
>>>
>>
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Jack Ye <ye...@gmail.com>.
Yes I am totally aware of the situation of people on vacation and
traveling, and was in the process of talking and resolving some people's
comments in the doc, that's why I did not start the vote as originally
planned. I think we are all aligned on this, sorry I did not make it very
clear in the last reply.
And thank you Owen, this would be a great idea! I also heard some concerns
of me driving this since I am also backed by a vendor. I considered opening
the access to all PMC members, but there are some technical challenges like
people's devlist email are not exactly their Gmail and many people are
still out of town, so things were also delayed at this front. Let us know
what you think is the best way to proceed!
Best,
Jack Ye
On Tue, Jul 2, 2024 at 9:14 AM Daniel Weeks <dw...@apache.org> wrote:
> Thanks Owen, I really appreciate the offer to moderate the discussion. I
> think that's a good idea and it would really benefit the community to have
> someone facilitating the discussion and drafting docs that does not have
> commercial interest.
>
> A number of PMC members have expressed that they're currently traveling or
> on vacation, which makes me concerned that the discussion isn't really
> reflective of the PMC.
>
> I'd love to hear your thoughts on how we might want to proceed.
>
> Thanks,
> Dan
>
> On Tue, Jul 2, 2024 at 1:57 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Hi Owen
>>
>> Sorry I missed your message before replying. I agree, I think we
>> should take more time on the proposal.
>>
>> Regards
>> JB
>>
>> On Mon, Jul 1, 2024 at 10:14 PM Owen O'Malley <ow...@gmail.com>
>> wrote:
>> >
>> > Sorry for coming into this conversation late, but I have a lot of
>> experience with writing the bylaws for Apache projects (Hadoop & ORC). As a
>> neutral third party (not working for Databricks or a cloud provider) who
>> has a lot of Apache experience, I'd like to offer my service as a moderator
>> for the discussion. I don't think it is appropriate for a small group to
>> come back with a finished product for a final vote, especially during the
>> summer when lots of people are travelling, this process should be much more
>> gradual and inclusive.
>> >
>> > .. Owen
>> >
>> > On Mon, Jul 1, 2024 at 7:21 AM Jack Ye <ye...@gmail.com> wrote:
>> >>
>> >> Hi everyone,
>> >>
>> >> Thanks for all the comments and feedback on the document, I am working
>> with a few commenters on some additional changes and wording, and then will
>> carry out the vote.
>> >>
>> >> Best,
>> >> Jack Ye
>> >>
>> >> On Thu, Jun 27, 2024 at 11:02 AM Jack Ye <ye...@gmail.com> wrote:
>> >>>
>> >>> To provide an update here, I have consolidated most of the comments
>> in the initial version, with the following changes:
>> >>>
>> >>> (1) condensed the section of roles and responsibilities, with
>> pointers to different pages in ASF and existing Iceberg project pages.
>> >>>
>> >>> (2) clarified voting details, regrading things like partial votes,
>> difference of voting on mailing lists vs voting on GitHub PRs
>> >>>
>> >>> (3) clarified the section regarding lazy consensus. There is a
>> definition difference between the ASF definition (no +1 vote needed) vs the
>> ORC definition (1 +1 vote). I renamed the ORC version as "minimum
>> consensus" instead.
>> >>>
>> >>> (4) updated "Modify Code" vote type to minimum consensus. This is a
>> bit different from ASF definition for code modification, but I think we are
>> coming to an agreement that the ASF definition is outdated. Minimum
>> consensus seems to make the most sense given the way we operate Iceberg so
>> far, which is basically at least 1 committer other than the author needs to
>> approve a PR before merging.
>> >>>
>> >>> (5) updated all decisions regarding committers and PMC members and
>> guideline updates to majority approval, following the ASF guideline on
>> voting for procedural issues.
>> >>>
>> >>> Let me know if there is anything else we see major disagreements
>> with, and I will organize a vote after 24 hours.
>> >>>
>> >>> Best,
>> >>> Jack Ye
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Jun 26, 2024 at 11:04 AM Jack Ye <ye...@gmail.com> wrote:
>> >>>>
>> >>>> +1 for adding to the site.
>> >>>>
>> >>>> I am putting it as a doc for now since Google doc is easier to
>> comment (I think?). My plan is to:
>> >>>>
>> >>>> (1) publish it as a PR after a vote has passed. We can do one more
>> sanity check in the PR, but the information will be exactly as it is
>> presented in the Google doc, maybe adding some additional links to more
>> easily jump among the sections or to other pages in the site, fix some
>> grammar issues that were overlooked.
>> >>>>
>> >>>> (2) keep a changelog within the document itself. Because we have
>> moved the site multiple times in the past, I am not really confident that
>> we could just track history with Git commit history, especially with such
>> an important document. I would like to add a changelog section in the end,
>> documenting what change has been approved when, with links to devlist
>> discussions and votes.
>> >>>>
>> >>>> For how we tackle the other topics, my plan is to pass the initial
>> version first, and then we just go through all the identified topics one by
>> one. I have a list of all topics in the original feedback collection
>> devlist thread.
>> >>>>
>> >>>> Let me know what you think about these plans!
>> >>>>
>> >>>> Best,
>> >>>> Jack Ye
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Wed, Jun 26, 2024 at 9:04 AM Ryan Blue
>> <bl...@databricks.com.invalid> wrote:
>> >>>>>
>> >>>>> +1 for adding this to the site once we agree on the changes.
>> >>>>>
>> >>>>> One thing that has been raised several times but hasn't yet been
>> addressed is how we want to tackle this. Many of us have asked to review
>> the additional bylaws individually and discuss the purpose and merits of
>> each one. It's great to have an overall doc (much like our integrated PRs
>> to give context) but I think we should start having separate discussions
>> about the rationale for each bylaw to make progress.
>> >>>>>
>> >>>>> Ryan
>> >>>>>
>> >>>>> On Wed, Jun 26, 2024 at 8:57 AM Micah Kornfield <
>> emkornfield@gmail.com> wrote:
>> >>>>>>
>> >>>>>> Hi Jack,
>> >>>>>> I think it would make sense to convert this to a PR, so it can be
>> version tracked in the future (and that way it avoids another review if the
>> intent is to transitition github)?
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>> Micah
>> >>>>>>
>> >>>>>> On Tue, Jun 25, 2024 at 9:07 AM Jack Ye <ye...@gmail.com>
>> wrote:
>> >>>>>>>
>> >>>>>>> Hi everyone,
>> >>>>>>>
>> >>>>>>> Thanks for the feedback in the bylaws document discussion thread!
>> As suggested, I have removed all the topics that require further debates,
>> and created this new doc to serve as the initial version that we can review
>> and later vote.
>> >>>>>>>
>> >>>>>>>
>> https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit
>> >>>>>>>
>> >>>>>>> I will organize new devlist threads to discuss other topics to
>> amend the guidelines step by step, once this initial version is in.
>> >>>>>>>
>> >>>>>>> A few additional changes that I have already incorporated:
>> >>>>>>> 1. modified the name from "bylaws" to "community guidelines",
>> following the latest ASF guideline
>> >>>>>>> 2. renamed "lazy majority" and "lazy 2/3 majority" to "majority
>> approval" and "2/3 majority approval"
>> >>>>>>> 3. changed "Propose Removing Committer", "Propose Removing PMC
>> Member" to consensus approval, and added "Propose PMC Chair Change"
>> decision following the default Apache project community guidelines.
>> >>>>>>> 4. changed "Release Product" voting period to 5 days instead of 3
>> days excluding weekends.
>> >>>>>>> 5. clarified the copyright of code in Apache Iceberg codebases
>> >>>>>>>
>> >>>>>>> The most important thing is probably to agree upon the 2/3
>> majority approval for modifying the project guidelines, so we can have a
>> consistent voting method going forward. This initial introduction of the
>> bylaws will be voted using consensus approval.
>> >>>>>>>
>> >>>>>>> Please take a look and comment about any additional changes
>> needed, and I will host a vote in 3 days.
>> >>>>>>>
>> >>>>>>> Best,
>> >>>>>>> Jack Ye
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Ryan Blue
>> >>>>> Databricks
>>
>
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Daniel Weeks <dw...@apache.org>.
Thanks Owen, I really appreciate the offer to moderate the discussion. I
think that's a good idea and it would really benefit the community to have
someone facilitating the discussion and drafting docs that does not have
commercial interest.
A number of PMC members have expressed that they're currently traveling or
on vacation, which makes me concerned that the discussion isn't really
reflective of the PMC.
I'd love to hear your thoughts on how we might want to proceed.
Thanks,
Dan
On Tue, Jul 2, 2024 at 1:57 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Owen
>
> Sorry I missed your message before replying. I agree, I think we
> should take more time on the proposal.
>
> Regards
> JB
>
> On Mon, Jul 1, 2024 at 10:14 PM Owen O'Malley <ow...@gmail.com>
> wrote:
> >
> > Sorry for coming into this conversation late, but I have a lot of
> experience with writing the bylaws for Apache projects (Hadoop & ORC). As a
> neutral third party (not working for Databricks or a cloud provider) who
> has a lot of Apache experience, I'd like to offer my service as a moderator
> for the discussion. I don't think it is appropriate for a small group to
> come back with a finished product for a final vote, especially during the
> summer when lots of people are travelling, this process should be much more
> gradual and inclusive.
> >
> > .. Owen
> >
> > On Mon, Jul 1, 2024 at 7:21 AM Jack Ye <ye...@gmail.com> wrote:
> >>
> >> Hi everyone,
> >>
> >> Thanks for all the comments and feedback on the document, I am working
> with a few commenters on some additional changes and wording, and then will
> carry out the vote.
> >>
> >> Best,
> >> Jack Ye
> >>
> >> On Thu, Jun 27, 2024 at 11:02 AM Jack Ye <ye...@gmail.com> wrote:
> >>>
> >>> To provide an update here, I have consolidated most of the comments in
> the initial version, with the following changes:
> >>>
> >>> (1) condensed the section of roles and responsibilities, with pointers
> to different pages in ASF and existing Iceberg project pages.
> >>>
> >>> (2) clarified voting details, regrading things like partial votes,
> difference of voting on mailing lists vs voting on GitHub PRs
> >>>
> >>> (3) clarified the section regarding lazy consensus. There is a
> definition difference between the ASF definition (no +1 vote needed) vs the
> ORC definition (1 +1 vote). I renamed the ORC version as "minimum
> consensus" instead.
> >>>
> >>> (4) updated "Modify Code" vote type to minimum consensus. This is a
> bit different from ASF definition for code modification, but I think we are
> coming to an agreement that the ASF definition is outdated. Minimum
> consensus seems to make the most sense given the way we operate Iceberg so
> far, which is basically at least 1 committer other than the author needs to
> approve a PR before merging.
> >>>
> >>> (5) updated all decisions regarding committers and PMC members and
> guideline updates to majority approval, following the ASF guideline on
> voting for procedural issues.
> >>>
> >>> Let me know if there is anything else we see major disagreements with,
> and I will organize a vote after 24 hours.
> >>>
> >>> Best,
> >>> Jack Ye
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Jun 26, 2024 at 11:04 AM Jack Ye <ye...@gmail.com> wrote:
> >>>>
> >>>> +1 for adding to the site.
> >>>>
> >>>> I am putting it as a doc for now since Google doc is easier to
> comment (I think?). My plan is to:
> >>>>
> >>>> (1) publish it as a PR after a vote has passed. We can do one more
> sanity check in the PR, but the information will be exactly as it is
> presented in the Google doc, maybe adding some additional links to more
> easily jump among the sections or to other pages in the site, fix some
> grammar issues that were overlooked.
> >>>>
> >>>> (2) keep a changelog within the document itself. Because we have
> moved the site multiple times in the past, I am not really confident that
> we could just track history with Git commit history, especially with such
> an important document. I would like to add a changelog section in the end,
> documenting what change has been approved when, with links to devlist
> discussions and votes.
> >>>>
> >>>> For how we tackle the other topics, my plan is to pass the initial
> version first, and then we just go through all the identified topics one by
> one. I have a list of all topics in the original feedback collection
> devlist thread.
> >>>>
> >>>> Let me know what you think about these plans!
> >>>>
> >>>> Best,
> >>>> Jack Ye
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Jun 26, 2024 at 9:04 AM Ryan Blue <bl...@databricks.com.invalid>
> wrote:
> >>>>>
> >>>>> +1 for adding this to the site once we agree on the changes.
> >>>>>
> >>>>> One thing that has been raised several times but hasn't yet been
> addressed is how we want to tackle this. Many of us have asked to review
> the additional bylaws individually and discuss the purpose and merits of
> each one. It's great to have an overall doc (much like our integrated PRs
> to give context) but I think we should start having separate discussions
> about the rationale for each bylaw to make progress.
> >>>>>
> >>>>> Ryan
> >>>>>
> >>>>> On Wed, Jun 26, 2024 at 8:57 AM Micah Kornfield <
> emkornfield@gmail.com> wrote:
> >>>>>>
> >>>>>> Hi Jack,
> >>>>>> I think it would make sense to convert this to a PR, so it can be
> version tracked in the future (and that way it avoids another review if the
> intent is to transitition github)?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Micah
> >>>>>>
> >>>>>> On Tue, Jun 25, 2024 at 9:07 AM Jack Ye <ye...@gmail.com>
> wrote:
> >>>>>>>
> >>>>>>> Hi everyone,
> >>>>>>>
> >>>>>>> Thanks for the feedback in the bylaws document discussion thread!
> As suggested, I have removed all the topics that require further debates,
> and created this new doc to serve as the initial version that we can review
> and later vote.
> >>>>>>>
> >>>>>>>
> https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit
> >>>>>>>
> >>>>>>> I will organize new devlist threads to discuss other topics to
> amend the guidelines step by step, once this initial version is in.
> >>>>>>>
> >>>>>>> A few additional changes that I have already incorporated:
> >>>>>>> 1. modified the name from "bylaws" to "community guidelines",
> following the latest ASF guideline
> >>>>>>> 2. renamed "lazy majority" and "lazy 2/3 majority" to "majority
> approval" and "2/3 majority approval"
> >>>>>>> 3. changed "Propose Removing Committer", "Propose Removing PMC
> Member" to consensus approval, and added "Propose PMC Chair Change"
> decision following the default Apache project community guidelines.
> >>>>>>> 4. changed "Release Product" voting period to 5 days instead of 3
> days excluding weekends.
> >>>>>>> 5. clarified the copyright of code in Apache Iceberg codebases
> >>>>>>>
> >>>>>>> The most important thing is probably to agree upon the 2/3
> majority approval for modifying the project guidelines, so we can have a
> consistent voting method going forward. This initial introduction of the
> bylaws will be voted using consensus approval.
> >>>>>>>
> >>>>>>> Please take a look and comment about any additional changes
> needed, and I will host a vote in 3 days.
> >>>>>>>
> >>>>>>> Best,
> >>>>>>> Jack Ye
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Ryan Blue
> >>>>> Databricks
>
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Owen
Sorry I missed your message before replying. I agree, I think we
should take more time on the proposal.
Regards
JB
On Mon, Jul 1, 2024 at 10:14 PM Owen O'Malley <ow...@gmail.com> wrote:
>
> Sorry for coming into this conversation late, but I have a lot of experience with writing the bylaws for Apache projects (Hadoop & ORC). As a neutral third party (not working for Databricks or a cloud provider) who has a lot of Apache experience, I'd like to offer my service as a moderator for the discussion. I don't think it is appropriate for a small group to come back with a finished product for a final vote, especially during the summer when lots of people are travelling, this process should be much more gradual and inclusive.
>
> .. Owen
>
> On Mon, Jul 1, 2024 at 7:21 AM Jack Ye <ye...@gmail.com> wrote:
>>
>> Hi everyone,
>>
>> Thanks for all the comments and feedback on the document, I am working with a few commenters on some additional changes and wording, and then will carry out the vote.
>>
>> Best,
>> Jack Ye
>>
>> On Thu, Jun 27, 2024 at 11:02 AM Jack Ye <ye...@gmail.com> wrote:
>>>
>>> To provide an update here, I have consolidated most of the comments in the initial version, with the following changes:
>>>
>>> (1) condensed the section of roles and responsibilities, with pointers to different pages in ASF and existing Iceberg project pages.
>>>
>>> (2) clarified voting details, regrading things like partial votes, difference of voting on mailing lists vs voting on GitHub PRs
>>>
>>> (3) clarified the section regarding lazy consensus. There is a definition difference between the ASF definition (no +1 vote needed) vs the ORC definition (1 +1 vote). I renamed the ORC version as "minimum consensus" instead.
>>>
>>> (4) updated "Modify Code" vote type to minimum consensus. This is a bit different from ASF definition for code modification, but I think we are coming to an agreement that the ASF definition is outdated. Minimum consensus seems to make the most sense given the way we operate Iceberg so far, which is basically at least 1 committer other than the author needs to approve a PR before merging.
>>>
>>> (5) updated all decisions regarding committers and PMC members and guideline updates to majority approval, following the ASF guideline on voting for procedural issues.
>>>
>>> Let me know if there is anything else we see major disagreements with, and I will organize a vote after 24 hours.
>>>
>>> Best,
>>> Jack Ye
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 26, 2024 at 11:04 AM Jack Ye <ye...@gmail.com> wrote:
>>>>
>>>> +1 for adding to the site.
>>>>
>>>> I am putting it as a doc for now since Google doc is easier to comment (I think?). My plan is to:
>>>>
>>>> (1) publish it as a PR after a vote has passed. We can do one more sanity check in the PR, but the information will be exactly as it is presented in the Google doc, maybe adding some additional links to more easily jump among the sections or to other pages in the site, fix some grammar issues that were overlooked.
>>>>
>>>> (2) keep a changelog within the document itself. Because we have moved the site multiple times in the past, I am not really confident that we could just track history with Git commit history, especially with such an important document. I would like to add a changelog section in the end, documenting what change has been approved when, with links to devlist discussions and votes.
>>>>
>>>> For how we tackle the other topics, my plan is to pass the initial version first, and then we just go through all the identified topics one by one. I have a list of all topics in the original feedback collection devlist thread.
>>>>
>>>> Let me know what you think about these plans!
>>>>
>>>> Best,
>>>> Jack Ye
>>>>
>>>>
>>>>
>>>> On Wed, Jun 26, 2024 at 9:04 AM Ryan Blue <bl...@databricks.com.invalid> wrote:
>>>>>
>>>>> +1 for adding this to the site once we agree on the changes.
>>>>>
>>>>> One thing that has been raised several times but hasn't yet been addressed is how we want to tackle this. Many of us have asked to review the additional bylaws individually and discuss the purpose and merits of each one. It's great to have an overall doc (much like our integrated PRs to give context) but I think we should start having separate discussions about the rationale for each bylaw to make progress.
>>>>>
>>>>> Ryan
>>>>>
>>>>> On Wed, Jun 26, 2024 at 8:57 AM Micah Kornfield <em...@gmail.com> wrote:
>>>>>>
>>>>>> Hi Jack,
>>>>>> I think it would make sense to convert this to a PR, so it can be version tracked in the future (and that way it avoids another review if the intent is to transitition github)?
>>>>>>
>>>>>> Thanks,
>>>>>> Micah
>>>>>>
>>>>>> On Tue, Jun 25, 2024 at 9:07 AM Jack Ye <ye...@gmail.com> wrote:
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> Thanks for the feedback in the bylaws document discussion thread! As suggested, I have removed all the topics that require further debates, and created this new doc to serve as the initial version that we can review and later vote.
>>>>>>>
>>>>>>> https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit
>>>>>>>
>>>>>>> I will organize new devlist threads to discuss other topics to amend the guidelines step by step, once this initial version is in.
>>>>>>>
>>>>>>> A few additional changes that I have already incorporated:
>>>>>>> 1. modified the name from "bylaws" to "community guidelines", following the latest ASF guideline
>>>>>>> 2. renamed "lazy majority" and "lazy 2/3 majority" to "majority approval" and "2/3 majority approval"
>>>>>>> 3. changed "Propose Removing Committer", "Propose Removing PMC Member" to consensus approval, and added "Propose PMC Chair Change" decision following the default Apache project community guidelines.
>>>>>>> 4. changed "Release Product" voting period to 5 days instead of 3 days excluding weekends.
>>>>>>> 5. clarified the copyright of code in Apache Iceberg codebases
>>>>>>>
>>>>>>> The most important thing is probably to agree upon the 2/3 majority approval for modifying the project guidelines, so we can have a consistent voting method going forward. This initial introduction of the bylaws will be voted using consensus approval.
>>>>>>>
>>>>>>> Please take a look and comment about any additional changes needed, and I will host a vote in 3 days.
>>>>>>>
>>>>>>> Best,
>>>>>>> Jack Ye
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ryan Blue
>>>>> Databricks
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Owen O'Malley <ow...@gmail.com>.
Sorry for coming into this conversation late, but I have a lot of
experience with writing the bylaws for Apache projects (Hadoop & ORC). As a
neutral third party (not working for Databricks or a cloud provider) who
has a lot of Apache experience, I'd like to offer my service as a moderator
for the discussion. I don't think it is appropriate for a small group to
come back with a finished product for a final vote, especially during the
summer when lots of people are travelling, this process should be much more
gradual and inclusive.
.. Owen
On Mon, Jul 1, 2024 at 7:21 AM Jack Ye <ye...@gmail.com> wrote:
> Hi everyone,
>
> Thanks for all the comments and feedback on the document, I am working
> with a few commenters on some additional changes and wording, and then will
> carry out the vote.
>
> Best,
> Jack Ye
>
> On Thu, Jun 27, 2024 at 11:02 AM Jack Ye <ye...@gmail.com> wrote:
>
>> To provide an update here, I have consolidated most of the comments in
>> the initial version, with the following changes:
>>
>> (1) condensed the section of roles and responsibilities, with pointers to
>> different pages in ASF and existing Iceberg project pages.
>>
>> (2) clarified voting details, regrading things like partial votes,
>> difference of voting on mailing lists vs voting on GitHub PRs
>>
>> (3) clarified the section regarding lazy consensus. There is a definition
>> difference between the ASF definition (no +1 vote needed) vs the ORC
>> definition (1 +1 vote). I renamed the ORC version as "minimum consensus"
>> instead.
>>
>> (4) updated "Modify Code" vote type to minimum consensus. This is a bit
>> different from ASF definition for code modification, but I think we are
>> coming to an agreement that the ASF definition is outdated. Minimum
>> consensus seems to make the most sense given the way we operate Iceberg so
>> far, which is basically at least 1 committer other than the author needs to
>> approve a PR before merging.
>>
>> (5) updated all decisions regarding committers and PMC members and
>> guideline updates to majority approval, following the ASF guideline on
>> voting for procedural issues.
>>
>> Let me know if there is anything else we see major disagreements with,
>> and I will organize a vote after 24 hours.
>>
>> Best,
>> Jack Ye
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jun 26, 2024 at 11:04 AM Jack Ye <ye...@gmail.com> wrote:
>>
>>> +1 for adding to the site.
>>>
>>> I am putting it as a doc for now since Google doc is easier to comment
>>> (I think?). My plan is to:
>>>
>>> (1) publish it as a PR after a vote has passed. We can do one more
>>> sanity check in the PR, but the information will be exactly as it is
>>> presented in the Google doc, maybe adding some additional links to more
>>> easily jump among the sections or to other pages in the site, fix some
>>> grammar issues that were overlooked.
>>>
>>> (2) keep a changelog within the document itself. Because we have moved
>>> the site multiple times in the past, I am not really confident that we
>>> could just track history with Git commit history, especially with such an
>>> important document. I would like to add a changelog section in the end,
>>> documenting what change has been approved when, with links to devlist
>>> discussions and votes.
>>>
>>> For how we tackle the other topics, my plan is to pass the initial
>>> version first, and then we just go through all the identified topics one by
>>> one. I have a list of all topics in the original feedback collection
>>> devlist thread.
>>>
>>> Let me know what you think about these plans!
>>>
>>> Best,
>>> Jack Ye
>>>
>>>
>>>
>>> On Wed, Jun 26, 2024 at 9:04 AM Ryan Blue <bl...@databricks.com.invalid>
>>> wrote:
>>>
>>>> +1 for adding this to the site once we agree on the changes.
>>>>
>>>> One thing that has been raised several times but hasn't yet been
>>>> addressed is how we want to tackle this. Many of us have asked to review
>>>> the additional bylaws individually and discuss the purpose and merits of
>>>> each one. It's great to have an overall doc (much like our integrated PRs
>>>> to give context) but I think we should start having separate discussions
>>>> about the rationale for each bylaw to make progress.
>>>>
>>>> Ryan
>>>>
>>>> On Wed, Jun 26, 2024 at 8:57 AM Micah Kornfield <em...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Jack,
>>>>> I think it would make sense to convert this to a PR, so it can be
>>>>> version tracked in the future (and that way it avoids another review if the
>>>>> intent is to transitition github)?
>>>>>
>>>>> Thanks,
>>>>> Micah
>>>>>
>>>>> On Tue, Jun 25, 2024 at 9:07 AM Jack Ye <ye...@gmail.com> wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> Thanks for the feedback in the bylaws document discussion thread! As
>>>>>> suggested, I have removed all the topics that require further debates, and
>>>>>> created this new doc to serve as the initial version that we can review and
>>>>>> later vote.
>>>>>>
>>>>>>
>>>>>> https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit
>>>>>>
>>>>>> I will organize new devlist threads to discuss other topics to amend
>>>>>> the guidelines step by step, once this initial version is in.
>>>>>>
>>>>>> A few additional changes that I have already incorporated:
>>>>>> 1. modified the name from "bylaws" to "community guidelines",
>>>>>> following the latest ASF guideline
>>>>>> 2. renamed "lazy majority" and "lazy 2/3 majority" to "majority
>>>>>> approval" and "2/3 majority approval"
>>>>>> 3. changed "Propose Removing Committer", "Propose Removing PMC
>>>>>> Member" to consensus approval, and added "Propose PMC Chair Change"
>>>>>> decision following the default Apache project community guidelines.
>>>>>> 4. changed "Release Product" voting period to 5 days instead of 3
>>>>>> days excluding weekends.
>>>>>> 5. clarified the copyright of code in Apache Iceberg codebases
>>>>>>
>>>>>> The most important thing is probably to agree upon the 2/3 majority
>>>>>> approval for modifying the project guidelines, so we can have a consistent
>>>>>> voting method going forward. This initial introduction of the bylaws will
>>>>>> be voted using consensus approval.
>>>>>>
>>>>>> Please take a look and comment about any additional changes needed,
>>>>>> and I will host a vote in 3 days.
>>>>>>
>>>>>> Best,
>>>>>> Jack Ye
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Ryan Blue
>>>> Databricks
>>>>
>>>
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Jack Ye <ye...@gmail.com>.
Hi everyone,
Thanks for all the comments and feedback on the document, I am working with
a few commenters on some additional changes and wording, and then will
carry out the vote.
Best,
Jack Ye
On Thu, Jun 27, 2024 at 11:02 AM Jack Ye <ye...@gmail.com> wrote:
> To provide an update here, I have consolidated most of the comments in the
> initial version, with the following changes:
>
> (1) condensed the section of roles and responsibilities, with pointers to
> different pages in ASF and existing Iceberg project pages.
>
> (2) clarified voting details, regrading things like partial votes,
> difference of voting on mailing lists vs voting on GitHub PRs
>
> (3) clarified the section regarding lazy consensus. There is a definition
> difference between the ASF definition (no +1 vote needed) vs the ORC
> definition (1 +1 vote). I renamed the ORC version as "minimum consensus"
> instead.
>
> (4) updated "Modify Code" vote type to minimum consensus. This is a bit
> different from ASF definition for code modification, but I think we are
> coming to an agreement that the ASF definition is outdated. Minimum
> consensus seems to make the most sense given the way we operate Iceberg so
> far, which is basically at least 1 committer other than the author needs to
> approve a PR before merging.
>
> (5) updated all decisions regarding committers and PMC members and
> guideline updates to majority approval, following the ASF guideline on
> voting for procedural issues.
>
> Let me know if there is anything else we see major disagreements with, and
> I will organize a vote after 24 hours.
>
> Best,
> Jack Ye
>
>
>
>
>
>
>
> On Wed, Jun 26, 2024 at 11:04 AM Jack Ye <ye...@gmail.com> wrote:
>
>> +1 for adding to the site.
>>
>> I am putting it as a doc for now since Google doc is easier to comment (I
>> think?). My plan is to:
>>
>> (1) publish it as a PR after a vote has passed. We can do one more sanity
>> check in the PR, but the information will be exactly as it is presented in
>> the Google doc, maybe adding some additional links to more easily jump
>> among the sections or to other pages in the site, fix some grammar issues
>> that were overlooked.
>>
>> (2) keep a changelog within the document itself. Because we have moved
>> the site multiple times in the past, I am not really confident that we
>> could just track history with Git commit history, especially with such an
>> important document. I would like to add a changelog section in the end,
>> documenting what change has been approved when, with links to devlist
>> discussions and votes.
>>
>> For how we tackle the other topics, my plan is to pass the initial
>> version first, and then we just go through all the identified topics one by
>> one. I have a list of all topics in the original feedback collection
>> devlist thread.
>>
>> Let me know what you think about these plans!
>>
>> Best,
>> Jack Ye
>>
>>
>>
>> On Wed, Jun 26, 2024 at 9:04 AM Ryan Blue <bl...@databricks.com.invalid>
>> wrote:
>>
>>> +1 for adding this to the site once we agree on the changes.
>>>
>>> One thing that has been raised several times but hasn't yet been
>>> addressed is how we want to tackle this. Many of us have asked to review
>>> the additional bylaws individually and discuss the purpose and merits of
>>> each one. It's great to have an overall doc (much like our integrated PRs
>>> to give context) but I think we should start having separate discussions
>>> about the rationale for each bylaw to make progress.
>>>
>>> Ryan
>>>
>>> On Wed, Jun 26, 2024 at 8:57 AM Micah Kornfield <em...@gmail.com>
>>> wrote:
>>>
>>>> Hi Jack,
>>>> I think it would make sense to convert this to a PR, so it can be
>>>> version tracked in the future (and that way it avoids another review if the
>>>> intent is to transitition github)?
>>>>
>>>> Thanks,
>>>> Micah
>>>>
>>>> On Tue, Jun 25, 2024 at 9:07 AM Jack Ye <ye...@gmail.com> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> Thanks for the feedback in the bylaws document discussion thread! As
>>>>> suggested, I have removed all the topics that require further debates, and
>>>>> created this new doc to serve as the initial version that we can review and
>>>>> later vote.
>>>>>
>>>>>
>>>>> https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit
>>>>>
>>>>> I will organize new devlist threads to discuss other topics to amend
>>>>> the guidelines step by step, once this initial version is in.
>>>>>
>>>>> A few additional changes that I have already incorporated:
>>>>> 1. modified the name from "bylaws" to "community guidelines",
>>>>> following the latest ASF guideline
>>>>> 2. renamed "lazy majority" and "lazy 2/3 majority" to "majority
>>>>> approval" and "2/3 majority approval"
>>>>> 3. changed "Propose Removing Committer", "Propose Removing PMC Member"
>>>>> to consensus approval, and added "Propose PMC Chair Change" decision
>>>>> following the default Apache project community guidelines.
>>>>> 4. changed "Release Product" voting period to 5 days instead of 3 days
>>>>> excluding weekends.
>>>>> 5. clarified the copyright of code in Apache Iceberg codebases
>>>>>
>>>>> The most important thing is probably to agree upon the 2/3 majority
>>>>> approval for modifying the project guidelines, so we can have a consistent
>>>>> voting method going forward. This initial introduction of the bylaws will
>>>>> be voted using consensus approval.
>>>>>
>>>>> Please take a look and comment about any additional changes needed,
>>>>> and I will host a vote in 3 days.
>>>>>
>>>>> Best,
>>>>> Jack Ye
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> Ryan Blue
>>> Databricks
>>>
>>
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Jack Ye <ye...@gmail.com>.
To provide an update here, I have consolidated most of the comments in the
initial version, with the following changes:
(1) condensed the section of roles and responsibilities, with pointers to
different pages in ASF and existing Iceberg project pages.
(2) clarified voting details, regrading things like partial votes,
difference of voting on mailing lists vs voting on GitHub PRs
(3) clarified the section regarding lazy consensus. There is a definition
difference between the ASF definition (no +1 vote needed) vs the ORC
definition (1 +1 vote). I renamed the ORC version as "minimum consensus"
instead.
(4) updated "Modify Code" vote type to minimum consensus. This is a bit
different from ASF definition for code modification, but I think we are
coming to an agreement that the ASF definition is outdated. Minimum
consensus seems to make the most sense given the way we operate Iceberg so
far, which is basically at least 1 committer other than the author needs to
approve a PR before merging.
(5) updated all decisions regarding committers and PMC members and
guideline updates to majority approval, following the ASF guideline on
voting for procedural issues.
Let me know if there is anything else we see major disagreements with, and
I will organize a vote after 24 hours.
Best,
Jack Ye
On Wed, Jun 26, 2024 at 11:04 AM Jack Ye <ye...@gmail.com> wrote:
> +1 for adding to the site.
>
> I am putting it as a doc for now since Google doc is easier to comment (I
> think?). My plan is to:
>
> (1) publish it as a PR after a vote has passed. We can do one more sanity
> check in the PR, but the information will be exactly as it is presented in
> the Google doc, maybe adding some additional links to more easily jump
> among the sections or to other pages in the site, fix some grammar issues
> that were overlooked.
>
> (2) keep a changelog within the document itself. Because we have moved the
> site multiple times in the past, I am not really confident that we could
> just track history with Git commit history, especially with such an
> important document. I would like to add a changelog section in the end,
> documenting what change has been approved when, with links to devlist
> discussions and votes.
>
> For how we tackle the other topics, my plan is to pass the initial version
> first, and then we just go through all the identified topics one by one. I
> have a list of all topics in the original feedback collection devlist
> thread.
>
> Let me know what you think about these plans!
>
> Best,
> Jack Ye
>
>
>
> On Wed, Jun 26, 2024 at 9:04 AM Ryan Blue <bl...@databricks.com.invalid>
> wrote:
>
>> +1 for adding this to the site once we agree on the changes.
>>
>> One thing that has been raised several times but hasn't yet been
>> addressed is how we want to tackle this. Many of us have asked to review
>> the additional bylaws individually and discuss the purpose and merits of
>> each one. It's great to have an overall doc (much like our integrated PRs
>> to give context) but I think we should start having separate discussions
>> about the rationale for each bylaw to make progress.
>>
>> Ryan
>>
>> On Wed, Jun 26, 2024 at 8:57 AM Micah Kornfield <em...@gmail.com>
>> wrote:
>>
>>> Hi Jack,
>>> I think it would make sense to convert this to a PR, so it can be
>>> version tracked in the future (and that way it avoids another review if the
>>> intent is to transitition github)?
>>>
>>> Thanks,
>>> Micah
>>>
>>> On Tue, Jun 25, 2024 at 9:07 AM Jack Ye <ye...@gmail.com> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> Thanks for the feedback in the bylaws document discussion thread! As
>>>> suggested, I have removed all the topics that require further debates, and
>>>> created this new doc to serve as the initial version that we can review and
>>>> later vote.
>>>>
>>>>
>>>> https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit
>>>>
>>>> I will organize new devlist threads to discuss other topics to amend
>>>> the guidelines step by step, once this initial version is in.
>>>>
>>>> A few additional changes that I have already incorporated:
>>>> 1. modified the name from "bylaws" to "community guidelines", following
>>>> the latest ASF guideline
>>>> 2. renamed "lazy majority" and "lazy 2/3 majority" to "majority
>>>> approval" and "2/3 majority approval"
>>>> 3. changed "Propose Removing Committer", "Propose Removing PMC Member"
>>>> to consensus approval, and added "Propose PMC Chair Change" decision
>>>> following the default Apache project community guidelines.
>>>> 4. changed "Release Product" voting period to 5 days instead of 3 days
>>>> excluding weekends.
>>>> 5. clarified the copyright of code in Apache Iceberg codebases
>>>>
>>>> The most important thing is probably to agree upon the 2/3 majority
>>>> approval for modifying the project guidelines, so we can have a consistent
>>>> voting method going forward. This initial introduction of the bylaws will
>>>> be voted using consensus approval.
>>>>
>>>> Please take a look and comment about any additional changes needed, and
>>>> I will host a vote in 3 days.
>>>>
>>>> Best,
>>>> Jack Ye
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>> --
>> Ryan Blue
>> Databricks
>>
>
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Jack Ye <ye...@gmail.com>.
+1 for adding to the site.
I am putting it as a doc for now since Google doc is easier to comment (I
think?). My plan is to:
(1) publish it as a PR after a vote has passed. We can do one more sanity
check in the PR, but the information will be exactly as it is presented in
the Google doc, maybe adding some additional links to more easily jump
among the sections or to other pages in the site, fix some grammar issues
that were overlooked.
(2) keep a changelog within the document itself. Because we have moved the
site multiple times in the past, I am not really confident that we could
just track history with Git commit history, especially with such an
important document. I would like to add a changelog section in the end,
documenting what change has been approved when, with links to devlist
discussions and votes.
For how we tackle the other topics, my plan is to pass the initial version
first, and then we just go through all the identified topics one by one. I
have a list of all topics in the original feedback collection devlist
thread.
Let me know what you think about these plans!
Best,
Jack Ye
On Wed, Jun 26, 2024 at 9:04 AM Ryan Blue <bl...@databricks.com.invalid>
wrote:
> +1 for adding this to the site once we agree on the changes.
>
> One thing that has been raised several times but hasn't yet been addressed
> is how we want to tackle this. Many of us have asked to review the
> additional bylaws individually and discuss the purpose and merits of each
> one. It's great to have an overall doc (much like our integrated PRs to
> give context) but I think we should start having separate discussions about
> the rationale for each bylaw to make progress.
>
> Ryan
>
> On Wed, Jun 26, 2024 at 8:57 AM Micah Kornfield <em...@gmail.com>
> wrote:
>
>> Hi Jack,
>> I think it would make sense to convert this to a PR, so it can be version
>> tracked in the future (and that way it avoids another review if the intent
>> is to transitition github)?
>>
>> Thanks,
>> Micah
>>
>> On Tue, Jun 25, 2024 at 9:07 AM Jack Ye <ye...@gmail.com> wrote:
>>
>>> Hi everyone,
>>>
>>> Thanks for the feedback in the bylaws document discussion thread! As
>>> suggested, I have removed all the topics that require further debates, and
>>> created this new doc to serve as the initial version that we can review and
>>> later vote.
>>>
>>>
>>> https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit
>>>
>>> I will organize new devlist threads to discuss other topics to amend the
>>> guidelines step by step, once this initial version is in.
>>>
>>> A few additional changes that I have already incorporated:
>>> 1. modified the name from "bylaws" to "community guidelines", following
>>> the latest ASF guideline
>>> 2. renamed "lazy majority" and "lazy 2/3 majority" to "majority
>>> approval" and "2/3 majority approval"
>>> 3. changed "Propose Removing Committer", "Propose Removing PMC Member"
>>> to consensus approval, and added "Propose PMC Chair Change" decision
>>> following the default Apache project community guidelines.
>>> 4. changed "Release Product" voting period to 5 days instead of 3 days
>>> excluding weekends.
>>> 5. clarified the copyright of code in Apache Iceberg codebases
>>>
>>> The most important thing is probably to agree upon the 2/3 majority
>>> approval for modifying the project guidelines, so we can have a consistent
>>> voting method going forward. This initial introduction of the bylaws will
>>> be voted using consensus approval.
>>>
>>> Please take a look and comment about any additional changes needed, and
>>> I will host a vote in 3 days.
>>>
>>> Best,
>>> Jack Ye
>>>
>>>
>>>
>>>
>>>
>
> --
> Ryan Blue
> Databricks
>
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Ryan Blue <bl...@databricks.com.INVALID>.
+1 for adding this to the site once we agree on the changes.
One thing that has been raised several times but hasn't yet been addressed
is how we want to tackle this. Many of us have asked to review the
additional bylaws individually and discuss the purpose and merits of each
one. It's great to have an overall doc (much like our integrated PRs to
give context) but I think we should start having separate discussions about
the rationale for each bylaw to make progress.
Ryan
On Wed, Jun 26, 2024 at 8:57 AM Micah Kornfield <em...@gmail.com>
wrote:
> Hi Jack,
> I think it would make sense to convert this to a PR, so it can be version
> tracked in the future (and that way it avoids another review if the intent
> is to transitition github)?
>
> Thanks,
> Micah
>
> On Tue, Jun 25, 2024 at 9:07 AM Jack Ye <ye...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> Thanks for the feedback in the bylaws document discussion thread! As
>> suggested, I have removed all the topics that require further debates, and
>> created this new doc to serve as the initial version that we can review and
>> later vote.
>>
>>
>> https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit
>>
>> I will organize new devlist threads to discuss other topics to amend the
>> guidelines step by step, once this initial version is in.
>>
>> A few additional changes that I have already incorporated:
>> 1. modified the name from "bylaws" to "community guidelines", following
>> the latest ASF guideline
>> 2. renamed "lazy majority" and "lazy 2/3 majority" to "majority approval"
>> and "2/3 majority approval"
>> 3. changed "Propose Removing Committer", "Propose Removing PMC Member" to
>> consensus approval, and added "Propose PMC Chair Change" decision following
>> the default Apache project community guidelines.
>> 4. changed "Release Product" voting period to 5 days instead of 3 days
>> excluding weekends.
>> 5. clarified the copyright of code in Apache Iceberg codebases
>>
>> The most important thing is probably to agree upon the 2/3 majority
>> approval for modifying the project guidelines, so we can have a consistent
>> voting method going forward. This initial introduction of the bylaws will
>> be voted using consensus approval.
>>
>> Please take a look and comment about any additional changes needed, and I
>> will host a vote in 3 days.
>>
>> Best,
>> Jack Ye
>>
>>
>>
>>
>>
--
Ryan Blue
Databricks
Re: [Discussion] Apache Iceberg Community Guideline - Initial Version
Posted by Micah Kornfield <em...@gmail.com>.
Hi Jack,
I think it would make sense to convert this to a PR, so it can be version
tracked in the future (and that way it avoids another review if the intent
is to transitition github)?
Thanks,
Micah
On Tue, Jun 25, 2024 at 9:07 AM Jack Ye <ye...@gmail.com> wrote:
> Hi everyone,
>
> Thanks for the feedback in the bylaws document discussion thread! As
> suggested, I have removed all the topics that require further debates, and
> created this new doc to serve as the initial version that we can review and
> later vote.
>
>
> https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit
>
> I will organize new devlist threads to discuss other topics to amend the
> guidelines step by step, once this initial version is in.
>
> A few additional changes that I have already incorporated:
> 1. modified the name from "bylaws" to "community guidelines", following
> the latest ASF guideline
> 2. renamed "lazy majority" and "lazy 2/3 majority" to "majority approval"
> and "2/3 majority approval"
> 3. changed "Propose Removing Committer", "Propose Removing PMC Member" to
> consensus approval, and added "Propose PMC Chair Change" decision following
> the default Apache project community guidelines.
> 4. changed "Release Product" voting period to 5 days instead of 3 days
> excluding weekends.
> 5. clarified the copyright of code in Apache Iceberg codebases
>
> The most important thing is probably to agree upon the 2/3 majority
> approval for modifying the project guidelines, so we can have a consistent
> voting method going forward. This initial introduction of the bylaws will
> be voted using consensus approval.
>
> Please take a look and comment about any additional changes needed, and I
> will host a vote in 3 days.
>
> Best,
> Jack Ye
>
>
>
>
>