ktlint has become too opinionated

[meyertime]

The direction ktlint has been taken the past couple years has removed it from the needs of the community and alienated some of its users.

Previously, ktlint aligned with the official style guides. Now, the default code style, ktlint_official, is opinionated and conflicts with and exceeds the official guides. Since the guides no longer serve as an anchor, this default style ends up reflecting the personal opinion of the maintainer. Issues #2138 and #2423 are good examples of this, because the changes proposed have strong community support, and they are aligned with both official style guides, yet they have been refused.

The intellij_idea and android_studio code styles may be used for those who don't agree with the opinionated ktlint_official style. However, there are some problems with this:

1. The default rules for ktlint should more useful than one person's opinionated style.
2. The intellij_idea and android_studio styles have become second-class features. Opinionated additions from ktlint_official have crept in, and these styles no longer align with the official style guides. With each new release, an additional rule or two has to be disabled to maintain alignment with the official guidance, and doing so may cause ktlint not to enforce what the official guide does say in some cases.
3. The principles of the project currently include minimizing configuration options, so it is unclear how long existing workarounds will be available, or if new workarounds will be accepted.

It's true that the original stated vision for ktlint may have included zero configuration in order to prevent "bikeshedding" about lint rules. In recent years, the direction of ktlint has leaned heavily into this, desiring minimal configuration and consistency to the point of determinism, even at the expense of code clarity and readability. However, an opinionated, deterministic linter with no configuration options, ktfmt, already exists for Kotlin. We don't need another one. Also, ktlint has gradually added some configuration options over time due to demand from the community. It's clear that people use ktlint because it is not deterministic and is configurable, so the stated vision and direction of ktlint should be adjusted to align with this.

Therefore, I am proposing the following course correction for ktlint:

• Re-brand ktlint as a community-driven, unopinionated, configurable linter, in the spirit of ESLint.
• Remove the ktlint_official style.
  • Its rules may be kept as configurable options.
  • No opinionated style that exceeds the official style guidance will be offered.
• Restore intellij_idea and android_studio back to official and android, with official the default.
  • Bring these styles back into full alignment with the official style guides. Under default configuration, they will enforce only what the official style guides say, no more, no less.
  • Any question as to what these styles should do by default will be decided by a review of the respective official style guide, not the opinions of the maintainers or contributors.
  • If the official style guide is not clear on a particular matter, then the default will be not to enforce it either way, but it may be implemented as a configurable option.
  • There will be no requirement that these styles be compatible with the built-in formatter of IntelliJ or Android Studio. At best, these are flawed implementations of the official style guides; the official guides are the standard we will measure by.
• Bump the version to 2.0 and remain pre-release (alpha, beta, release candidate) until all of the above are completed.
• Embrace configuration.
  • The code styles will be sets of default configuration for a common set of configurable rules. Users will be free to adjust from there.
  • If a configuration option is desired by the community, it will generally be accepted as long as it is not the default, though the maintainer may choose not to implement it, but rather encourage opening a PR.
  • Those users who want ktlint to enforce a more opinionated style can achieve this by configuring rules or enabling additional ones.

If you agree with this proposed course correction, show your support by reacting with 👍. If you disagree, react with 👎. If you have a suggestion to improve this plan, please leave a comment.

EDIT: If you look further down in this thread, we have reached a compromise. Configurability will allow users to customize the styling enforced by ktlint, and that will be my focus. The existing code styles will remain as they are so as not to affect indifferent/happy users that are just using the defaults.

[eygraber]

If you agree with this new direction, show your support by reacting with 👍

@meyertime I think it might be more clear to say "If you agree with this course correction", because otherwise it could be read a little ambiguously; new direction could mean the course correction you proposed or the new direction that ktlint is currently headed in.

[meyertime]

Good point. Updated.

[shashachu]

Thanks @eygraber for pointing out this issue in the kotlinlang Slack. I think the fundamental tension is the been lack of general ownership and support of ktlint, which we (Pinterest) should absolutely take responsibility for, as we have 'owned' the project in name only for quite some time.

When we took over ktlint years ago there was a robust community of contributors (myself included) and for various reasons, we all stopped putting time into ktlint.

@paul-dingemans has essentially single-handedly kept the project alive since then, spending what is likely hundreds of hours of his own personal time, and I want to acknowledge his enormous contributions to the project. As a result, it has become a single-maintainer project not really by design, but because he's the one putting in the vast majority of the work into the project.

@meyertime I completely understand and acknowledge the frustration you're feeling; I do want to say in general that 'software by committee' is not a long term way to keep a project healthy, and that likely Paul is trying to strike a proper balance between the general principals of the project and trying to glean what the community at large wants. Let's in general try to avoid veering into the direction of personal attacks.

For #2138 in particular, I would also consider this a regression, as we use this formatting in our own codebase. I think most Android developers would as well.

I would be open to adding another maintainer or two (I suspect Paul will as well), and I would personally like to have someone who works primarily on Android, as that's obviously a huge proportion of the Kotlin userbase.

[meyertime]

Thank you, @shashachu, for your thoughtful response.

I agree that "software by committee" is not good long-term, and that isn't my intention here. I am also trying to gauge what the community wants and find out if many agree with me or if I am an outlier. I have seen some response here and in other forums that suggest that I am not the only one who is frustrated with the direction of ktlint.

Part of the problem is that I disagree with "the general principles of the project". As I described above, I think ktlint diverged from its stated vision in order to meet the needs of the community by becoming configurable and thus less opinionated. Then, Paul started to bring it back to those earlier stated principles. I think it's better to continue to meet the needs of the community and adjust the principles accordingly.

I also think the nature of linters in general is that they naturally reach a state where they are more or less "done" and do the job they're intended to do. At that point, it's just a matter of keeping up with any new language features that get added. I feel like ktlint got to that point before ktlint_official was introduced, which may explain why people stopped contributing. I don't think ktlint_official was born out of a need from the community.

At this point, I'm prepared to contribute as much as I can, but I'm not sure adding another maintainer would help if the maintainers don't agree on the principles. So I'm also trying to gauge if we can strike a balance or if it's time to fork.

[shashachu]

@meyertime Forking in my opinion is a 'last resort' option and would probably be a worse outcome for everyone including the community, so I think we can come to a compromise. I agree with you that 'anti-bikeshedding' has largely been aspirational even from the beginning with ktlint, and it is true that ktfmt exists now as a Kotlin linting alternative and has a very different implementation.

Would codestyles be a 'middle ground' here? Is the sticking point that you want to use ktlint_official due to it being the default? Perhaps it can be renamed ktlint_strict if that's the intention. I agree with you that idea and android should closely align with the recommendations of those groups, so I'd also say we shouldn't have style-creep into those groups that conflict with IDEA and Android. It can also be difficult to have 100% alignment with those styles so we only have to guess about changes, or closely follow the commits going into their plugins.

I'd like to give @paul-dingemans a chance to respond here as well. I'm happy to also chat more real-time in kotlinlang, although I believe time zones might make that more difficult.

[meyertime]

@paul-dingemans I just want to say that none of this was meant as a personal attack. Please understand that it is hard to be critical of the direction ktlint is going without being critical of the person who has been singlehandedly maintaining it. I edited this issue and made an effort to soften the language and focus more on the problems I see with ktlint. I am sorry that my frustration came out with it initially.

@shashachu I will respond to your questions soon. In the meantime, I did try to get into the Kotlinlang Slack yesterday, but wasn't able. Something about not having a jetbrains.com email address. Any ideas?

[eygraber]

I've been using ktlint for a long time. Originally through the detekt ruleset, and more recently directly through the ktlint binary.

I agree with everything that @meyertime said. My list of disabled rules keeps growing, and my requests for bug fixes and new features are summarily dismissed.

I think detekt is a good project to look up to in terms of configuration (as well as many other things). There's very sensible defaults, and the freedom to adapt it to your project as needed (within reason).

I would love to see that level of freedom in ktlint, as well as an easier way to write rules (again following detekt).

@meyertime have you tried http://surveys.jetbrains.com/s3/kotlin-slack-sign-up

[meyertime]

@shashachu

Forking in my opinion is a 'last resort' option and would probably be a worse outcome for everyone including the community, so I think we can come to a compromise.

Agreed!

Would codestyles be a 'middle ground' here? Is the sticking point that you want to use ktlint_official due to it being the default? Perhaps it can be renamed ktlint_strict if that's the intention.

I question the usefulness of including an opinionated, unconfigurable code style, especially when ktfmt exists. But more than that, I believe its inclusion causes more harm than good. For one thing, since there is nothing underpinning ktlint_official, such as an official style guide, there is no basis to decide what its rules should be. It fosters threads that spin in circles and don't go anywhere, because it's just one person's opinion vs. another's. Then, since additional configuration options are to be avoided, the issue can't be resolved that way either. Last but not least, the fact that it's the default and blessed code style causes intellij_idea and android_studio to take a back seat, and they don't get the attention they need. Plus new users are likely to start with the default settings, and when they see wonky results, which is more likely the more opinionated the rules are, they are more likely to open issues and start arguing about it, or just not use ktlint if they don't know about the other styles.

If ktlint_official is kept, then it should at least be made less opinionated, and there should be something underpinning it so that disputes can be resolved. For example, perhaps some combination of the two official style guides (such as, "only rules that appear in both style guides", or "all rules from both guides unless they contradict each other").

I agree with you that idea and android should closely align with the recommendations of those groups, so I'd also say we shouldn't have style-creep into those groups that conflict with IDEA and Android. It can also be difficult to have 100% alignment with those styles so we only have to guess about changes, or closely follow the commits going into their plugins.

I'm glad we agree on this. Getting intellij_idea and android_studio to align with the official style guides would be huge! I could certainly help by identifying the ways in which they don't, opening issues, and potentially contributing fixes. Well, at least for android_studio, since the project I'm leading is an Android app, and that's the code style we're using.

This brings up another issue. Historically, official and android were compatible with IntelliJ's built-in formatter, in addition to trying to follow the official style guides. This was a pain point for @paul-dingemans, and he mentioned it as one of the primary motivators for ktlint_official. It also explains why these were renamed to intellij_idea and android_studio. I think it would have been better to just drop that requirement from official and android and focus only on the official style guides than to introduce a third more opinionated style. Or, alternatively, to have 4 styles: intellij_idea and android_studio match IntelliJ's formatter, while official and android only the official style guides. But that may be a bit much.

Finally, there's the issue of configurability. All of the problems with code styles would be a moot point if the rules were configurable. Then code styles would just be different starting configurations. We wouldn't have to argue about it, we could just configure ktlint to our liking. I know that configurability will require careful thought and plenty of automated tests to prevent regressions, but it has been done successfully and sustainably in other linters. The heavy resistance to configurability is giving us fewer options for resolving issues.

So, in summary, if I were to rank my sticking points:

1. Getting intellij_idea and android_studio aligned with the official style guides
2. Embrace configurability (within reason, of course)
3. ktlint_official not gumming up the works

[meyertime]

@eygraber Thanks for the Slack sign-up link. I filled it out, and I'm waiting for a response.

Also, thanks for the additional context. Full disclosure: I am relatively new to ktlint. Added it to our Android project 13 months ago. So my knowledge of ktlint's history is based on research, not experience. I'm not new to software development, though.

[paul-dingemans]

Forking in my opinion is a 'last resort' option and would probably be a worse outcome for everyone including the community, so I think we can come to a compromise.

Agreed!

Forking the project will not only harm the ktlint community, but all the API Integrations and possibly the Ruleset Providers (like compose-rules) as well. Each of those projects will have to decide what they will do. Follow the original project, or the fork, or both.

I find it questionable that you make it sound that only my personal opinions are leading in this project. Of course, my personal opinion has had great influence on this project. This was not by design or intentional, but a consequence of a community which is not responsive enough to get accurate insights on future developments of the project. I have tried to reach out to the community before making changes. I have raised issues in the Github project and advertised for this in the Slack channel. The amount of responses was negligible. For the investigation regarding formatting the when-statement, I have used LinkedIn to gather feedback which worked surprisingly better. This feedback resulted in implementing a different default choice for formatting the statement.

Previously, ktlint aligned with the official style guides. Now, the default code style, ktlint_official, is opinionated and conflicts with and exceeds the official guides. Since the guides no longer serve as an anchor, this default style ends up reflecting the personal opinion of the maintainer. Issues #2138 and #2423 are good examples of this, because the changes proposed have strong community support, and they are aligned with both official style guides, yet they have been refused.

The code styles android_studio (previously android) and intellij_idea (previously official) already did not align fully with the originating style guides from the moment that I joined the project. Some rules of the Androids Kotlin Style guide leaked into the intellij_idea implementation. Same for rules of the Kotlin Coding Conventions have been leaking into the android_studio implementation. Sometimes they directly conflict with the guideline. Did you know for example that the default indentation of the ident type of android_studio is a tab while the (current) style guide explicitly declares not to do so?

The point that I want to make with above, is that style guides are not more than a guide. On a lot of details they are quite specific. On some points (trailing comma's) they explicitly leave it to the discretion of the developer to pick something reasonable. And, on other topics the guides do not mention anything at all. The kotlin_official code style attempts to fill in the blanks between, and left open by the Androids Kotlin Style guide and Kotlin Coding Conventions.

Occasionally, I have tried to get more clarification about the Kotlin Coding Conventions by submitting an issue to the Jetbrains issue tracker. In issue, Roman Elizarov remarked:

Our Kotlin style guide tries to be as simple as possible. We don't have a goal to exhaustively specify how exactly everything should be named and laid out. We are only making recommendations.

A 'new' language feature like context receivers has still not resulted in an update of the style guide as of today. Should any request for formatting regarding such features be denied as no reference to it is found in the style guides?

I think that the value of ktlint, and especially the ktlint_official code style, is to be more specific than the guidelines as it results in more consistent code throughout a code base. Would you be willing to scrutinize every line of code in ktlint to make it 100% fully compatible with the guidelines? Do you really think that if you would succeed in that, that it makes all ktlint users to be more happy?

Let me clarify this with an example. Androids Kotlin Style guide explicitly defines a maximum line length of 100 characters. The Kotlin Coding Conventions does not specify any rule about it. In ktlint_official code style this has been merged into setting a default of 140 (yes, this is an opinionated value) characters. If android_studio code style would be 100% compatible with the Androids Kotlin Style guide, this would mean that you also need to remove features that allow single strings to pass the max line length.

There will be no requirement that these styles be compatible with the built-in formatter of IntelliJ or Android Studio. At best, these are flawed implementations of the official style guides; the official guides are the standard we will measure by.

I am glad that we agree on this. The ktlint_official code style has dropped that requirement explicitly which was needed to resolve bug reports from the community. As users of the android_studio and intellij_idea code style would still complain about code being formatted differently by ktlint compared to Intellij IDEA formatter, there was no other way than to create a new code style. But dropping this requirement for android_studio and intellij_idea will once more upset users.

The intellij_idea and android_studio styles have become second-class features. Opinionated additions from ktlint_official have crept in, and these styles no longer align with the official style guides. With each new release, an additional rule or two has to be disabled to maintain alignment with the official guidance, and doing so may cause ktlint not to enforce what the official guide does say in some cases.

I disagree with the labeling intellij_idea and android_studio code styles as second-class features. When I write new rules, I am aiming to get them working in all code styles. In case such a rule is an addition on top of Androids Kotlin Style guide and Kotlin Coding Conventions they are enabled by default only in the ktlint_official code style. An opt-in in the other code styles is possible. This is totally inline with your vision that additional rules should not be added to intellij_idea and android_studio if this is not founded in the corresponding style guide.

If somehow functionality which is intended for ktlint_official has crept into code formatted with intellij_idea or android_studio that may be marked a bug. However, if you use intellij_idea or android_studio code style, and you have enabled a rule which by default is only enabled in ktlint_official than this should not be considered as a bug as the user explicitly decides to leave the path of one of the predefined code styles.

The principles of the project currently include minimizing configuration options, so it is unclear how long existing workarounds will be available, or if new workarounds will be accepted.

Minimizing the number of configuration options is born out of necessity. Lots of people just seem to assume that each of their favoured enhancements have to be built into the project. Often people than suggest to put the functionality behind a configuration setting. Although that can be helpful, it has the downside of introducing a lot of complexity. Not because of adding some conditional logic, but due to the (combinatorial) explosion of execution paths that result as of it. The least harmful configuration options, are the options which are related to numeric values like tab size, and number of parameters in a function before to start wrapping), and I have no real objection to those. Most harmful configuration options are the enumerations like code style, and function body expression wrapping.

Removing existing configuration settings, and changing default settings (for example the indent style in android_studio) is nearly impossible. It will upset lots of developers, and resulting in more maintenance (handling issues) compared to the benefits. Introduction of new configuration options is a possibility, but is not one that is taken lightly. In the same way, you do not have to fear that I will ever suggest to drop the code styles android_studio or intellij_idea entirely.

Since the guides no longer serve as an anchor, this default style ends up reflecting the personal opinion of the maintainer. Issues #2138 and #2423 are good examples of this, because the changes proposed have strong community support, and they are aligned with both official style guides, yet they have been refused.

It is true that #2138 and #2423 have an unusual high number of participants that actively engage the discussion, and like or dislike comments. Even when every like or dislike of a comment would come from a unique visitor, those threads would count for 150 users. But it is more likely that some of those users have (dis)liked multiple comments resulting in less unique users that are voicing a complaint.

Ktlint has tens of thousands of users. The vast majority of those users are invisible from the viewpoint of the project. We have no metrics about the usage patterns. We don't know how many users use a specific code style. We don't know which rules are disabled. We don't know the number of users per version of the ktlint rule sets. This makes decision-making hard. Even with input of some active users the outcome of any decision is still opinionated.

What I do know from the ktlint-intelli-plugin version 0.22 (e.g. ktlint 1.2.1) is that it has been downloaded by 17,799 developers as of today. The '0.23.0' version of the plugin has been downloaded 4,659 developers within one week after its release. I expect that the total number of ktlint users (either via Ktlint CLI, the gradle and maven plugins, Detekt, Spotless) is a multiple of the number of the users of ktlint-intellij-plugin.

Active users in the ktlint project, including the Slack channel, typically have a question, an enhancement request, or they report a bug. They have an apparent reason to become active. Only some of them stay active for a longer period of time. The active users however miss a representation of users that are either satisfied with the project, or don't dare to raise their voice in public project regardless whether they like or dislike the project. How can anyone claim that they represent the entire ktlint community, and therefore should be listened to? I cannot claim to represent all ktlint users that are not active contributors or readers of this project issue. But neither can you claim that the active users in #2138 and #2423 do represent all users that wants this to be resolved in the way you propose.

As maintainer and guardian of the project it is my responsibility to balance the interests of all users as good as possible. I am trying to balance requests from the Android community, the non-Android Kotlin community, the API Consumers and Ruleset Providers. This means that android_studio code style is based on Androids Kotlin Style guide, and intellij_idea is based on Kotlin Coding Conventions. The ktlint_official code style combines the best of both guidelines, when necessary it extends those guidelines to provide a consistent code formatting experience.

Each user that raises or supports an issue like #2138 and #2423 is important, and should be listened to within reasonable bounds. If a request is not followed up to your satisfaction, the next step is to actively contribute a change by raising a pull request. We can negotiate about which solutions are acceptable to both of us.

@shashachu wrote:

I would be open to adding another maintainer or two (I suspect Paul will as well), and I would personally like to have someone who works primarily on Android, as that's obviously a huge proportion of the Kotlin userbase.

I would prefer so select maintainer only after there is a proven track record on the project. This would require regular (code) contributions, performing code reviews, participate actively in discussions on the issue tracker, and responding on questions on Slack. I am open to mentoring a potential new maintainer.

[ephemient]

Forking the project will not only harm the ktlint community, but all the API Integrations and possibly the Ruleset Providers (like compose-rules) as well. Each of those projects will have to decide what they will do. Follow the original project, or the fork, or both.

As somebody who maintains a custom Gradle integration for a private project, I'll just follow whichever one actually works for us. Sadly I have to say that there's been no value in the additions to the ktlint style for us.

[eygraber]

@paul-dingemans my conclusion from reading through your comments is that there are two options for moving forward:

1. Stay the course, and deal with the inevitable splintering and crumbling of the community
2. Embrace configuration

In this case configuration would decrease the current bike shedding problem:

1. @paul-dingemans wants to make a change
2. No one is interested in discussing it (I'll leave my opinions about getting feedback from LinkedIn to myself for now)
3. @paul-dingemans decides how it will work
4. Community doesn't like the decision
5. Community is "unable to convince @paul-dingemans that he made the wrong choice"
6. More discussion and anger about how another rule needs to be disabled and the direction of ktlint, etc...

The fact is you're going to have a hard time getting quality feedback for formatting features, because no one cares about it until it's breaking their project. Aside from the fact that feedback is just opinion anyways, and there will never be consensus on opinion based matters. There isn't even broad consensus about the Kotlin style guide's inhospitality to variance.

The only way to deal with that is by providing broader configuration options. Will it add complexity? Probably. Is it unattainable because of that? No, there are plenty of formatters/linters out there that work just fine while allowing a high level of configuration. Detekt is a prime example in the Kotlin community. They pick sane defaults, try to anticipate variant needs up front, and are open to adding configuration to address them as the community needs it.

[wakingrufus]

As the primary maintainer of https://github.com/JLLeitschuh/ktlint-gradle these days, I don't really have a strong opinion about ktlint_official vs intellij_idea. I use intellij_idea in my projects, but a single line in my .editorconfig to enable that is not something that bothers me at all. But that brings up one thing I want to point out: the trend toward using .editorconfig as the primary way to configure ktlint has reduced the complexity of using/integrating with ktlint, as well as made it easier to resolve those IDE/ktlint differences, when they do occur, without multiple sets of configurations. So kudos to @paul-dingemans for having that vision and moving in that positive direction. If a more "configurable" ktlint is the future direction, I hope to see it be implemented in the same way, and perhaps with coordination with JetBrains to develop shared .editorconfig properties that ktlint and ij can both use in a consistent way (meaning less ij or ktlint specific properties)

[wakingrufus]

I had one more thing to add: if governance of ktlint is being reconsidered from Pinterest's side, as @shashachu implied was possible, I'd suggest combining ktlint, klint-gradle, ktlint-intellij-plugin into a single GitHub org, then applying to become a member of CommonHaus (https://www.commonhaus.org/). Commonhaus has established some patterns and systems to help with community-project feedback loops, while not requiring projects adopt any specific pre-determined processes.

[skylerreimer]

I'd like to add a comment from the perspective of an indifferent/happy user.

I've used ktlint across several android related projects over the years and every so often it'll format my code in a way that is not expected. My current project has always been on the latest versions of the library. I usually shrug off the unexpected formatting and move on. I suspect a large chunk of users fall into this bucket. I would personally rather have a standardized rule set across all kotlin codebases than nitpick or add custom rules. It makes everything easier to read when we all have the same format. For these reasons I don't agree with the statement that a single maintainer will cause the community to crumble.

That said, it seems like Pinterest is loosely maintaining this repo and the primary maintainer doesn't even work there. This is a big and important project for many organizations. Grabbing an android focused maintainer and migrating this project (and related plugins) to a single github org seems to be a viable option if Pinterest isn't as committed as they once were to maintaining ktlint.

[meyertime]

Ok, well that answers that question. 😅 Yes, I will drive the change to make ktlint more configurable (assuming this experiment goes well as planned) and support it as a co-maintainer, responding to issues, etc.

I said what I did because I didn't want you to think I was trying to take over in a hostile sense. Forking would have been a last resort, and yes, I would have been fully responsible for it then. So I'm definitely willing to share the burden with you.

[meyertime]

In regards for long-term ownership of this project, I'm chatting with some folks internally on Monday to talk through our options. My personal goal and certainly Pinterest's goal is to keep this project healthy and active, whatever form that may take. I will share updates as I have them.

@shashachu I still think it would be good if Pinterest could help when it comes to getting good feedback from the community. I'm sure I will run into the same problem as Paul eventually. I am focusing on making the one rule configurable initially (#2138), but then there will be the question of what else should be configurable and what those options should look like, and I won't want to make those decisions unilaterally.

As it has been brought out before, people tend not to pay attention to ktlint until something goes wrong, so the feedback tends to be biased and not necessarily representative of the entire community. I don't know what the answer is to that, but perhaps Pinterest as an organization would have more resources to solve it than we as individuals do.

Thanks again for your attention to this.

[shashachu]

That was the theory in bringing ktlint into the Pinterest org, but the reality is that folks are just busy doing their full-time work, and I didn't have luck boosting engagement within the company. I was the only regular contributor within the company (I'm the Android lead) and even that fell off to the side over the years. That said, we've made no decisions about the eventual governance/ownership of ktlint, I just wanted to add a little bit of context.

[meyertime]

Thanks for the clarification. I can see what I can do within Target as well. Kotlin is used pretty extensively here. Though I may end up being the only contributor as well, but there are other teams I can try to get feedback from. I had a chat with my boss about what I've committed to for ktlint, and fortunately, he and Target in general is supportive of open source contributing.

[eygraber]

I think a "committee" might help here, where there's a group of people who are available to discuss rules, configuration, etc... That will hopefully solve the issue of no one contributing to the conversation until something goes wrong, as well as not requiring anyone on the committee to be active code contributors (if they don't want to be).

I think it would be nice if one+ of the detekt maintainers would agree to be on the "committee" since they have experience and expertise with these kind of things (cc @BraisGabin).

[meyertime]

I like it. Though we just talked about not wanting to do "software by committee". 😆 But we don't want design by dictator either. I think a balance is good. The leaders provide a unifying vision and ultimately decide, but with input from a committee of users to make sure it meets the needs of the larger community.

[eygraber]

That's why I put "committee" in quotes 😅

I guess it's more people who are dedicating themselves to be available for discussion.

[wakingrufus]

I think we have had very productive collaboration between ktlint and ktlint-gradle especially regarding API changes that might effect integration. I think @paul-dingemans has been very proactive and open in this regard. But this has mostly been via informal slack conversations on the kotlin slack. Maybe instead of "committee", we just need a dedicated space to have these discussions in a place that is easy for interested parties to find. Maybe the kotlin slack is that place or maybe there is something better.

[eygraber]

I think those conversations can and should happen in the open (Kotlin slack, etc...). The idea of a "committee" is only that there are people dedicated to responding.

[wakingrufus]

I think those conversations can and should happen in the open (Kotlin slack, etc...). The idea of a "committee" is only that there are people dedicated to responding.

Yes, in the open of course, but maybe there is a way to make it easier to discover, or to gather feedback, such as something like this: https://www.commonhaus.org/bylaws/decision-making.html

[eygraber]

I think the reality of the project is that at the end of the day, most users don't want to get involved in nitty gritty discussions about how their formatter works. So making it easier to discover or gather feedback might not matter as much because of that.

Personally, making formal rules seems like a bit much to me, but I'd be interested in hearing what others think.

[skylerreimer]

Just looking around at kotlin usage internal to Amazon, it seems like most teams set their ktlint version and never thought about it again. There's also almost zero people asking about ktlint in our internal support channels. I think the hypothesis that most people don't care about their linter after they set it up is true.

A strict feedback loop might make it hard to make changes if we think people are not interested in giving feedback.

[eygraber]

I think the hypothesis that most people don't care about their linter after they set it up is true.

Until it does something they really don't like 😇

[npouliquen]

Just looking around at kotlin usage internal to Amazon, it seems like most teams set their ktlint version and never thought about it again. There's also almost zero people asking about ktlint in our internal support channels. I think the hypothesis that most people don't care about their linter after they set it up is true.

FWIW, I'm in this boat. I'm at Amazon and use Kotlin. I was trying to upgrade my ktlint dependency a few days back, which brought me to #2138, as I was very unhappy with the result of that formatting. I agree with your sentiment. People just expect their linter/formatter to work the way they want. It isn't something that is top of mind until the output is something they greatly dislike. It's the only reason I came to this repo.

Gathering feedback is probably pretty hard for a project like this. I also don't know how important it is. If the road Ktlint is headed down is to offer more configuration, feedback becomes less important. Ideally, if folks don't like what the default behavior is, they can just change the configuration and it is back to what they like.

[meyertime]

If the road Ktlint is headed down is to offer more configuration, feedback becomes less important.

A fair point. Configurability may help in more than one way. It may reduce negative feedback from users who can't configure ktlint to their liking. Then, as you pointed out earlier:

Adding more configurability would also enable folks to share their configuration with others. This is something that developers clearly enjoy doing with other tools. Why not with Ktlint?

There may be more for users to talk about that isn't necessarily negative in the normal course of ktlint usage.

[BraisGabin]

I think it would be nice if one+ of the detekt maintainers would agree to be on the "committee" since they have experience and expertise with these kind of things (cc @BraisGabin).

I don't have the time for something like that, I can't give my long term commitment.

But I'm nearly always on at Slack. If someone thinks that what we have on detekt could help ktlint I'm open to answer DMs or any @me on public chats about anything related with this.

[paul-dingemans]

We have had fruitfull discussions here. But it is becoming a little messy with different topics being discussed. I have opened Github Discussion where we split the discussions per topic. Please keep on contributing via the discussion sections.

[bcmedeiros]

I've been using ktlint since way before 1.0 and to be honest I don't think the problem is necessarily becoming too opinionated, it's the pace and the way this is happening. We have more rules being created and breaking changes after 1.0 than before. I made a big effort on my previous project to iron out everything to 1.0, and it's been uphill from there.

I really thing being opinionated (or mostly opinionated) is not the problem, but rather where and how is the "opinion" being formed. We should put a process in place where things are discussed before a new rule that re-formats the entire project drops in the standard rule set (that is the experience for most people).

[paul-dingemans]

I really thing being opinionated (or mostly opinionated) is not the problem, but rather where and how is the "opinion" being formed. We should put a process in place where things are discussed before a new rule that re-formats the entire project drops in the standard rule set (that is the experience for most people).

This is really an important aspect of the problem. There is no active community around Ktlint that is willing to actively participate in discussions and testing before changes are implemented. Most people on the issue board and the ktlint slack channel only reach out after they experience problematic/unexpected behavior. Rules usually live for multiple releases in the experimental rulesets before being promoted to a standard rule. Only when an experimental rule has become stable, it is promoted. Given this low effort involvement of the community, what would you propose to make this work?

[bcmedeiros]

Sorry for the delay, was a few weeks off.

I propose we recruit some members in the community to compose a group that will be committed to experiment the rules before they are promoted to stable. I volunteer myself to belong to this group.

To be honest, on the pre-1.0 era, I was very active in testing releases as soon as possible and even had a project with all the experimental rules enabled. When 1.x was released, I assumed we would reduce the pace of new rules, especially breaking ones, so I lowered my guard substantially. I might have missed something, but in my experience ktlint has been "less stable" after 1.0 then before.

If we do create a group to triage new rules, I think we need to also commit to a minimum quorum for promotions, and that will potentially slow down the release cadence a bit. I don't think it's a bad things, my opinion, but interesting to know what others think.

Mu current situation is: I'm stuck on 1.1.1 and there are so many changes if I upgrade and I need to break it down, figure out what I need/can disable to move forward. I'll digest this and provide more fine-grained feedback.

[paul-dingemans]

I propose we recruit some members in the community to compose a group that will be committed to experiment the rules before they are promoted to stable. I volunteer myself to belong to this group.

You're welcome to try-out the experimental rules. Typicall I keep an experimental rule at least two releases as experimental to get them stable. But as we have to few users running with experimental rules, feedback typically is only received after promoting the rules to stable.

Currently there are only 4 experimental rules left (https://pinterest.github.io/ktlint/latest/rules/experimental/), and there are almost no new rules planned or being build.