71–80 of 84 posts
Earlier quoted context omitted.
You got some great points there but I don't think contributing a change without asking get before is bad even if it misses the project goals. I sometimes need a feature and posting it on mailing lists, etc tasks too long (considering the contribution is only going to be a few lines ~100). If it misses the goal of the project, I don't reallt care. It has fulfiled the licensing agreement (to post code back upstream). I…
There is a sense of pressure to merge PRs, though. When you have a lot of open PRs it starts to discourage further contributions. And if you reject a lot of PRs, or if you are too strict about it (i.e. nit-picking their PRs) it can also create a negative atmosphere that discourages further contributions. Also... when you deal with dependencies in a package manager (like npm dependencies), it is less than ideal to rel…
If a PR is not quite right (which is often the case), I will clone their fork locally, and edit their commit(s) using git rebase and then merge it.
That way the user is still acknowledged as a contributor on GitHub (and they can see both of our names/profile pictures next to the commit message). Then I make a comment explaining why I edited their commit(s) on the pull request itself or the issue page. That keeps everyone happy and encourages further contribution.
It's not always practical to do this though but it feels natural in many cases.
I think GitHub needs a "+1" button for issues. It'll give maintainers some insight as to what priority to give an issue, without spamming them with e-mails. Asking users not to comment with comments such as "+1", or even turning off comments, hides this information. This will solve the issue partly.
This was basically my life with building Ansible for three years. Given, I loved many aspects of it, but it was really hard and it took a major toll. (clarification: this has post has absolutely nothing to do why I am not working on it anymore) I've been considering a bit of a blog post on this (particularly the unknown parts of wide scale OSS projects), but basically open source projects get harder as you have more…
> When your project faces this pressure how do you act to ensure that meaningful discussion happens and decisions are made that are the best for your actual users and contributors in the long run? Make sure you know who your users are. Keep in touch with them, reach out, do "community building". They will tell you things about your product/software/system you would otherwise never hear. That way, you can also filter…
I just did that, actually.
Earlier quoted context omitted.
I don't know that I would go that far. He was very abrasive, whereas his core message could've been plenty to stop the nonsense he always added a little bit of aggression to keep the drama going. If he was a genius, you probably wouldn't ever have known the issue existed. At least it seems that way to me.
But the people who started the attacks researched his profiles and publicized the entire thing. Their entire goal was public ridicule and getting him denounced. If this group of thugs is good at anything, it's getting the word out and the twitter mobs mobilized.
And this is what makes the way he handled it -genius- :-)
Earlier quoted context omitted.
Based on lines changed, merge requests accepted/rejected, etc etc. You know, GitHub developers are quite smart. They could just write their own weighting algorithm if they wanted to. :-)
Those are absolutely awful metrics to use when measuring a developer's ability and talent, or the quality of this developer's contributions. They are also extremely easy to game, too.
Earlier quoted context omitted.
Maybe relevant: We're bringing GitLab to FreeBSD. :-) Check the ruby@ list for current status, things left to do, etc. https://lists.freebsd.org/pipermail/freebsd-ruby/2015-July/t...
Thanks for that effort! Please let us know if we can help in any way.
I think GitHub needs a "+1" button for issues. It'll give maintainers some insight as to what priority to give an issue, without spamming them with e-mails. Asking users not to comment with comments such as "+1", or even turning off comments, hides this information. This will solve the issue partly.
On the contrary; it will turn the whole thing into something that can be gamed even better by those who are good at rallying, organizing mobs, and shaming people into doing what the mob organizers can't do on their own.
> Lately a number of open source projects has faced tremendous pressure from people coming from Twitter and Reddit to have issues resolved a certain way. Can you point to a specific example? the only things I have seen is some brigading and cabal to pressure a project owner to remove a contributor from a project, but it was akin to a lynch mob, not related with programming in any way.
The recent witch hunt against projects that don't have Code of Conducts. 'meh' did a masterful job with those: https://github.com/opal/opal/issues/941 https://github.com/opal/opal/issues/942 https://github.com/opal/opal/issues/945
> The recent witch hunt against projects that don't have Code of Conducts.
isn't really true. The issue started with a maintainer who advertised their relationship with @opal on twitter who then made perceived transphobic comments.