Barriers to contributions
One thing I want to do is to remove as many barriers to contribution as possible. My dream is for random_user_632 to see a bug or have a feature idea, code it up, and then submit it for inclusion. In order to get there we need to first identify the barriers and then remove or reduce the ones we can.
If you've ever thought "I could do that but nah" please let us know.
I started this discussion with the SMF team, Friends, and Beta Testers and here are some of the issues we discussed.
General interest in developing the product.
This comes in two flavors: What do I get out of it? And, "Is it interesting to me?".
I think education/discussion can help the first camp. The second camp depends on the answer. If it is "yes" then we need to help that person become a contributor. If it is "no" then there isn't much we can do. For various reasons I'm not interesting in working on a HTTP server, the Linux Kernel, a database, or a host of other projects I use.
Programming/graphic design/doc knowledge
Ok, someone is interested and they've got that OS spirit but they do need to know how to program or design images or write a doc. Without that knowledge they aren't much help. What can the organization do to help those people?
Finding the repository
A friend and former SMF PM mentioned that it was hard to find the code. We need to make finding the code for contribution about as easy as finding the downloads.
Understanding the submission procedure
I've seen this one a few times: A person makes a set of changes but has trouble getting those changes submitted for merging into the repository.
The team
I've seen this several time: Someone has the skills but doesn't want to contribute unless they are part of the team. Is there anyway we can lessen the importance of the team with regards to contributions? Or put another way: How do we help people realize that they don't need to be part of the team in order to contribute?
Knowing what needs to be done
Especially when someone is starting out it is hard to know where to jump in. Where should I start? What should I work on? How do we help people find out what needs to be done?
Please share your thoughts in both barriers you see and in how we can remove/reduce those barriers.
If you've ever thought "I could do that but nah" please let us know.
I started this discussion with the SMF team, Friends, and Beta Testers and here are some of the issues we discussed.
General interest in developing the product.
This comes in two flavors: What do I get out of it? And, "Is it interesting to me?".
I think education/discussion can help the first camp. The second camp depends on the answer. If it is "yes" then we need to help that person become a contributor. If it is "no" then there isn't much we can do. For various reasons I'm not interesting in working on a HTTP server, the Linux Kernel, a database, or a host of other projects I use.
Programming/graphic design/doc knowledge
Ok, someone is interested and they've got that OS spirit but they do need to know how to program or design images or write a doc. Without that knowledge they aren't much help. What can the organization do to help those people?
Finding the repository
A friend and former SMF PM mentioned that it was hard to find the code. We need to make finding the code for contribution about as easy as finding the downloads.
Understanding the submission procedure
I've seen this one a few times: A person makes a set of changes but has trouble getting those changes submitted for merging into the repository.
The team
I've seen this several time: Someone has the skills but doesn't want to contribute unless they are part of the team. Is there anyway we can lessen the importance of the team with regards to contributions? Or put another way: How do we help people realize that they don't need to be part of the team in order to contribute?
Knowing what needs to be done
Especially when someone is starting out it is hard to know where to jump in. Where should I start? What should I work on? How do we help people find out what needs to be done?
Please share your thoughts in both barriers you see and in how we can remove/reduce those barriers.
Nothing is a bigger barrier to contribution than 'Thanks, but no thanks', and no amount of making it easier to contribute is going to change that - except making it more common.
Nothing stopping you. Work is progressing on 2.1, while 3.0 is more in the idea stage, analyzing, testing stage. I wouldn't expect commits for 3.0 to be accepted since smCore for it is being hashed out mostly at the moment. But commits for 2.1 would be looked at. Just remember to sign off on the commit before you push a pull request.
So now I am confused about all of the different branches and repositories...
Ok, so I forked SMF 2.1 Repository, now I have 3 branches to choose from: master, development, release-2.1. I noticed the README.md file explaining a bit on this, but still find it unclear...
I'm assuming we should be using one of these branches when doing our edits to SMF, correct? I don't think we should use the master branch at all, since that seems to be the one to hold the merged code...
Confused, in the SMF 2.1 Repository, there is a development branch that states that it is for developing the next version(s)... If so, why is it in the SMF 2.1 Repository??
Should we be using the release-2.1 branch? I'm assuming, right? Since we are only allowed to fix bugs since, AFAIK, someone stated that features in 2.1 should not be added, as this part was done and it's only for fixing bugs now... correct??
Alas I do not have the time you have. I tried and was proven tardy. I am waiting for the U-Tube instructional video before I try again.
Edit: I forgot about this excellent resource as well: http://teach.github.com/
Exactly my opinion.
Do you need a manual for any other website? No, because efforts are made to make it obvious what you're supposed to do.
Thinking that any site, especially one which is meant to be for advanced uses, should be designed so that no documentation is needed is completely asinine. Sure, make it as simple and intuitive as possible, but lets face it, knowing what you're doing with Git requires a learning process. Any site like Github needs documentation for you to understand it.
Having help or references for the advanced stuff is fine. Such as your example of using quotes around stuff. That's an advanced technique, it isn't immediately obvious, and as such it's perfect material for reference manuals.
But in the case of Google, actually they've really tried to make it as easy to use as possible without needing help. You go there, the cursor's already in place, you start typing and it gives you suggestions as to what you might be looking for. It's not going to take much even experimentation to figure out how to use the basics. Not only that but techniques such as interface affordability (i.e. things that are meant to be pressed, give them a 3D look that represents a button in the physical world, something that is pressable)
I'm not disputing that GitHub overall is an advanced site. But when you have to have a video to explain the basics, there's something wrong. When you get three page discussions, or multi-hour IRC sessions between people who do know how to use GitHub and people who don't, just to get them started, something is very, very wrong.
I'm not disputing that a learning process is required, but to make it that you need to have the *basics* explained because it's that hard to use, surely you'd agree that you could do something to make it better?