https://bugs.kde.org/show_bug.cgi?id=387259
--- Comment #10 from Francis Herne <m...@flherne.uk> --- > It's become increasingly clear (also thanks to that remark from Francis) > that you consider this project as your own play thing and don't care about > how outsiders (as in people still using other products) think about or (can) > use it. I don't think that's an accurate representation at all. I can't speak for anyone else, but I'm opposed to this feature /because/ it seems focused on the very small group of KDevelop-developers and wouldn't be of use to 'outsiders' (for the reasons I described above). People generally /do/ ignore things that they're entirely uninterested in (to the extent that it's possible; these things land in email inboxes and on IRC, and it takes time to determine if they're interesting in the first place). I'm not, however, uninterested in this suggestion; I believe the original idea would be actively harmful, and I wanted to explain why before you or anyone else spent more time trying to implement it. Similarly, when people comment on review requests they may or may not be interested in the feature itself, but everyone cares about the state of the codebase and thus can have an interest in the suggested code changes. Some personal suggestions on why I think you're having trouble getting things accepted: - Some of your suggestions only address problems found on macOS; or in extreme cases only when using unusual build options (OSX, Apple-supplied libraries) on macOS. Thus the issues don't resonate much with other developers, which you can't really avoid except by explaining them clearly. - The scope and impact of your suggestions can seem very disproportionate to the benefit, especially when combined with the above. I think everyone working on the KDevelop codebase finds large parts of it to be overengineered and overcomplicated, and adding to that for things that only help a tiny proportion of users is a hard thing to sell. - Several of them are workarounds for problems that should be solved in other ways or upstream - the UI and other interfaces are already confusing to 'outside' users (and me...), so we should focus on making the existing features solve more problems and be more intuitive, rather than adding extra ones that interact with them to produce your desired behaviour in your specific use-case. Again, this is the /opposite/ of focusing on "inside" users. Sometimes you just seem to shoot yourself in the foot here -- for example, I really like your diff-context setting, which has a variety of uses and is intuitive to everyone. But you presented it as an unintuitive means to workaround Phabricator's buggy branch-matching - a problem that mainly affects KDE developers, and should of course be fixed in Phabricator instead - and I get the impression that set off Milian's "silly workaround" filter. So, if you want my advice: - Think about whether a suggestion makes sense for anything outside your specific usecase, and whether it's patching over a deficit in another feature that should be fixed instead. Test whether the problem you're solving is actually the one you believe it to be. - Try to find a solution that adds as little UI (including things like this proposal, not only buttons) and code complexity as possible. Again, the best way is likely to fix, improve or extend existing things. - Explain clearly about how you thought about the first two things, and which approaches you've excluded. Which problems does this solve and for whom; why is this the simplest solution (for users and/or for code). If you feel the need to write "I believe..." or "It's very probable that..." about the code, you've probably missed something above. - Try to be a little less verbose, and structure your posts clearly. It's not a writing competition, you can and should use lists instead of full paragraphs. This may seem like a personal complaint or pointless bikeshedding, but I do find your posts in particular to have a low information-density and be hard to read - they're more like a narration of your chain of thought than an explanation of the resulting points. Anyway, good luck, and happy hacking... -Francis -- You are receiving this mail because: You are watching all bug changes.
