Allow auto-formatting of the SQL queries in the Sequel-Ace Query editor #1534
Comments
|
Cool idea, currently the SQL formatter doesn't work at all in the latest macOS so fixing that should probably be the priority first |
|
This issue has been marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Bad Bot. We still need this. |
|
This issue has been marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Bad Bad Bot. We still need this. |
|
@rpai9 What's the point of keeping an issue open like this that doesn't seem to have any passion from the community for someone to develop this change? I understand that you need this feature, and I'd happily review a PR from you to add it, but what's the point of keeping this issue open if it seems unlikely anyone implements it? |
|
I don't have a stake in this particular issue (it's not a proposed feature I feel strongly about), but I'm in favor of not auto-closing issues. It's frustrating to have a robot determine the fate of something you care about – I'd prefer it if the stale bot assigned a label and left it at that. Here are some of the reasons I think it's worth keeping issues open: First, closing an issue usually indicates that it's been resolved – either by a code change, or by an intentional decision that it should not be fixed (ideally by consensus). If a person finds the closed issue, they should be able to read through the conversation and find its resolution. An issue without a resolution is an open conversation, and closing it without proper formalities is like closing a conversation without saying goodbye. I don't think there's anything wrong with keeping an unfinished conversation open for someone to participate in a couple of years later. Second, closing an unresolved issue leads to duplicate issues (the same issue being logged multiple times). Closed issues are hard to find. They don't show by default when searching, and even if a user knows that they can search closed issues, they may not bother, because it's reasonable to assume that closed issues are resolved, and if they're seeing something currently in the app, it must not be resolved. Third, closing an unresolved issue may prevent a potential contributor from finding the one issue that might have interested them enough to contribute a pull request. We don't know which issues will pique a potential contributor's interest, and we have no guarantee that the potential contributor will stumble onto the project within a month or two of the issue being opened. Leaving issues open increases opportunities to connect potential contributors with the project. Finally, closing an unresolved issue can cause a loss of community knowledge that's still relevant. Issue conversations may contain workarounds, proposed solutions, or steps to reproduce issues that may have have come after a significant amount of users banging their heads against the wall. If the issue is closed and forgotten, the next person who reports it may have to start from scratch. It can be overwhelming to look through a large unfiltered list of open issues, but GitHub provides sorting and filtering tools that can help. Labels can be used to indicate issue types, statuses, or sections of the app. Milestones can help group issues together when there are specific goals. Having clear titles for each issue can also be helpful, maybe using standardized prefixes. GitHub doesn't provide a priority field, but a potential contributor can sort the issues by number of thumbs-up emojis to get a rough idea of which features are most important to users (I just learned about this today!). By mentioning the above tools, I don't want to imply that the project leads aren't doing a good job at keeping the project organized. I think you're doing a great job, and you spend more time keeping the project running than any of us. You also interact well with the community, keeping conversations respectful and encouraging participation. But I'm in favor of anything that makes the project more welcoming to contributors and potential contributors, and stale bot can be frustrating. :) |
|
Hey there, @samuelbradshaw - thank you for the thoughtful and detailed response. You make some great points here. I've said this a few times, but Stale bot is really here to mark issues stale that have little passion in the community. An issue being marked stale definitely doesn't mean it's not important - but it means that there doesn't appear to be interest within the community to make a feature/fix happen. We all, as you're well aware, work on this project for free - nobody gets paid. Things only get worked on when there's passion around them and someone willing to do that work. I think stale bot comes from an understanding that having issues sit open in the issue backlog makes it harder for issues with broad scope/passion to stand out and get the attention they deserve. I hope this doesn't come across as not caring about users in any way. The very fact this project exists is because a few folks got tired of all the bugs in Sequel Pro and decided to fix them for themselves and everyone else. Right now, so few members of the community are contributing code changes it really lies on just a few of us to make changes happen. If I have ten minutes to work on Sequel Ace, I don't really want to spend those ten minutes sorting through issues and trying to find ones with passion and lots of impacted users - I want those to jump right out to me so I can get them fixed. I really think a key message to everyone ought to be if you have passion about an issue, please please please take a stab at fixing/addressing it. I love reviewing PRs - I'll review any pull request to Sequel Ace, that's been my pledge since day one. But I really don't have the bandwidth myself to fix every bug and add every feature that people want. Unfortunately, free, open source software just doesn't come with the same professional support that a paid product is expected to - we all have day jobs and families that have to come first. I do agree there are flaws with stale bot. But having a thousand issues instead seems far worse of a result to me than some issues with only a few users impacted getting closed prematurely. We can also re-open issues if there is additional info provided at a later date. |
|
@Kaspik I'd love to have you weigh in on stale bot here if you have any thoughts. I feel like I've spent a lot of time lately responding to concerns about stale bot and would definitely love to hear the thoughts of the whole @Sequel-Ace/all crew about it. |
|
I think the best way to see which issues users are most passionate about is by sorting the open issues by number of thumbs up reactions: Unfortunately, the number of people who are passionate about an issue isn't proportional to the number of people who are able and willing to actually contribute code, and like you say, there are only a few. In saying that, I recognize that I'm one of those who's never contributed code (I helped a little with the current icon, but that was a couple of years ago). I'm mainly here because I use Sequel Ace every day and I'm happy to see it succeed. I hope that by sticking around I'll eventually be able to learn my way around a macOS code base well enough to contribute. |
|
I do think stale-bot is helpful in things that don't get any attention or label (most of the actual issues open get label which excludes them), but I've extended the days from 28 to 60. If any issue has no activity for more than 60 days and doesn't have any label about being planned (which I believe issues with reactions have), I think it's totally okay to close them and re-open if needed. |
|
@Kaspik I agree with you. Though I want this feature, I don't have enough time to contribute. Closing the issue. |
Allow auto-formatting of the SQL queries in the Sequel-Ace Query editor.
I think piggy backing on open source projects like PoorMansTSqlFormatter might the easiest way to implement this.
Screen.Recording.2022-08-12.at.10.53.02.AM.mov
The text was updated successfully, but these errors were encountered: