More information in the Readme for Developers (discussion)

[Elfangor93]

In order to have more developers who are willing to help improving the code of the joomgallery, I suggest to post more information about how to help coding on the joomgallery code. Topics I would like to see addressed in the readme are:

• Guide: How to set up the development environment
• Codestyle-guide
• Naming conventions (Naming of classes, methods, branches, etc)
• Release strategy (To which branch do I need to target my PullRequest?)
• Git workflow (What is the recommended workflow with git, if I would like to contribute code?)
• How can I resolve bounties? How can I earning money?

Do you have other topics which should be documented here on GitHub?
Do you have any ideas, how to motivate developers to contribute code?
Is there anything we could improve in order to get more contributes?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[MrMusic]

Thanks for your suggestion.
I would prefer to create articles on the website and link to them in the Readme.md.

[Elfangor93]

I would offer to create the articles for bounty and development environment.
Is anyone willing to text the other articles?

[MrMusic]

I would offer to create the articles for bounty and development environment.

Thank you very much!
I would offer to create the articles for Codestyle-guide and Release strategy (Versioning).

[Erftralle]

That sounds good!

A starting point for a guide how to set up a development environment I used can be found here.

There should already be a section about naming conventions (variables, classes, methods) in the code style guide. Regarding the branch names, there should only be three active branches here. The master branch (next bug fix release), a branch for the next feature release (at the moment v3.6.0) and a branch for the next major release (at the moment v4.0.0).

Regarding the working with Git or GitHub I think there are already lots of tutorials and documentation available in the web (see here and here and here.

[Elfangor93]

I like this graphical workflow:

But one step is missing, which I think is very important in case we dont want to resolve merging conflicts manually. Before sending a pull request I think its helpful to rebase the branch of your forked repo towards the remote branch. I would add this "rebase" step to our workflow.

What do you think?

[Erftralle]

What do you think?

A rebase is not always necessary as it does not necessarily have to lead to conflicts during development. Usually you only notice it when you create the pull request. Even if you have already done a rebase before creating the pull request, conflicts can arise again after creating the pull request until the final merge. A rebase is still possible after the pull request has been created. Sometimes the conflicts are so easy to resolve that whoever merges the branch resolves the conflict himself. However, sometimes you are asked to resolve the conflicts yourself by doing the rebase.

In summary, I would not insert a mandatory rebase into the graphic.