Hacker News Reader

Comment by MatthewWilkes | Hacker News Reader

> We would also like to thank our contributors (7 new ones since PyPy 2.6.0) and encourage new people to join the project. PyPy has many layers and we need help with all of them

This doesn't match my experience of the PyPy project. I found a tiny bug in the stdlib matching against CPython, went into IRC to ask a question about test running to be sure I got it right and was quickly engaged in conversation about why I was running core tests. Next thing I know my small bug has been fixed by a core developer and my chance to contribute is gone.

I'll stick to being a user.

View on HN

This is very very disingenuous.

Here are the public IRC logs for what I assume you're referring to (which is from July 2014 by the way):

https://botbot.me/freenode/pypy/2014-07-02/?msg=17362202&pag...

You found a bug in an old version of PyPy. A core developer told you you might want to try a new one. No one stole your shot out from under you.

You would undoubtedly be welcomed to contribute. Don't post FUD.

Disclaimer: I am not a PyPy core dev but I do work closely with them.

> Alex_Gaynor - simpson: import operator; operator.isNumberType is the check you want

> I'll push this change quickly

> Alex_Gaynor - uhh, wait the check seems to exist?

I dunno, I kinda see both sides here. First, I don't think the devs were off-base at all here. They were friendly and looking to solve problems. However, they did seem to want to simply solve the problem, while Matthew did state that he was looking at this as a way to contribute.

The whole interaction could have been improved with a little encouragement at the end, and possibly a recommendation of an 'easy' bug that was currently in need of a fix. It was fairly clear that there was an enthusiastic new contributor, so a little effort in this direction may have been warranted.

I certainly would consider this an example of being unfriendly or unwelcoming.

I apologise that I mis-remembered and characterised intending to fix a bug, investigating, and finding out it was already fixed as just fixing a bug, however I believe the rest stands.

The fact that I wanted to run tests and couldn't, and the team went on to why I wanted to run tests and looked to solve my problem is my complaint.

Also, to be clear, I'm not trying to say the PyPy channel is unfriendly, it certainly isn't. It's just not set up to help potential new contributors get started.

On the flip side of this thread, some projects have started to adopt specific tagging in their issue systems for folks looking to get started as contributors. I really like this as it's clear communication to both new contributors and to existing contributors that the issue in question is an on-ramp for the project.

Here's Neovim's "entry-level" label, for example:

https://github.com/neovim/neovim/issues?q=is%3Aopen+is%3Aiss...

As another example it seems that Rust does the same:

https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...

Servo inherited that policy too: https://github.com/servo/servo/issues?q=is%3Aopen+is%3Aissue...

Actually pypy tries to do the same, bitbucket does not support tagging very well though (but looking for "easy" or something in the issue tracker helps). I am personally sorry if the poster had an experience like that, IRC is difficult to communicate over, it must have been a misunderstanding

Is this a complaint or a compliment to the developers?

He didn't want to report a bug, he wanted to contribute to the project. I can think of a few reasons why. They lost a new potential committer by "being pragmatic" about it, but ignoring inter-personal relationships, like so often.

Personally I'd be quite excited to see a bug I reported fixed the same-day - of course people's expectations are different it's not always easy to balance these things.

One of the rewards of participating in OSS is to make your name visible, this can then be used as creds to gain commit rights or to talk at conferences as well as proof of competence when looking for a job.

Interestingly, I've had the same experience when reporting and asking how to contribute to Python 3, not by a core dev but somebody "stealing" my bug and quickly submitting a patch!

The open source community is not there to provide you with cred and visibility. It's there to so software can be developed in a way that certain people think is the best way to develop software.

Something similar happened that left me with mixed feelings recently. I recently came up with a new feature idea for Python, and a core dev ran with it. I was very happy at first, but then he wrote a pep, implemented it, and got all the congrats. I had hoped to help, and put something on my resume, but was shut out. "Thanks for improving my pep" on a mailing list is all the credit I got (and work I was able to do on it). Kind of disappointing, though I will enjoy the feature.

Sometimes person reporting an issue along with the code, doesn't get it quite right and core dev can immediately see correct solution and can't make himself to wait until original reporter makes it right... of course it doesn't happen often but it does.

One of the project I participated the most was ansible, and in a case like this, @mpdehaan2 would just push back and comment until your PR was acceptable, which was encouraging and making you contribute more.

I can understand that, I certainly would have been stoked about a bug report being fixed on the same day; I hadn't reported the bug though. I was working on providing a bug report with a patch alongside it and (perhaps foolishly) mentioned the bug informally as context as to why I was doing this.

Without being privy to the entire context, what I think might've happened is that your discussion caught the interest of a core developer who then picked it up and ran with it. I doubt they intended to step on your toes as a consequence of fixing the problem. Hackers tend to be intrigued by problems, including small ones, and especially ones that cause software behavior to deviate from expectations.

The other side of the coin is that without a patch, the developers have no idea what your motives or capabilities are. They can't read minds, so if you pique their interest sufficiently, they're very likely to take it upon themselves to do the legwork. No malice intended. I should hope you'll change your mind about contributing to FOSS projects after reading this thread, because I think it's counterproductive to take this sort of thing personally (I don't know if you are, but it appears to me that you're unhappy about this at the very least).

That said, there aren't many projects that post credits or thanks to people who have discovered bugs or whose line of questioning has lead to fixing application behavior. While it's extra work and isn't always feasible, it can encourage users to pitch in if they know their name might appear in some credits (even if it's only per-release). Then there's the question of how big the problem needs to be to credit someone...

I'm a long-term FLOSS contributor, but I've also served on the boards of 501(c)(3)s, I've been a mentor for Google Summer of Code for most of the times the programme has run and I've run workshops at my local university about getting involved in open source. I know what is involved in making a community welcoming to new contributors. If a project is putting an explicit call for contributions in updates that implies they're not getting as many as they'd like, which fits my experiences.

What you say about hackers getting nerd-sniped is true, but "that's just how coders are" certainly isn't. If you're a core developer for a project and you want the community to grow rather than diminish it's your responsibility to make it socially welcoming as well as having a low technical barrier to entry. I personally have spent many hours responding to emails about problems I could have fixed trivially, but if I'd done that the potential new contributor may not have grown into someone that's regularly fixing bugs I can't fix trivially. I'm not taking the unwelcoming attitude personally, I'm acting accordingly. If I can't get the information from a community I need to participate but I can get them to do the work by just throwing it over the fence I'd be crazy to continue to try and help them unless I have a very strong reason to outside of requiring fixes.

As to your point about reading minds, this is specifically mentioned in my initial comment. I asked about a problem running tests, and when I provided the context that I was asked for (I'm trying to put together a patch for this bug) there should have been no question as to motivation.

> I hadn't reported the bug though.

I don't think its reasonable to expect a projects core developers, when they become aware of a bug through mechanisms other than formal bug reports, to deliberately stall confirming and resolving the problem because the person raising the issue is entitled to a crack at fixing it.

You can do something correct and still be discouraging to people who would like to contribute.

How is reporting a bug not a contribution? Now, I don't know about this particular bug, but in most cases finding the bug is where the work is. Checking in the fix is trivial.

That's a shame, it can sometimes be tough to pick out a good manageable intro-bug on an open source project you want to contribute to. Perhaps it was a new-ish core dev who was also keen to cut his teeth on small/doable bugs?

Not everyone can get it right all the time.

Fixed a bug the same day someone asked about it and some potential contribute blame you for not letting them fix entry level bug.

Answering people with "patch welcome" and people blame you for not fixing it.

Did you tell them that you wanted to contribute, rather than get a bug fixed?

>This doesn't match my experience of the PyPy project

One experience, with one developer, and without going through official channels to asks for participation etc.

The IRC channel is an official channel, in fact it's by far the most important one of the PyPy project.

Reply on news.ycombinator.com