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.

QuoteKnowing what needs to be done

Some kind of a public roadmap would help there.

The biggest problem is submissions that are useful but not useful to be in the core, i.e. mods. There are plenty of mods that could be written to help a lot of people but the amount of BS that goes with doing it is what puts people off.

I really hate to be an asshole here but this is about contributions to the core 2.1 code. I feel more encouraged to send forth code on GH than here on sm.org, primarily because I KNOW my pull requests will get feedback. That, and less of the said BS gets flung about.

That's the thing: most of the things people would want to contribute aren't actually going to be suitable for mainline 2.1 anyway, which means most of them would have been better off not being contributed in the first place...

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.

live627, what is stopping you from sending them forward on Github?

Come again??

https://github.com/SimpleMachines

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.

I know. I've already made 4 pull requests, two of which are merged into the core already. I'm also not interested in smCore.

First let me just say, I have read a ton of articles already that explain GitHub and how to use it.  Spent most of my day today, just reading about how GitHub works... arggg!

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...

Quotemaster - is the main branch, only used to merge in a "final release"
development - is the branch where the development of the "next" version/s happens
release-2.1 - is the branch where bug fixes for the version 2.1 are applied

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??

Only bug fixes in release-2.1

Quote from: SoLoGHoST on September 08, 2012, 11:57:12 PM
First let me just say, I have read a ton of articles already that explain GitHub and how to use it.  Spent most of my day today, just reading about how GitHub works... arggg!

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.

@Butch - Video would be great for this...  yep!!!  If someone were to create a video tutorial on how exactly to do everything so that we can contribute to SMF, this would be more productive for SMF, honestly!!!

Maybe I should make a full blog post about this but in the interim I wanted to let everyone know about Github training: http://training.github.com/web/free-classes/. They offer free online classes to learn about Github.

Edit: I forgot about this excellent resource as well: http://teach.github.com/

You know a website is absolutely dire when people have to be taught how to use it.

That is a ridiculous statement. The whole sentiment that people should just know how to use everything is ridiculous.

Quote from: Arantor on October 19, 2012, 12:26:20 PM
You know a website is absolutely dire when people have to be taught how to use it.

Exactly my opinion.

No, it's not.

Do you need a manual for any other website? No, because efforts are made to make it obvious what you're supposed to do.

This is why I gave up on it. The poor sods with the orange badges deal with GitHub. I just feed them markup and css.

Yes, you need lessons on how to use a lot of websites. You might not remember a lot of them because you've used them for a long time but I'm sure that you've learned to use them somehow. For instance, searching. You didn't come out of the womb knowing to put what you are looking for in the search bar and press Enter. You had to learn that somehow. Do you use any "advanced" searching methods? I bet you didn't know that adding quotes around something or adding a minus sign before something will alter the way you search. You learned that through documentation.

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.

Well done for, as usual, missing my point.

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?