I completely agree regarding transparency, having options expressed in writing, and tracking decisions.
I also support the ASF philosophy that voting should only happen on the dev list. However, treating the dev list as the only acceptable mechanism for discussion feels overly burdensome, in my humble opinion. In practice, I don't believe that email is not structured enough for all types of interactions. Here are two simple examples: 1. *Github issues* We have a template for reporting issues that enforces structure - capturing key elements such as Airflow version, affected area, reproduction steps, and so on. This level of enforced structure is hard to achieve in email. We also frequently respond to Github issues with decisions - explicitly or implicitly - which, in an abstract sense, are still decisions. 2. *AIPs (Airflow Improvement Proposals)* We have a template for AIPs. While many improvement ideas start as a simple thought in a Github issue or email, we often ask contributors to write them up as AIPs. The structure helps guide discussion, enables threaded comments, and supports versioning. Personally, I find the AIP process quite helpful. We do reference the AIP in the voting thread on the dev list, but the bulk of the discussion happens in Confluence, within the context of the written document. I may be misunderstanding the intent of this discussion, but one of the referenced examples - specifically "the versioning rules for the API" - was already covered in the original AIP <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-72+Task+Execution+Interface+aka+Task+SDK>, in the following paragraph: *"This API should be strongly versioned using CalVer, and we propose an approach such as https://docs.cadwyn.dev/ <https://docs.cadwyn.dev/> to allow us to easily support many versions in parallel (tl;dr of this project: calver + request "migrations" lets you easily handle multiple versions API clients without needing parallel support, even what might otherwise be a breaking change, as long as change from one version to the next does not throw away information.) Each change, no matter how small, to this API will result in a new CalVer."* I have always viewed ASF processes as encouraging written, open communication to foster transparency in decision making, but not as precluding the use of openly accessible applications such as Github and Wiki. So far, I believe the Github and AIP processes have worked well alongside the dev list, and I am unsure what the motivation is for requiring a change here. Vikram On Sat, Mar 22, 2025 at 10:20 AM Michał Modras <michalmod...@google.com.invalid> wrote: > +1, I fully agree with the mechanism - it is open, transparent, gives > everyone an opportunity to participate, and keeps track of how the > decisions are made. > > On Sat, Mar 22, 2025 at 5:34 PM Shahar Epstein <sha...@apache.org> wrote: > > > Overall I agree that decisions should be made in the devlist. > > One improvement that I'd like to suggest, though, is to have a dedicated > > page on cwiki that summarizes all recent and upcoming decisions (votes + > > lazy consensus) in a table, including links to their respective devlist > > threads. We could have a page for important discussions as well. > > By doing it, we'll gain: > > 1. Better transparency - instead of searching within many emails for > > past decisions in client/Apache mail archives, we'll just look them up at > > the table. > > 2. Better noticeability - people would be more easily aware of > > upcoming votes. Personally I often miss emails as I redirect them to a > > subdirectory, and I get disappointed if I miss important votes. > > > > We already attach links to threads for AIPs in their wiki page, but I > think > > that having a more generalized page would benefit us all. > > That's my two ₪ anyway :) > > > > > > Shahar > > > > On Sat, Mar 22, 2025 at 12:09 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > > I also would like to start another thread regarding decision making in > > our > > > projects. We had some discussions about decision making in our project. > > > > > > As an ASF project we are supposed to make important decisions on the > > > devlist. Full stop. "If it did not happen at the devlist, it did not > > > happen" is something that you can hear often in the ASF - even if the > > only > > > place you can actually see it written this way is > > > https://www.apache.org/press/highlights.html#2017 > > > > > > The Apache Software Foundation has a very clear notion of important > > > decision making: > > > > > > * official voting rules https://www.apache.org/foundation/voting.html > > > * community development guidelines > > > https://community.apache.org/committers/decisionMaking.html > > > > > > Both of those refer to decision making at the devlist. > > > > > > We had a few - unnecessarily heated - discussions on how decisions are > > made > > > in the project. I personally think that our decision making should be > > done > > > at the devlist - where anyone can participate. Things like versioning > > rules > > > for API (hinted by Ash at the last dev call) or how our repo is > > structured > > > (a new proposal raised today by TP) should - IMHO - be discussed here, > at > > > the devlist. > > > > > > Not in a slack thread, not in private discussion, not when two or more > > > people talk to each other in a call. It's fine to discuss things > outside > > - > > > of course, but then any proposals for a change of things that we > already > > > discussed for weeks and either implicitly (by non-objection) or > > explicitly > > > (by not responding to [LAZY CONSENSUS] or [VOTE] thread in the devlist) > > are > > > just discussions. If someone wants a change, starting a thread in > devlist > > > is the right way of proposing a change. Especially for things that were > > > discussed before - sometimes for weeks, and no concerns were raised. > > > > > > IMHO - it's very simple - want a change - start and lead a [DISCUSS]. > > [LAZY > > > CONSENSUS]. or [VOTE] (depending on the level of disagreement and > number > > of > > > different opinions). Not very complex - it just requires to start and > > lead > > > a discussion mailing list thread. Super inclusive and follows the > > archiving > > > and all other requirements of the ASF (for example you do not have to > > agree > > > TOC of Slack to participate) > > > > > > I would love to hear if others disagree with it and think that this > > process > > > is overly complex or problematic. I think it's quite clear, reasonable > > and > > > great to keep community decision making in check and follow all the > rules > > > and expectations of the ASF, but maybe there are some concerns with the > > > process and we would like to improve it. > > > > > > I would love to hear what others think about it. > > > > > > J. > > > > > >
