Debian discusses Discourse
Debian discusses Discourse
Posted Apr 18, 2020 4:08 UTC (Sat) by pizza (subscriber, #46)In reply to: Debian discusses Discourse by berndp
Parent article: Debian discusses Discourse
For the F/OSS projects I'm active on these days, the barrier of entry is steep indeed; not because we eschew "modern" pull-request github contributors, not because we rely on "archaic" mailing lists for correspondence, but because in order for someone to meaningfully contribute, they have to have some pretty niche skills -- reverse-engineering hardware and writing low-level device drivers or other bare-metal code.
To be blunt, someone that doesn't have the patience to semi-effectively operate an email client isn't going to be willing to invest the dozens of hours needed to wrap their heads around the problem spaces we operate in. It's a very steep learning curve (I'm not sure if I'll ever be done climbing it myself!) and our "making it easier for folks to contribute" efforts are better spent on tasks like the endless need for [improved] documentation.
> Sorry to the "I grew up with a mobile and twitter/fb/<and other crap tools> and only my grandma uses email" generation but please grow really up and don't primarily discuss the tools (that you actually know today - there are more out there ...) but think about "what makes good and constructive communication to solve problems and what avoids and/or discourages trolling, handwaving, etc.?".
I feel that this is not a "generational" gap so much as one of attitude -- It's not really about "email" or "forums" or whatever. Instead, are you the sort of person to accept the tools you're handed, and what the tool supplier says you are allowed to do with them, even when it doesn't really work that well for you, or do you roll up your sleeves, take things apart, and build/adapt better tools? (I might add that the latter is what brought us the Internet, Linux, and git, among the most wildly successful engineering efforts of all time..)
After all, the entire raison d'etre of Free Software is to empower the end-user [1], and Debian holds that principle very dear indeed. Sure, most folks probably don't care how the Debian sausage is made, but when you're the ones making that sausage, it's an entirely different conversation.
[1] As opposed to "Open Source", which is about empowering the _developer_, who may or may not chose to empower their end-users as well.
Posted Apr 19, 2020 3:31 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (8 responses)
OK, so there is a rite of passage element, thanks for the honesty. Except not because a rite of passage is a test you pass only _once_ to prove your worth. It can't be the main and (by your own admission) more complicated main communication channel with the rest of the world that you have to keep using every day.
Posted Apr 19, 2020 11:20 UTC (Sun)
by ballombe (subscriber, #9523)
[Link] (7 responses)
Posted Apr 19, 2020 16:32 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Posted Apr 21, 2020 11:08 UTC (Tue)
by jezuch (subscriber, #52988)
[Link] (5 responses)
Posted Apr 21, 2020 13:17 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
Okay, that one's a bit of a stretch, but here's one that isn't: Employers that require a college degree. Or a master's degree for more senior positions. They don't actually care about any specific coursework you took, as it will simultaneously be irrelevant, outdated, or insufficient.
What they do care about, and what the degree demonstrates, is that you were able to demonstrate effective time management and deliver results on a deadline. It shows you can juggle multiple projects simultaneously, with the project management (ie professors) considering their project to be the most important. It shows you can interact within a team, with incomplete and inconsistent requirements and the help of certian colleagues that, if you're being honest in your peer reviews, aren't worth the air they're breathing. It shows you can generally function on your own, both in the professional "work independently" sense, but also in the personal (hygiene/laundry, nutrition) sense.
In short: it shows you can endure (and perhaps even thrive) in spite of heaping piles of conflicting BS being dumped on you.
None of those "soft skills" are an explicit part of the coursework, but they are such that if you don't learn them reasonably well, you won't make it through university. And if you can't hack it well enough to get through university, you're probably not going to get far in a workplace that requires those skills, and more.
This is even more true for advanced degrees; rarely is your exact thesis or dissertation of interest to prospective employers; what matters is that you independently developed an idea/project from start to finish, running the approval/review/bureaucracy/BS gauntlet. Again, a valuable and necessary skill for higher-level positions.
(Yes, there are exceptions to this, but most folks don't have three-deviations-beyond-the-mean levels of raw talent...)
Posted Apr 21, 2020 14:23 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link]
Posted Apr 22, 2020 5:29 UTC (Wed)
by jezuch (subscriber, #52988)
[Link] (2 responses)
Anyway, like mbunkus said, I hope you're not suggesting that someone should spend 5 years of preparation before they're allowed to contribute to a project...
Posted Apr 22, 2020 13:08 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
Eh, even back in my undergrad days where we had to fend off dinosaurs on the way to class, it was commonly "joked" that our degrees would be in general crisis management with a minor in our erstwhile field.
In all seriousness, freshly graduated folks are fairly useless when it comes to specific technical skills. I don't say that pejoratively; what I expect instead is a decent understanding of the theory that underpins those technical specifics.
I want to see how they _think_, because it's completely unrealistic to expect fresh-outs to be immediately productive with the unique combination of miscellany that makes up our codebase (and technical debt). They're going to be learning on the job for the rest of their career.
(I should point out that I'm making a distinction between a university/college and a trade school)
> Anyway, like mbunkus said, I hope you're not suggesting that someone should spend 5 years of preparation before they're allowed to contribute to a project...
"be allowed to contribute"? Not at all. But they're not going to be terribly useful starting out, either. It takes time to grok a new codebase, even if you are already very familiar with the problem domain and tooling used.
(And these days, the typical software dev hasn't ever left the confines of client- or server-side javascript. It's quite a steep learning curve from that to reverse-engineering compiled binaries so you can figure out why your bare-metal realtime system is occasionally corrupting the data being read off the SD card...)
Posted Apr 22, 2020 18:56 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
There is always plenty of "quality of life" fixes in every project that experienced developers are too busy and too precious to do: small bug fixes, documentation gaps, small validation gaps, basic optimizations and simplifications, etc. These are a great way to ramp-up and learn about a project while being immediately productive and useful.
Tools like githab try hard to lower the barrier to submit these - and doing them lowers the barrier even more for the next project noobs[*]. "Are you with us or not?" mailing-lists and email code reviews keep (by your own admission) that barrier not crazy high but significantly higher. The difference is really that simple.
[*] a "project noob" can be very experienced with other environment and tools and may bring fresh perspectives.
Posted Apr 21, 2020 11:12 UTC (Tue)
by jezuch (subscriber, #52988)
[Link] (5 responses)
Why? Someone may have infinite supply of patience for problems they are interested in but zero for configuring stupid email client just the way the reviewer likes it on pain of rejecting your contributions. I know I do. And I'm definitely not one of the snapchatting youngsters!
Posted Apr 21, 2020 12:42 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
There's a pretty substantial gap between "configuring [the] stupid email client just the way the reviewer likes it" and "semi-effectively operating an email client"
The objection folks seem to have is that email is used _at all_, because *waah, it's too much effort*. Meanwhile they will hand out their email address or phone number to every app or website they encounter, and click on the link that comes back to "confirm their account". Congratulations, that's the total effort required to subscribe to a mailing list, and unlike the "messages from our selected partners" the apps or websites send in buckets, the mailing list will have clear subject lines -- and far more often than not, be considerably less voliminous.
But sure, let's scrap email for github-style PRs. And guess what? All three of the F/OSS projects I actively work on have github and/or gitlab mirrors. One has seen a total of 4 PRs opened, and 3 of those ended up abandoned because the submitter didn't respond. The fourth was eventually resubmitted via the "proper" channels, but still didn't make it in because the submitter didn't follow through with requested changes. Meanwhile, the other two projects have yet to see a single PR opened. Indeed, one project (for which I am the sole developer) has yet to see anyone click on the "fork" button, and, over the course of _eight years_, has received only one patch of any substance and maybe three or four trivial few-liners.
The overwhelming reason project X doesn't get drive-by contributions is that there isn't anyone (beyond the 1-4 people already involved) that gives enough of a f*ck to even look at the code, much less make changes to it. If local changes do get made, IME the biggest impediment to contributing upstream are actually corporate policies and processes that default to "don't share anything, ever."
As evidenced by the steady trickle of folks contacting me over email with questions, highly-technically-challennged support requests, or the rare "offering to test", "semi-effectively operating an email client" is a pretty low barrier indeed, I find it pretty hilarious that clueless end-users can manage this just fine but this mythical pool of hyper-talented developers that would be all over my code can't.
Indeed, it seems that the best way to generate contributions is to make your software crappier, because folks simply don't notice or care about the stuff that JustWorks(tm).
Posted Apr 21, 2020 15:49 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Plus, for any project that only gets a handful of external contributions over a long stretch, why would I want to set up a mailing list for it? The hosting service is largely irrelevant there (maybe CI solutions differentiate, but CI for such things is also usually the empty set), but if it's at least on *some* forge, those drive-bys are much more possible.
And any contribution mechanism will have abandoned patches. I don't know that one can derive rationale behind them without doing actual studies, especially with such a low N. As a contributor, I was definitely put off for a while when I had sent a patchset and it got, seemingly, completely ignored. Next time I go to rebase it (when I got a chance). Hey, it's been merged (with some minor fixups). A notice to the list would have been nice (not only for me, but else wanting those patches). Forges at least let me know when that happened.
And I'm not saying forges are always better. Lists work…ok for the kernel (as an occasional contributor), but feedback and better status tracking would definitely be appreciated.
Posted Apr 21, 2020 17:21 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Those young whippersnappers...
Posted Apr 21, 2020 17:27 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Apr 22, 2020 5:45 UTC (Wed)
by jezuch (subscriber, #52988)
[Link]
Autism works in mysterious ways...
Anyway, I was responding to the argument that since the project's subject matter is complex then it's fine if the submission process is also complex - and especially to ascribing an ideology to that. It's way simpler to be honest and just call it a hazing ritual :) It's fine to have reasons you work this way (it's better to try to improve that) but ideologies are bad.
Debian discusses Discourse
Debian discusses Discourse
If you cannot deal with a bunch of email files, I am not going to let you deal with files on my computer.
(because fundamentally that is what free software is about).
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
It's actually quite funny. If you host your code on Github under an Open Source license then you can get free CI from Travis or Github Actions.
Debian discusses Discourse
Debian discusses Discourse