Add extra tips to screenshot

Idea
In dont.god-commit.adoc could specific reasons be added to explain why they are bad? I think it would help explain them better.
Screenshot included: no

• html
• pdf

Good day!

I would like to contribute by translating the documents into the Filipino language so that it will have a broader reach. Can I do it through setting up pull requests?

Thanks!

Please remove items in the right column:

Please remove items in the right column:

The current table:

Proposed updated table:

• html
• pdf

Please remove items in the right column:

• Use a visual html page (large buttons) to navigate between the sections (split on DOs / DONTs or something else?)
• CI to build all books in their own subfolders

High

In no particular order:

Note: creating these as issues on your project and working through them

• Catchy and easily to follow high level README.md file with simple screenshots / diagrams (include links to more details in the various sections)
• Have a CONTRIBUTING.md file. Good examples: OpenGov, Atom
• Include a CODE_OF_CONDUCT.md file. Standard COC
• Include a LICENSE file. Good resource to help
• Include an ISSUE_TEMPLATE.md file to help when people create an issue (idea, bug/defect etc)
• Include a PULL_REQUEST_TEMPLATE.md file to help when people submit a pull request
• Use milestones in the issue section to organise project journey and priority of issues in that current sprint. Also align milestone name to releases
• Use labels on issues to highlight: area, size of work with points etc
• Use releases to show stable versions. Use semver format
• In the release notes include a changelog
• Use an existing branching strategy, for example gitflow (even if a cut down version)
• Split documentation into overview (in README.md) and link to more details. Include explanation of acronyms / abbreviations for people to understand
• Clean up unused files, branches, releases etc
• Add badges to the repo for: CI, dependency checkers, lint checkers, deployment etc
• Documentation to be in the repo, so that it can be kept in sync with the codebase and all changes go via pull request for review (treat documentation like code)
• Have a simple static website that demonstrates features (could host for free on GitHub Pages)
• Deploy documentation as part of CI to static website and downloadable PDF (could host for free on GitHub Pages)
• Use description, link and labels in the project repo (top of landing page)
• Make the project standards (branching, labelling, testing etc) clear
• Lock main branch and pull requests require at least 1 review

Medium

In no particular order:

• Meetup talk
• Hackathon

General

In no particular order:

• Make sure issues (stories) are small enough and have enough information for someone outside the team to understand and feel they could contribute - sketches / diagrams etc are usually welcome, these do not have to be pixel perfect
• Similar to issues, keep pull requests small so others can follow / review - plus improves project's activity
• Try to respond within 24hrs to a contributor activity on the repo
• Commit messages must be descriptive but concise
• Clear project vision
• Automate as much as possible

Greetings,

I would like to translate your book Open Source Tips to Spanish and French so it can be more understandable for people limited by the english language. I would like to know how can I commit that translation to your repo.

Thanks in advance for your answer.

Please remove items in the right column:

• Add DO for members of the GitHub organisation to have their membership public

Please remove items in the right column:

| Type Idea |
| Screenshot included? | no |
| Description | I think you should include more information about starting with GitHub such as contributing and working with someone. The information already on there contains lots of strange terms that puzzle beginners. |

New section on this.

e.g.

• Code standards checker
• etc

Please remove items in the right column:

1. Make the project more inclusive for beginners working on open source projects by adding asciidoctor installation steps to Readme: http://asciidoctor.org/
2. Be clear in the Readme that users only need to do: (a) $ gem update asciidoctor & $ gem install --pre asciidoctor-pdf (if memory is correct) - as I beginner when I first looked at documentation I was unsure of if I needed to go through rest of steps which were only relevant to using ascii for setting up a new project
3. Include Asciidoc Preview package for Atom: https://atom.io/packages/asciidoc-preview to help beginners check their changes are correct
4. Include an explanation of what a build file is (for beginners) & how to use it for this project, especially if they don't use the Atom Asciidoc Preview package|

Please remove items in the right column:

1. The following DOs and DON'Ts aim to address some of those basic questions, and offers some pointers to aspiring Open Source developers.

"and offers", shouldn't that be "and offer"?

2. Or, "How do I choose between so many competing projects?”.

There shouldn't be a period at the end of this sentence, similar to the sentence just before.

Thanks.

Please remove items in the right column:

On page 4:
the subtitle of the codesnippet is doubled
"GitHub syntax highlighingGitHub syntax highlighting"