You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know I've already been doing some of this, by including maintainer/authors like @larsgw and @shieldo, but I know there's a lot of you who have been super active and helpful, and even just maintaining other implementations.
I'd like to include as many maintainers in the org, as well as folks who have been contributing actively to the development of the language. The following list is not exhaustive, but just a list of names off the top of my head. If there's anyone else you think should be in the org, feel free to nominate them (or yourself). For nominations by folks other than me, I'll ask for a majority 👍🏻 from existing org members.
Once that's done, I'd like to stop acting as BDFL and just have us move the language forward by consent. That is, we will land things as long as no one has strong, principled objections. You can think of it as "soft consensus". I don't think we need much more formal structure than that for now, but we can figure that out as a group going forward.
I also don't expect this to be a high-maintenance thing. I don't expect or intend the pace of development to accelerate very much here. I just want us all to start moving towards a better system than "I wonder if Kat will like this".
The text was updated successfully, but these errors were encountered:
Maybe a call-for-consensus model before changes, with some timeline (two weeks?) to gather objections, running on a consensus model, meaning attempt to seek unanimous agreement, but at minimum no "strong" objections.
Presumably you hold veto power, allowing you to kill something you hate or override a strong objection from the council.
Presumably you hold invite/kick power for the council membership itself?
Call-for-consent is what I'm thinking of, but perhaps we should only do it for anything marked as breaking, rather than our usual business-as-usual house cleaning stuff?
No, I refuse to hold veto power and I want people to stop thinking of me that way.
See ^
If there ends up being a lot of us, we can always split off responsibility into teams, but I think for now, all we need is a thumbs up/down system on breaking changes.
Ah, I was using the W3C definition of consensus, which from what I can gather from an infographic you shared a bit ago on your Twitter, is indeed what you mean by "consent" (no strong objections; weak "I can live with it" objections are allowed).
For the rest, that surprises me, but I'm okay with it! We should formalize still formalize this somewhere; presumably a different repo in this org (kdl-org/how-we-work?)
I know I've already been doing some of this, by including maintainer/authors like @larsgw and @shieldo, but I know there's a lot of you who have been super active and helpful, and even just maintaining other implementations.
I'd like to include as many maintainers in the org, as well as folks who have been contributing actively to the development of the language. The following list is not exhaustive, but just a list of names off the top of my head. If there's anyone else you think should be in the org, feel free to nominate them (or yourself). For nominations by folks other than me, I'll ask for a majority 👍🏻 from existing org members.
So, for the list of folks off the top of my head:
Once that's done, I'd like to stop acting as BDFL and just have us move the language forward by consent. That is, we will land things as long as no one has strong, principled objections. You can think of it as "soft consensus". I don't think we need much more formal structure than that for now, but we can figure that out as a group going forward.
I also don't expect this to be a high-maintenance thing. I don't expect or intend the pace of development to accelerate very much here. I just want us all to start moving towards a better system than "I wonder if Kat will like this".
The text was updated successfully, but these errors were encountered: