> Thanks Jarek for sharing such valuable background information, particularly > concerning the legal aspects, which we hope we won’t need to delve into.
Over the years, I've learned that all licences, agreements, and terms and conditions are worth understanding - mostly because they prevent you from getting into situations where you need to use them. J. On Mon, Mar 9, 2026 at 3:14 PM Wei Lee <[email protected]> wrote: > > Thanks Jarek for sharing such valuable background information, particularly > concerning the legal aspects, which we hope we won’t need to delve into. > > Reading through, I think we have a consensus on the process, but let me > rephrase it a bit. > > --- > > ## How to submit an AIR rule to Ruff > > 1. Begin the voting process or initiate a Lazy Consensus regarding migration, > deprecation, or any other issue where there is strong community agreement. If > someone opposes the decision, we can revisit the discussion and hold another > vote. > > 2. Once the vote or Lazy Consensus is approved, create a pull request and > update the Airflow best practices documentation. At this point, the > development of Ruff rules can proceed concurrently. > > 3. After the pull request for Ruff is merged, ensure that the relevant > documentation is updated to incorporate the new Ruff rules accordingly. > > --- > > Will start another Lazy Consensus thread for this process and create a PR for > it > > Best, > Wei > > On 2026/03/08 12:35:17 Przemysław Mirowski wrote: > > 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] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > 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]
