being part of an interconnected commons is good actually god forbid we shirk a false sense of independence for even a moment https://mastodon.social/@dabeaz/113318518803522463

d@nny "disc@" mc²

@aud reading the source code (often by cloning the repo) is my secret weapon. so often i'll end up forking slightly and then either contribute my changes back if i really need them or often i can figure out how to avoid them and go back to using a published release

d@nny "disc@" mc²

@aud this is how my signal work started lol

Asta [AMP]

@[email protected] ooooh, I should consider doing a fork more often. That's a good idea. I often read the source code, too, to see how they implement things and how the data is moved about and manipulated in their code.

d@nny "disc@" mc²

@aud also making docs changes!! see e.g. https://github.com/rust-lang/regex/pull/861

d@nny "disc@" mc²

@aud but then see how later upon discussion i found regex-automata wouldn't work for my use case! https://github.com/rust-lang/regex/discussions/1167#discussioncomment-8585027

Asta [AMP]

@[email protected] I really need to be more active with the libraries and things I use. I've had a number of bad experiences involving PRs and questions in the tech world to where I tend to just use the software as is and work around it or ditch it, if necessary, without even thinking about the possibility of making fixes/suggestions/etc. I just assume they'll brush me off, which... well.

Still, just because it's happened a lot before (and in a job setting) doesn't mean it's always going to happen or that I should let myself be held back from contributing or becoming involved. Blehhhhh.

Asta [AMP]

@[email protected] I really need to be more active with the libraries and things I use. I've had a number of bad experiences involving PRs and questions in the tech world to where I tend to just use the software as is and work around it or ditch it, if necessary, without even thinking about the possibility of making fixes/suggestions/etc. I just assume they'll brush me off, which... well.

Still, just because it's happened a lot before (and in a job setting) doesn't mean it's always going to happen or that I should let myself be held back from contributing or becoming involved. Blehhhhh. I guess I'm a little shy about it due to PRs sometimes being used as a gatekeeping method. It's like, I just spent weeks on this, and I don't necessarily want to go through the PR process only to find that nothing I do will be good enough for them to accept not because of the work, but because of... well.

d@nny "disc@" mc²

@aud oh yeah i mean worst case i just fork it. nobody mentions that forking is not remotely as difficult as maintaining the base software bc you can pull in their changes except for the parts you need (this again is how i have been doing my signal work, and how i was going to do the zip crate until the new maintainer started accepting my changes)

d@nny "disc@" mc²

@aud my pip PRs have taken many months to get in (multiple years in some cases) but i think they're still good so i'm doing the work and getting community buy-in to accept them but rejection is always a possibility and if it's not worth your time then that's their loss and you make your own fork, or rewrite from scratch, or contribute to a different project. pip maintainers fucking rock and are terribly reasonable (they just have very little free time) so i have no problem continuing to push for stuff to get in

d@nny "disc@" mc²

@aud however i also feel that people often misinterpret maintainers saying "i need these changes to be made" as a rejection instead of a polite request to make the code easier to accept as part of the natural back-and-forth of contributing code that the maintainer will have to maintain unless you have already established yourself as a maintainer who can be trusted to fix issues that come up

Asta [AMP]

@[email protected] I definitely agree. I usually consider those positive PR cases (and have definitely had them, for the record!) and differentiate between when you do everything they ask and... well, I'm also talking in a work context project, where they start "nitpicking" things that you've seen them completely ignore in PRs from other people. Or do themselves. In the code. Or even try and "nitpick" something that pops up in the PR that is literally you emulating the style of code they've had.

Asta [AMP]

@[email protected] (or in one case, literally "nitpick" something they did that happened to show up as visible in the code preview of your PR because they're clearly barely reading it).