After trying to help a project on the triage site... there needs to be a troll or toxicity level indicating which github projects should be avoided for obvious reasons.
I would imagine that such a system would be hard to cultivate. For many projects I'd say that two people would be a very bad fit together due to a clash of personalities, but on their own there's nothing troll-ish or toxic about either individuals. It would be hard to really quantify such problems with a project rating score and since so few people would be using the rating system (for many project), then it would be possible for a incorrect outlook on a project to be given based upon a single misunderstanding with one individual.
> I would imagine that such a system would be hard to cultivate.
Yes, matchmaking/recommenders can be hard... but I wonder if there is a different cluster of low-hanging fruit here?
Given a project on github, and desire to know its status, culture, players, etc, there's what I call the "github dance". Exploring commits and forks and pull requests and issues and wiki. Struggling to pull together a picture of n unfamiliar people from scattered comments. It's painful. It's very not what the github information display UI is optimized for. The exploratory dance seems far more often bounded by exhaustion than coverage confidence. There's almost no automation, for a task which seemingly permits a lot of it.
So apropos GP and toxicity: Signals like lots of wontfix prs, or an ecology of unmerged forks, have to be gathered by eye. Rather than a more automated/clearly-presented "well, that's a bit odd...". Absent a standard way of presenting goals and scope and roadmap and culture, everyone is winging it, some inevitably more opaquely than others. One can figure out a lot about projects using github data, but it requires having surfed a lot of projects, and the gh ui is seriously fighting you. Heck, one of the times when you most want to explore the ecology of forks, large dissatisfied communities in need of a new nucleation point... does gh provide a nice tailored display? Ha - gh says 'too many forks to tell anything about them'. There seems a lot of untapped potential value. And at least some of it seems relatively unchallenging to implement. And then there's all the many extra nifty things one could do with rich bulk analysis and ML - shoemaker's children.
That sounds like an interesting starting point for an academic paper on community interaction. Many of those metrics could be gamed if they were the 'goal' of a particular site, though before they're gamified they do sound like an interesting way of filtering through repos to find examples to talk about how communities function (or not).
Toxicity might be hard, but some stats might end up being a fair proxy.
Time to PR resolution, PR acceptance/rejection ratios. These probably get more useful as you break them down by the average profiles of who gets accepted and rejected (i.e., project has a high general acceptance rate, but no one with fewer than 5 PRs has ever had one accepted. Or, project hasn't accepted a PR from a previously-unaccepted user in over a year, etc.
Maybe worthwhile to repeat the calculations but only track PRs submitted in response to a CodeTriage prompt.
I don't understand how a site like this really helps people find something that they're interested in, which has a good community, and is something that they would specifically want to be involved in. It just looks like data overload to me and it biases everything towards the ultra-large projects which for new contributors can be overwhelming (unless said project has a lot of effort in mentoring/on-boarding/etc).
I'm not sure how you would present the information on this site in a way which would better lead to quality interactions between newcomers and existing projects, but as it stands it comes off to me as a jumbled list.
It's somewhat more important to me (because I'm experienced) to find the right project vs a random issue in one of many projects... I don't have trouble thinking of open source projects to contribute to, but I work in a big co and not super interested in trying to edit something like firefox because the community is too large.
I would prefer something like who's hiring but for volunteer work where projects say look, I have this kind of side project, or we have this smaller company, we use this stuff, we'd love to have a competent C++ person (sub your language of choice) to fix this (Windows build/annoying bug/move us to an awesomer version of a third party/rewrite the docs), in exchange, we're ready to have a short like 10mn 1:1 over IRC or email or something to help you get started. And then I'd feel like I can really bring something to the table, I suppose.
Most projects say "come hang out in our channel" or "just start with one of the beginner issues"... but it's a little intimidating to go to a new channel and not know what to say and walk in on people being already friendly insiders just to get a task. And I never know if it's socially OK to pick an issue in the tracker and post and say I'll fix it... what if I hit a problem or it turns out to be more than I could chew at this point in time, etc.
It's tough. Supporting someone through their first contribution is a lot of work and there's a lot of falloff with new contributors. It's easier to say "just do the work yourself if you're actually interested" and it can be exhausting to go through the initial hand holding time and time again.
As someone who is interested in growing a medium sized open source project, it's difficult to find the people who are interested in contributing without feeling too pushy. You want to give people the best information and tools to go forward, but you also want to let them learn independently (since scratching your itch is typically an adage within FOSS).
I do push the "just pop into the IRC channel" approach because it's hard to give better recommendations before knowing who the other individual is and what they want to get out of volunteering. I don't know if any particular thread could accomplish the negotiation of "who want's to help whom" due to the vast differences of all the different specializations, project sizes, project collaboration styles, etc. It would be nice if it did though.
I'd consider myself a "senior" developer and I have volunteered before (not as a dev)... In most other large-ish structures there are volunteer coordinators that introduce themselves & the project to new people, give out links, set up volunteer events when growing the project is needed, that sort of thing. My understanding is open source actually makes quite a lot of money, so I'm not sure how come spending what amounts to a few hours a month doing outreach is a much bigger problem than it is for the local community garden.
And of course, as a more experienced dev, really all I need is some kind of human touch so I know that if I start working my efforts won't fall into a big black void... devs tend to call that hand-holding because most devs think all socializing is a waste of time, but for most people volunteering is at least a little social.
As far as actionable advice goes, I think having virtual "volunteer days" (on the 1st Saturday of the month, beginners can join the channel and get matched with somebody more experienced if they have questions for their first pull request) may work. Also appealing is publishing "openings" showing an example of what skills developers in your project commonly tend to have (working independently, obsessive about coding standards, super-problem-solver, an eye for usability, great communication skills, ability to use valgrind, whatever) so people can self-select into it.
Interesting perspective. My own domain is within linux-audio which does not involve all that much cash (I've investigated various funding models for my projects as well as observed them for others and it is a hard game). Most of the projects are on the smaller side, so when you have a few people shift gears to spend time on volunteer events/activities it frequently slows down or pauses development.
I do try to put in community outreach time as it scratches a different itch than the more development focused day-job, however it does frequently seem to not lead too far. There are many cases where people interested in contributing are very junior individuals who need some assisting along the way due more to a lack of experience rather than lack of familiarity with the project in question. Linux audio in particular is challenging since it involves the intersection of several different domains (low-latency programming, DSP, C/C++, user interface coding/design, audio/speech processing backgrounds, technical writing, etc). So, people do end up being more green than I would expect compared to other open source domains.
Thanks for the specific suggestions. I've considered doing a specific hack day/weekend/etc event for a while, though I've never acted upon it since I don't really want to deal with the possibility that I end up spending a day or more and there is no activity in response.
I do like the idea of openings though. It's a clever way of presenting what the project has to offer as well as presenting specific enough profiles of people that it might get someone over the initial hump of "perhaps I should ask about contributing".
You seemed to have a very specific domain so I looked it up -- I think you're right, there's an inherently higher barrier to entry in your case. If you eventually do do a hack day, post it to HN, I'd give it a try! (I'm a very very beginner music maker and my own domain is graphics, not audio... but I do do fiddly low-level math in C++...)
What I'm trying to do to get experience working on other people's code is get the people I know who are trying to build their portfolios to farm issues and so on out to each other. I know a guy who's working on an RSS feed reader and ran into a bug he doesn't feel like fixing, I have a Rails app that needs styling, we work on each other's projects.
It's probably worse than finding big open-source projects to contribute to, but that's intimidating enough that none of us have done it.
Not affiliated (nor previously familiar) with CodeTriage, but I see a number of "I wish it did X" responses already and thought it was worth pointing out that their About page links to the repo for CodeTriage itself: https://github.com/codetriage/codetriage
They have over 100 contributors, so it seems likely they'd appreciate your issue or pull request.
16 comments
[ 5.7 ms ] story [ 33.9 ms ] threadThere are certain things that I "specialize" in that I feel could be of more merit to some projects than others.
Yes, matchmaking/recommenders can be hard... but I wonder if there is a different cluster of low-hanging fruit here?
Given a project on github, and desire to know its status, culture, players, etc, there's what I call the "github dance". Exploring commits and forks and pull requests and issues and wiki. Struggling to pull together a picture of n unfamiliar people from scattered comments. It's painful. It's very not what the github information display UI is optimized for. The exploratory dance seems far more often bounded by exhaustion than coverage confidence. There's almost no automation, for a task which seemingly permits a lot of it.
So apropos GP and toxicity: Signals like lots of wontfix prs, or an ecology of unmerged forks, have to be gathered by eye. Rather than a more automated/clearly-presented "well, that's a bit odd...". Absent a standard way of presenting goals and scope and roadmap and culture, everyone is winging it, some inevitably more opaquely than others. One can figure out a lot about projects using github data, but it requires having surfed a lot of projects, and the gh ui is seriously fighting you. Heck, one of the times when you most want to explore the ecology of forks, large dissatisfied communities in need of a new nucleation point... does gh provide a nice tailored display? Ha - gh says 'too many forks to tell anything about them'. There seems a lot of untapped potential value. And at least some of it seems relatively unchallenging to implement. And then there's all the many extra nifty things one could do with rich bulk analysis and ML - shoemaker's children.
Time to PR resolution, PR acceptance/rejection ratios. These probably get more useful as you break them down by the average profiles of who gets accepted and rejected (i.e., project has a high general acceptance rate, but no one with fewer than 5 PRs has ever had one accepted. Or, project hasn't accepted a PR from a previously-unaccepted user in over a year, etc.
Maybe worthwhile to repeat the calculations but only track PRs submitted in response to a CodeTriage prompt.
I'm not sure how you would present the information on this site in a way which would better lead to quality interactions between newcomers and existing projects, but as it stands it comes off to me as a jumbled list.
I would prefer something like who's hiring but for volunteer work where projects say look, I have this kind of side project, or we have this smaller company, we use this stuff, we'd love to have a competent C++ person (sub your language of choice) to fix this (Windows build/annoying bug/move us to an awesomer version of a third party/rewrite the docs), in exchange, we're ready to have a short like 10mn 1:1 over IRC or email or something to help you get started. And then I'd feel like I can really bring something to the table, I suppose.
Most projects say "come hang out in our channel" or "just start with one of the beginner issues"... but it's a little intimidating to go to a new channel and not know what to say and walk in on people being already friendly insiders just to get a task. And I never know if it's socially OK to pick an issue in the tracker and post and say I'll fix it... what if I hit a problem or it turns out to be more than I could chew at this point in time, etc.
As someone who is interested in growing a medium sized open source project, it's difficult to find the people who are interested in contributing without feeling too pushy. You want to give people the best information and tools to go forward, but you also want to let them learn independently (since scratching your itch is typically an adage within FOSS).
I do push the "just pop into the IRC channel" approach because it's hard to give better recommendations before knowing who the other individual is and what they want to get out of volunteering. I don't know if any particular thread could accomplish the negotiation of "who want's to help whom" due to the vast differences of all the different specializations, project sizes, project collaboration styles, etc. It would be nice if it did though.
And of course, as a more experienced dev, really all I need is some kind of human touch so I know that if I start working my efforts won't fall into a big black void... devs tend to call that hand-holding because most devs think all socializing is a waste of time, but for most people volunteering is at least a little social.
As far as actionable advice goes, I think having virtual "volunteer days" (on the 1st Saturday of the month, beginners can join the channel and get matched with somebody more experienced if they have questions for their first pull request) may work. Also appealing is publishing "openings" showing an example of what skills developers in your project commonly tend to have (working independently, obsessive about coding standards, super-problem-solver, an eye for usability, great communication skills, ability to use valgrind, whatever) so people can self-select into it.
I do try to put in community outreach time as it scratches a different itch than the more development focused day-job, however it does frequently seem to not lead too far. There are many cases where people interested in contributing are very junior individuals who need some assisting along the way due more to a lack of experience rather than lack of familiarity with the project in question. Linux audio in particular is challenging since it involves the intersection of several different domains (low-latency programming, DSP, C/C++, user interface coding/design, audio/speech processing backgrounds, technical writing, etc). So, people do end up being more green than I would expect compared to other open source domains.
Thanks for the specific suggestions. I've considered doing a specific hack day/weekend/etc event for a while, though I've never acted upon it since I don't really want to deal with the possibility that I end up spending a day or more and there is no activity in response.
I do like the idea of openings though. It's a clever way of presenting what the project has to offer as well as presenting specific enough profiles of people that it might get someone over the initial hump of "perhaps I should ask about contributing".
It's probably worse than finding big open-source projects to contribute to, but that's intimidating enough that none of us have done it.
They have over 100 contributors, so it seems likely they'd appreciate your issue or pull request.