21–30 of 245 posts
A lot of their comments seem justified though and it looks like you were learning a lot from it as you mentioned it was your first rust merge. Also a lot of the delay was because you didn't have time to work on it as you mentioned in 2019 :) I'm not a developer but I read through the thread to see what it's about. But I think most comments were constructive criticism or just non blocking suggestions even. Though code…
I used to use kitty, but its CPU usage was on the higher side on my laptop. I tried alacritty but the lack of tabs (after using kitty for a long time) was a deal-breaker. I'm currently using Wezterm[1], another rust-based terminal, which has tabs. It's worked great for me so far. 1. https://github.com/wez/wezterm
I think many developers treat PRs as an opportunity to gatekeep. I'm not a very politically correct or emotional person but I think gatekeeping/nitpicking is extremely demotivating and it should be avoided wherever possible. When I review PRs, I'm looking at the big picture. I'm looking to see if it introduces security issues or diverges from standard practice. I don't care if there's a slightly better way which redu…
I think a lot of people treat the merge of a PR as their god-given right. Because they spent time on it. But if they spent the time without discussing with the maintainer first, why would they be obliged to merge it ? It is like spending a ton of money on a big, bulky, but useless to a recipient present, giving it to someone and then complaining that they don’t take it - you had spent all this money! The way out of t…
I've never seen this at work or in open source, and I've done quite a bit of open source. Contributors will get frustrated if their PR is simply ignored and I think for good reason. But I've never seen anyone say or even imply that their PR must be merged.
Of course, if it's too strict then people will stop contributing entirely. But if it isn't stright enough then the project can suffer from bloat and a lack of a unifying vision.
This becomes less of an issue if there's some level of expectation management involved. e.g. here is what we would like contributions for, here are things that we won't, and if you're unsure about any of it, open an issue about it before investing all your time and effort.
But from sidelines, I find it ironic that a project whose name is a play on the word 'alacrity', meaning "cheerful readiness, promptness, or willingness", is earning criticism for its plodding perfectionism & willingness to say 'no'.
(Maybe users/contributors are subconsciously applying a higher standard via the connotations of its name?)
“They don't want to merge my code with unsafe and I can’t prove it's actually safe”. 2 examples extrapolated to the whole community and language. Is there any particular reason to resurrect it from 2020?
Please don't ever post things like this. If you're this frustrated that the people who make free things for you aren't donating their time to you in the way you'd prefer, grab a drink with a friend and vent to them in private instead.
A lot of their comments seem justified though and it looks like you were learning a lot from it as you mentioned it was your first rust merge. Also a lot of the delay was because you didn't have time to work on it as you mentioned in 2019 :) I'm not a developer but I read through the thread to see what it's about. But I think most comments were constructive criticism or just non blocking suggestions even. Though code…
A PR is a gift and a burden. A gift of someone else's effort to contribute and push something forward. A burden because once received, future maintainance of the gift is really on the one who received the gift. It may as well be the gift of a kitten... you now have to look after the kitten for the next 12-15 years. Is it socialised? House-trained? How much effort does this take when there are also gifts of other anim…