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]
