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