If you’d like to contribute to the design or front-end, feel free to contribute to tickets labeled with either Needs design feedback or Needs design. We could use your thoughtful replies, mockups, animatics, sketches, doodles. It’s best to keep proposed changes simple and constrained in scope so that it’s easy to compare, discuss, and implement changes.
Terms
- Labels: each GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue has labels that denote the ‘state’.
- PR: pull request: how to add a ‘patch’ in terms of GitHub.
- Milestones: a way to chart and manage the project.
Labels
Whilst not an exhaustive list here are some of the useful labels to know about:
- Bug: something is broken or doesn’t work as expected.
- Enhancement: a suggestion for an improvement, or feature.
- Needs design feedback: feedback on something that exists.
- Needs design: a feature or iteration that needs a design.
Choose your own adventure
Without coding
- Advisor: go through ‘needs design feedback’ issues.
- Screenshotter: add screenshots to issues that have none of the problems.
- Informer: ask for more information as can’t replicate a problem.
- Tester: test not only GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ on all devices, browsers and situations, but also test bugs here and here. Also testing any PR is a great way to help move issues along.
- Copy issues: review and suggest copy.
- Creator: add to ‘needs design’ or anything that seems like it would be good to have a design.
- Documentor: everything needs documentation.
- Triage: see an issue without any comments or actions? Go through from oldest issues and make sure all issues can move on a little.
With coding
- Patcher: make PRs
- Reviewing code: CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. for example is crucial.
Note: due to technical nature some of the triaging is a little intimidating for new contributors.
Diving into the code
Note: this isn’t for all designers but if you do want to explore, here are some guides to get you started.
Setting up system
To run Gutenberg from GitHub and potentially make PR you need a few things:
- A local environment, Docker is recommended because Gutenberg has a container.
- GitHub app: recommended unless you want to explore the world of the command line: https://desktop.github.com/.
- A code editor: https://atom.io/ is from GitHub but you can use whatever you find useful, https://code.visualstudio.com/ also is an option.
- Terminal app if on mac (or another way to interact at that level): at some point you’re going to have to dive into command line but there are some simple steps to this you can always refer to.
Useful resources
- https://desktop.github.com/
- https://help.github.com/
- https://help.github.com/articles/git-cheatsheet/
- https://help.github.com/articles/creating-a-pull-request/
Workflow
A good workflow for new contributors to follow is listed below:
- Fork Gutenberg repository.
- Clone forked repository.
- Create a new branch.
- Make code changes.
- Commit code changes within the newly created branch.
- Push branch to forked repository.
- Submit Pull Request to Gutenberg repository.
Branch naming
Ideally name your branches with prefixes and descriptions, like this: [type]/[change]. A good prefix would be:
- add/ = add a new feature
- try/ = experimental feature, “tentatively add”
- update/ = update an existing feature
