-
-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clipboard isn't perfect #95
Comments
why not just make something new? because clipboard isn't gaining much PRs, issues and stars. |
For me, I'll take the first option. If a repo has stars more than 500 or 1k, I'll consider it as something that is worth a try. Small number of issues and PRs means maintianers are active on this, and I prefer such repos because I can get quick feedback, fixed or not, rather than waiting for an issue to be replied for weeks or even months. Many repos are like that, and I end up quiting reluctantly. Meanwhile, Clipboard is not with complex functionalities, just a small widget I think. So just keep it simple, with less issues and quick feedback. If you want more issues to keep a repo more "active", make a new one, with more functionalities. |
The tricky part is that Clipboard does actually do some funky/advanced stuff under the hood to get everything working, so it's a wonder how there aren't more issues because there are so many moving parts. However, I can see where you're coming from, as Clipboard right now just has the basics. Hopefully there should be some more advanced features coming soon. I'm thinking once the macOS tests are fixed, the next items for the todo list are to add the |
Cute |
Why do you require following checks on bug reports?
You don't accept bug reports from downloaded binary? Or in case you are, it's not clear from this check-boxes... |
Those two checkmarks verify that you aren't reporting an unrelated compiler issue because we can't fix those. LTO errors sometimes crop up due to various compiler changes and there's no good way to get rid of them other than disabling LTO altogether. C++20 support is also something that we can't fix as Clipboard only adheres to the C++ standard (see #86 (comment)), so it's really a compiler/OS issue. All of this verifies that only real problems with Clipboard show up in Clipboard Issues. |
Fix for build-clipboard.yml
|
This fixed FreeBSD, thanks! I thought it was an issue with Cross Platform Actions but I guess not. |
Tried to find suitable version for freebsd 13.1 using https://freebsd.pkgs.org/13/freebsd-amd64 |
Good comment. However, the number of closed PR and issues are literally at the top of the issues tab. Maybe someone would think it's because it's unused, but if that was the case there were none closed issues. 👍 |
I think Clipboard has the most user friendly defaults and features, what I have to do with |
You can actually get even simpler than this, |
It turns out that making one issue isn't enough: there's actually more activity if there are multiple issues in the queue. This is an example of the bandwagon fallacy, where people tend to think something is better if it looks like it's popular. It's also more proof that we aren't living in a meritocracy or else none of this behavior would happen in the first place. |
This is a great project, unifying command based clipboard managing across platforms (and, for Linux, even within: X11 versus Wayland!). Congratulations, developer! I wanted to comment on the aspect of visibility of the project: while the name "Clipboard" is very clear and straightforward, the generic name hinders the project from standing out. It is, for one thing, impossible to search for information (third party blogs, video's, etc). |
I thought about this, and I'm also sad that I didn't think of a better name. However, something that has helped is exclusively branding "Clipboard" as the "Clipboard Project" and using "CB" as the short name, since that's what the binary is and is more distinct. Therefore, if you want to search for info, try "cb" and that should work better than "clipboard." |
This isn't an issue with Clipboard, but rather one of humans in general.
Consider this. If you look at some repo, your eyes might look at the number of Issues and Pull Requests first. If you then notice that this repo has zero issues and zero PRs, what do you assume? There are two potential cases here. The first is where most/all issues get quickly resolved and PRs get quickly resolved too. The second is where nobody has bothered to make any issues or PRs because nobody is using the project. Us humans tend to default to the second option.
Unfortunately, Clipboard falls into the first case. Most issues are quick fixes, some aren't actually issues with Clipboard but rather some underlying standard (so we can't fix them), and the rest do take more effort to fix. The end result of this is few to no issues or PRs, which gives false credence to the second case.
So, the purpose of this issue is to inform you of this psychological phenomenon and to keep at least one open issue in the queue.
The text was updated successfully, but these errors were encountered: