31–40 of 85 posts
Earlier quoted context omitted.
Ignore anything about MQ. They have old docs on using MQ that we've been trying to wean them away from. Modern hg is far better than MQ, and in some situations, better than git. You can edit, you can rebase, you can amend, you can evolve.
MQ?
I have yet to move onto a big project, but it was a nice introduction to that kind of distributed coordination needed for open source repos.
It can be a great way to expand your skills as a developer and also to gain experience working with designers and solving problems around growth, product positioning, pricing, and all sorts of other things.
[disclosure: I work at Assembly -- happy to answer any questions: austin@assembly.com]
The answer is "all of them!" ESR wrote "Every good work of software starts by scratching a developer's personal itch." You'll be much more effective working on a program that you use and want to make better, compared to a beginner-friendly project that you have no interest in. Instead of looking externally for projects, look inwards. Think about the software you already use, and how it could be better: that stupid an…
I've had experiences of projects I tried to get involved because I liked the software but where the maintainer had zero interest in involving any new people. It's lovely that developers scratch itches and create cool software - there isn't anything that implies those same people want to work with other new people.
I'm glad you had a good experience and maybe I was unlucky or whatever but I don't think mere interest in the software is enough, the project has to be in a state where the developers want other programmers involved (lots of projects would like some testers and documenters but nothing else and to an extent understandably).
I mean, I'm not sure why guidance towards accessible projects is a bad thing.
Edit: Oh I knew I'd get reactions. Counter-arguments? A lot of professional software teams have a hard time adding new people. Why would any old open source project be easy to get involved with?
Edit2: I love the idea of open source, I want to get involved again in a larger project when I have time but the "no problems" guidance approach seems itself a problem. Lots of projects are even infamous for problems. There's clearly more to what project you'd be a fit for than "what you love" and just leaving that as the advice seems like a characteristic problem of open source itself.
Our sourcecode is on Github:
https://github.com/Crowducate/crowducate-next
Planning documents are on Hackpad:
It is written in Python and it is being actively developed.
You can find some notes on getting started with development here: http://pgcli.com/develop
It is a command line client for Postgres database.
I'll be more than happy to answer questions or help you get started. My email is amjith.r [at] gmail.
Feel free to get in touch.
Even if you're just adding another parameter to an existing endpoint (which is largely a copy/paste exercise), it's a great way to learn the structure of a gem, learn your way around API documentation, and check out others' best practices and unit tests. I contributed to the official Instagram gem during my first few weeks of learning Ruby.
https://github.com/Instagram/instagram-ruby-gem
Prereqs: Ruby, API basics