Hey Everyone, I think that lazy consensus should be done for best practices too following the Jarek's comment that if we will not be able to reach consensus regarding given best practice, it will probably not be a best practice. If it would be only a PR for doc (definitely every best practice should have an entry there before ruff rule PR), it always can be missed.
Also, +1 for everything what Jarek mentioned. ________________________________ From: André Ahlert <[email protected]> Sent: 05 March 2026 22:22 To: [email protected] <[email protected]> Subject: Re: [Discuss] How we submit Airflow-Specific Rules to Ruff Hey everybody, The process sounds reasonable, and I think we can meet in the middle by splitting rule types. For migration/deprecation (Airflow 3 behavior/compat), a short dev-list lazy consensus is enough. For “best practice” rules, I’d treat “AIR” as meaning community-backed, so it should have a Best Practices entry (or doc PR) before we endorse the Ruff PR. For external Ruff-first PRs, I wouldn’t block or “punish” anyone; just reply with a friendly template asking for a brief dev-list thread so we can confirm whether it’s AIR-endorsed or should use a different prefix/disclaimer. I also like a simple default window (e.g., 72h) and always cross-link the thread in the Ruff PR. Em qui., 5 de mar. de 2026 às 17:24, Kaxil Naik <[email protected]> escreveu: > Lazy consensus seems good to me since any rules merged there should > actually help Airflow & Ruff users. So a bad rule isn't good for us or > Ruff. > > On Thu, 5 Mar 2026 at 19:54, Jarek Potiuk <[email protected]> wrote: > > > Yes. I think consensus or a vote is a good idea. > > > > From the very beginning Ruff rules for Airflow were only submitted > > there because we befriended Astral and cooperated, and they were > > willing to accept our AIR rules. However, I would personally would > > love if Ruff had a plugin system for those (which I know is unlikely > > to happen - at least in short term - and Charlie and the team were > > very explicit about it). If you have a free evening > > https://github.com/astral-sh/ruff/issues/283 might be an interesting > > read :) > > > > So we have to live with what we have. Technically it's unlikely Astral > > team will merge anything in AIR without consulting with the PMC - > > because this is what they agree from the beginning. And this is their > > rule not ours. But even if we have no technical control over PR > > merges, we still maintain complete trademark control. As the rule name > > suggests, these rules are connected with the PMC because they are > > generally "Airflow rules." Airflow is a registered trademark, we could > > easily demand the removal of the rules because we do not control their > > actions. This is similar to social media. For example, on LinkedIn, we > > have no ultimate control over where, how, or for whom content is > > shown, but we control what is posted there. If someone creates another > > LI account called "Apache Airflow" and starts posting there, we have > > all the power to issue a "cease and desist". It actually happened > > recently with one of the ASF projects—someone from the community > > posted (good things) about a project using an account that looked > > official, and the PMC asked them to hand over the account to the PMC's > > control. And they did (that was not even a hostile thing, it was more > > that PMC was worried someone might confuse that account with a PMC > > managed account). > > > > Technically, AIR (Airflow) in Ruff terms suggests PMC involvement. If > > someone submits their own rules named Airflow concerning Apache > > Airflow without a clear disclaimer that it is not a PMC thing, we have > > legal power over it, even if we lack formal "merge" button privileges. > > Airflow is a registered trademark, and it is the PMC members' duty to > > act and protect the brand when they become aware that someone is using > > the Airflow name inappropriately. So for example if Astral team were > > to go rogue at any point and started accepting rules that we, as a > > PMC, did not accept—or worse, rules we actively disagree with - we > > have all the legal power needed to ask them to remove those rules, and > > they will undoubtedly comply. I've seen many similar conversations > > where PMC members reached out and issues were fixed (we've even done > > that quite a few times). Those things are usually done in `private@` > > mailing lists, and they are resolved quickly. Nobody wants to mess > > with lawyers, and having a registered trademark—which we do - gives > > you a very strong argument. Nobody objects when you show them the > > registered trademark proof. They comply immediately. > > > > So even if we lack the technical power to "merge," we control the > > rules—it is up to us what process to follow. If there are doubts, lazy > > consensus and voting apply, so following it might be a good idea. > > > > Putting legality aside, I think also best practices is a nice thing to > > agree in the community - having a best practices that only one or a > > few people consider optimal isn't a good idea. If interested people > > (dev community here) cannot reach a consensus - or at the very least > > majority vote—that the practice is "best," then by almost definition, > > it's not. This means there are different practices, and none of them > > is best. > > > > And re: random submission - I agree "silence" would be a punishment. > > But personally I would not call disagreement or directing the person > > to devlist to ask for consensus a "punishment". I never see > > "discussion", "voting" or even "disagreement" or "heavy" argument as a > > form of punishment—for me, it's more a discovery of what others think. > > And it's a present you can take or not - whether you agree or > > disagree. I learn every time someone disagrees with me, every time I > > get my message across, and every time a decision is made against what > > I think. We have a good rule here: "disagree but engage," and I think > > the "disagree" part is a great learning opportunity. We've conducted > > big number of votes in the past, in some my position received more +1s > > than -1s, and in others, fewer. Whenever we did it well and a decision > > was made we just followed it. > > > > However, I also see that it would be great at some point to have > > different rules that we do not agree on here, but someone might want > > in Ruff. In such a case, I think that someone should ask the ruff > > people to use a different rule prefix (AIX for example) - to > > distinguish that from AIR practices that have general community > > consensus here. And names it "Person X rules for Apache Airflow(R)". > > > > This - in legar terms - is so called "nominative use". You can read > > about it in https://www.apache.org/foundation/marks/#principles. Such > > a name does not suggest that something is controlled by the Airflow > > PMC, and we have no control over its usage there, and you don't even > > have to ask for permission to use it. This could be done entirely > > outside the community - just between Person X and Astral. It's a > > question if they would accept something like that. However, that's a > > question, between the submitter and the Astral team, not ours. They > > might ask us or decide themselves, but only if someone follows the > > trademark and does not suggest in any way that those rules are > > "Airflow PMC ones." > > > > J. > > > > On Thu, Mar 5, 2026 at 8:03 AM Wei Lee <[email protected]> wrote: > > > > > > > is there currently an understanding in the user community, or even > > Ruff maintainers, that Ruff rules for Airflow (or any other library for > > that matter) are "official" or "officially endorsed"? > > > > > > Probably not *that* official, but this is closer to how things work > > today. Whenever Ruff maintainers receive an Airflow PR, they reach out to > > me (as I've been the most active Ruff contributor for AIR rules in the > > Airflow PMC) to check our stance on the rule. > > > > > > > Is there precedence for Apache project management procedures being > > "organically" extended to independent 3rd party tools? > > > > > > I'm not sure about this. Maybe Jarek has some thoughts? > > > > > > > Does that mean such a rule has no raison d'etre? > > > > > > Not really. It can still make sense. > > > > > > > Will they receive no feedback from contributors associated with > > Airflow "as punishment" for not going throughout an approval process they > > know nothing about? Will they be advised to follow a different project's > > (Airflow's) arbitrary guidelines? > > > > > > I think we should advise them to follow Airflow's guidelines, since the > > Airflow PMC might be asked to review that PR, and I'd like to ensure we > > have at least some consensus on how we want to review it. > > > > > > That said, we don't have control over Ruff. Ruff maintainers can still > > decide to merge a rule and release it without notifying the Airflow PMC. > > This process is primarily about deciding how we want to respond to those > > review requests and letting Ruff maintainers know that the Airflow > > community supports the PR's intent—but whether to merge it is still up to > > them. > > > > > > > > > And thanks for bringing these up! > > > > > > Best, > > > Wei > > > > > > > On Mar 5, 2026, at 2:21 PM, Dev-iL <[email protected]> wrote: > > > > > > > > Thank you for starting the discussion! > > > > > > > > I don't disagree with anything you said, but let me play the devil's > > > > advocate for a moment. > > > > > > > > I have a fundamental question to bring up - is there currently an > > > > understanding in the user community, or even Ruff maintainers, that > > Ruff > > > > rules for Airflow (or any other library for that matter) are > > "official" or > > > > "officially endorsed"? Is there precedence for Apache project > > management > > > > procedures being "organically" extended to independent 3rd party > tools? > > > > > > > > Ruff rules are opt-in, so if a certain user/project disagrees with a > > > > particular rule - they can just disable it. To give a specific > example > > - > > > > say someone creates a rule to migrate from operator api to taskflow - > > > > certain teams will surely not be interested in this and keep it > > disabled. > > > > Does that mean such a rule has no raison d'etre? > > > > > > > > Regarding the "we" part of your post's title -say a random > contributor > > who > > > > isn't familiar with Airflow's internal procedures proposes a rule > (i.e. > > > > raises a PR in Ruff). Will they receive no feedback from contributors > > > > associated with Airflow "as punishment" for not going throughout an > > > > approval process they know nothing about? Will they be advised to > > > > follow a *different > > > > project's* (Airflow's) arbitrary guidelines? > > > > > > > > Would love to hear your thoughts on this! > > > > > > > > Best, > > > > Iliya > > > > > > > > On Thu, 5 Mar 2026, 5:13 Wei Lee, <[email protected]> wrote: > > > > > > > >> Hi everyone, > > > >> > > > >> I'd like to start a discussion on how we decide to submit > > Airflow-specific > > > >> rules to Ruff in the future. > > > >> > > > >> ## What we have now > > > >> We already have migration rules in place, and this direction was > > proposed > > > >> by TP quite some time ago. In general, these changes have not > > required much > > > >> debate because they address cases where behavior no longer works in > > Airflow > > > >> 3. > > > >> > > > >> While working on the migration, we established a soft convention for > > rule > > > >> numbering: > > > >> > > > >> **AIR xyz**[1] — where "x" indicates the minimum supported Airflow > > major > > > >> version (e.g., AIR001 should be applied to all Airflow versions > while > > > >> AIR301 works for Airflow 3.0+), "y" means you should do it in "y-1" > > minor > > > >> version since these things will be deprecated since minor version > "y" > > and > > > >> will be removed in future version (most likely in the next major > > release, > > > >> but change it as early as possible). (e.g., AIR321 are things > changed > > in > > > >> Airflow 3.1.* but still have backward compatibility) > > > >> > > > >> ## Why this is brought up now > > > >> > > > >> Illya (Dev-iL) recently opened 4 PRs: (Illya even has SKILLS for > > that!) > > > >> > > > >> - https://github.com/astral-sh/ruff/pull/23584 > > > >> - https://github.com/astral-sh/ruff/pull/23631 > > > >> - https://github.com/astral-sh/ruff/pull/23579 > > > >> - https://github.com/astral-sh/ruff/pull/23583 > > > >> > > > >> The first 2 seem relatively uncontroversial: > > > >> > > > >> - One is already listed in Airflow best practices. > > > >> - One reflects a rule that has already been merged into the Airflow > 3 > > main > > > >> branch. > > > >> > > > >> The latter 2 are best practices. Although we have discussed this in > > > >> https://github.com/apache/airflow/issues/43176, I believe we should > > have > > > >> a more formal discussion on the dev list. > > > >> > > > >> ## My proposal > > > >> > > > >> For future additions of this type of rule, one possible process > could > > be: > > > >> > > > >> 1. Start a discussion (or Lazy Consensus) on the dev list. If > > consensus is > > > >> reached, proceed. > > > >> 2. Add the rule to the Airflow best practices documentation; at this > > > >> point, Ruff rule development can proceed in parallel. > > > >> 3. Once merged, update the Ruff rules to the relevant documentation > > > >> accordingly. > > > >> > > > >> Feedback and alternative suggestions are very welcome. If everything > > > >> sounds good, I'll start new threads for those existing PRs. > > > >> > > > >> Thanks! > > > >> > > > >> [1] https://docs.astral.sh/ruff/rules/#airflow-air > > > >> > --------------------------------------------------------------------- > > > >> To unsubscribe, e-mail: [email protected] > > > >> For additional commands, e-mail: [email protected] > > > >> > > > >> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
