Some additional perspectives from someone not on Iceberg, but who's
looked into a lot of ASF project communities.
On 2024/06/25 17:54:48 Tyler Akidau wrote:
...snip...
1. I like the idea of guidelines on committership and PMC membership, but
worry about overspecification limiting who might be c
Thanks, Jack, for taking the time to put this initiative together.
I will borrow Julian Hyde’s example of the blind men and the elephant [1]:
“Do you know the story of the blind men and the elephant? Each man touches
a different part of the elephant, so they assume they are touching a
different a
Hi everyone,
Thanks Jack, for your efforts in the proposed bylaws. This initiative not
only provides a valuable foundation but also prompts us to thoroughly
examine our current operations and ensure they align with our collective
objectives.
An area I like for discussion is the management of prop
Thanks for bringing this up Jack.
I think having more established rules specifically for the project is
probably a good thing to make sure outsiders see a path to becoming more
included in the project. I'm especially interested in the proposals for
more actively including newer contributors from d
Thank you Jack for wrangling this. These conversations are never easy, but
I'm glad to see this happening. As a relative newcomer to the Iceberg
effort, I am personally supportive of the idea of bylaws. I agree with Ryan
that it's important to not overspecify and overindex on processes, but I do
th
Thanks everyone for the insightful comments! I have raised a separate
thread for the initial trimmed down version of the proposal.
To summarize, here are the discussion points we will have once the initial
version is passed:
1. guidelines for committership and PMC membership
2. active, inactive, e
Hi everyone,
Thanks to everyone for the valuable points raised recently.
I’m in favor of having bylaws that contain details on how the Iceberg
community works, especially regarding “Decisions,” as this will provide
clarity and guidance for all members. I would like to share some of my
thoughts o
Hi, everyone.
Thank Jack Ye to start this hard work first.
I want to emphasize that ONE being seen as the project leader is not about
holding the position of PMC Chair, but rather due to his contributions.
I'm more interested in lowering the entry requirements for committers and PMC
members t
On 2024/06/24 07:38:47 Jack Ye wrote:
> Hi everyone,
>
> I propose that we put up a bylaws document like other projects such as
> Apache Hadoop and Apache ORC. I think this will put people at peace and
> remove many people's concerns about the future of the project and its
> vendor-neutral stan
> I would love to have a "problems statement" as
introduction: what problems we see concretely (and with facts to prove
that), what are the proposals in the bylaws to fix that.
Thanks JB for bringing this up.
+1 to collect all the problems from the community first by openly
discussing it (without
I meant precision (not prevision) :)
Typo mistake :)
Regards
JB
Le mar. 25 juin 2024 à 07:53, Jean-Baptiste Onofré a
écrit :
> Hi,
>
> Just a couple of comments and prevision from ASF standpoint:
>
> 1. Generally speaking, I like this bylaws proposal, and I don't see a
> problem to state again
Hi,
Just a couple of comments and prevision from ASF standpoint:
1. Generally speaking, I like this bylaws proposal, and I don't see a
problem to state again what is defined at ASF level (I'm thinking
about vote which is described here
https://www.apache.org/foundation/voting. As reminder, it's n
HI,
> This was in response to the discussion on emeritus, looks like Jack already
> took this into account in the latest proposal, so it is ok with me. I'm
> still for tracking emeritus status, as in the long run more PMC's naturally
> become inactive and it is harder to pass a majority vote.
Hi
Also copying my previous response in private.
Hi
> Thanks Jack for taking the time for this doc. While the Iceberg community
> and PMC so far has been one of the most collaborative, and I have
> personally the utmost respect for those that laid the groundwork without
> which we would not be h
Hey everyone,
Thanks Jack for setting this up, and everyone for their feedback so far.
Sharing my exact response from the private@:
Hey Jack,
>
> Thanks for raising this, and favor of having a bylaws where we can
> formally adopt ways of working that are specific to the Iceberg project.
> For exa
Here is my original email from the thread on the private list. It echoes
Carl's suggestion in point 5, that we should focus on adopting bylaws that
solve challenges that we are facing in this community, rather than adopting
bylaws en masse or from another community with different concerns.
Origina
+ private for PMC members who may not follow dev
1/ I encourage the folks who have already responded on the private@ thread
to replay their comments here. As I noted earlier, this discussion falls
outside the categories that belong on the private list.
2/ I think adopting a set of clearly articul
Thanks for pointing to the ASF guidelines Carl, I did not know that. I had
the impression of engaging with the private list first due to responses in
previous devlist discussions, but I guess I landed in the right place
eventually :)
> In light of the recent change of company for a few committers
The motivation for bylaws was this: "In light of the recent change of
company for a few committers and PMC members".
That means that we're talking about new rules based on what a few specific
people might do. Speculation like that belongs on a private list, just like
discussing actual behavior wou
Hi Ryan and Jack,
The ASF's PMC Guide [1] is pretty clear on what belongs on the private list:
- pre-disclosure security problems
- pre-agreement discussions with third parties that require
confidentiality
- nominees for project committer, PMC or Foundation membership
- personal c
> The reason for that is that there's a long-standing norm to discuss the
conduct of individuals only on private lists. In this case, I think it
applies even though it is discussing hypothetical conduct. And note that
I'm one of the individuals here.
Respectfully, what does this mean, Ryan? No ind
Sorry for the confusion Ryan, this is not mistakenly sent to devlist. As we
discussed, this is the thread for collecting community feedback, which is
essential for forming bylaws with the community.
We have that separated discussion thread in the private list, which we will
continue to iterate, an
Hey everyone, I think Jack mistakenly sent this to the dev list so please
let's pause discussion for now.
There's a thread on the private list about this in which PMC members,
including me, have asked to keep it on the private list right now.
The reason for that is that there's a long-standing no
Yes I also agree there is the issue of accumulated proposals and PRs. And I
think we should discuss it as a part of the bylaw, since the voting process
matters a lot regarding the velocity.
For the PR part, my approach in the bylaws is to make sure code
modification is a lazy consensus of a commit
Thanks Jack for raising this, this is quite important to keep healthy of
this community.
I agree with Ajantha about the concerns of accumulated proposals and prs,
and maybe we should have another thread to discuss about it?
On Mon, Jun 24, 2024 at 20:37 Robert Stupp wrote:
> Thanks Jack for the
Thanks Jack for the proposal.
I’m generally +1 on this. There are a few details to clarify, but I suspect
nothing that’s controversial.
> On 24. Jun 2024, at 12:45, Ajantha Bhat wrote:
>
> Thank you, Jack, for your diligent work on this.
>
> This seems essential at the moment.
>
> I would lik
Thank you, Jack, for your diligent work on this.
This seems essential at the moment.
I would like to address a couple of additional points that need our
attention:
*Criteria for Committership/PMC:*We've observed an inconsistency in how
committership is granted. Contributors to sub-projects ofte
Hi everyone,
In light of the recent change of company for a few committers and PMC
members, I hear an increasing ask from the community to define proper
processes in Iceberg to ensure its vendor neutral stance.
I propose that we put up a bylaws document like other projects such as
Apache Hadoop a
28 matches
Mail list logo
