News:

SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

Barriers to contributions

Started by Thantos, June 29, 2012, 04:30:07 PM

Previous topic - Next topic

Thantos

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.



live627

QuoteKnowing what needs to be done
Some kind of a public roadmap would help there.

Arantor

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.

live627

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.

Arantor

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.

Joshua Dickerson

live627, what is stopping you from sending them forward on Github?
Come work with me at Promenade Group



Need help? See the wiki. Want to help SMF? See the wiki!

Did you know you can help develop SMF? See us on Github.

How have you bettered the world today?

live627


SleePy

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.
Jeremy D ~ Site Team / SMF Developer ~ GitHub Profile ~ Join us on IRC @ Libera.chat/#smf ~ Support the SMF Support team!

live627

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.

The Craw

Quote from: SleePy on July 01, 2012, 11:40:04 PM
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.

* The Craw forks the 2.1 project; has mind blown at awesomeness.

SoLoGHoST

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

live627


butchs

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.
O:)
I have been truly inspired by the SUGGESTIONS as I sit on my throne and contemplate the wisdom imposed upon me.

SoLoGHoST

@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!!!

Joshua Dickerson

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/
Come work with me at Promenade Group



Need help? See the wiki. Want to help SMF? See the wiki!

Did you know you can help develop SMF? See us on Github.

How have you bettered the world today?

Arantor

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

Joshua Dickerson

That is a ridiculous statement. The whole sentiment that people should just know how to use everything is ridiculous.
Come work with me at Promenade Group



Need help? See the wiki. Want to help SMF? See the wiki!

Did you know you can help develop SMF? See us on Github.

How have you bettered the world today?

ascaland

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.

Arantor

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.

Antechinus

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

Advertisement: