3 ms·

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

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.

fundamental 8y ago
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.
- mncharity 8y ago
  > 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.
  - fundamental 8y ago
    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).
abathur 8y ago
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.

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.

fundamental 8y ago

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.

mncharity 8y ago
> 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.
- fundamental 8y ago
  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).

abathur 8y ago

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.