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] > > > > >
