This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.
Thank you for your interest in contributing to PeerTube's design. Our team is building a software, but we don't forget its core concept still is to interact with people. Here's how you can help them better get along.
Contribution guidelines
Onboarding 🍓
Everyone can contribute to PeerTube's design. Anyone who influences what the design becomes is the designer. This includes developers, PMs, even corporate legal. All are the designers.1
The project is still low on resources and no dedicated design team has been established, nor a dedicated design repository − yet. We are trying to get you to speed nonetheless, and make communication between design-literate and code-literate people as easy as possible.
Open Source Design
We care about Open Source Design, and Open Design in general. Making the design process open is an important thing for us, as interfaces too can greatly impact the resulting software, in bad or good.
It implies putting your files in the open and iterating to modify it with others until consensus. More specifically, it means dividing a given design problem in manageable parts, and track them in public for us to help 😃.
You might want to read some more here, although these are just hints:
Suggested workflow
- See what you think about is being tackled by others on the issue tracker
- Think of using pen & paper. High-end software isn't the goal. Design is.
- Create a repository from your fork.
- Be very descriptive of the changes you've made. The reviewer will have to manually merge them, which means they have to be aware of even the smallest changes as they could be easy to miss.
- Create an issue on PeerTube's repository.
- Please use this issue template.
- Mention only one of the maintainers to review.
- The issue will ultimately be edited/closed as the changes need to be converted to integration/code tasks.
- High-five yourself and go brew some ☕ while you wait for the review(s). Thanks! 🙌
Suggested Software
Again, think of using paper & pencil first.
We recommend first and foremost open source software such as Inkscape or Pencil (a few others: mockup tools and design tools), but at the same time we know most of them are behind popular software for web design workflows. You can use any design software that's available to you. Just make sure to include editable exports (SVG, PDF, EPS) along with your source files.
Organization
Pages and artboards
In terms of organization method, use the one that best suits you. However, if you think the file is becoming too complex, consider organizing it with different pages and/or artboards. For example, pages can be different issues and artboards can be different states. Remember to follow the naming guidelines.
See the Files and folders section for naming and organizing Sketch files.
Git
Git is hard: screwing up is easy, and figuring out how to fix your mistakes is sometimes almost impossible. Yet that's one of the best tool to deal with heterogeneous groups of people (you!) coming from all over the world. It brings structure to chaos.
Begin by learning git interactively, or with a video. There is also that dead simple site explaining it. Or the verbose official documentation of Git. Tons of ways, really.
Here are some more links and tips to help you along! ✌️
- Revert your changes to a file and make it as if you never touched it:
git checkout FILEPATH/FILE - If you already did a commit but want to uncommit those changes (before pushing):
git reset HEAD^ - If you feel you screwed up some more, there is the infamous Dang it git! site, and don't be afraid to ask us.
Don't forget the section about git-lfs. Large files as graphics sources slow down Git, and need that special plugin to be dealt with.
Commits
Commiting changes is the action to bundle the changes you've made in a set that can be shared with others. Of course some rules apply to that step, and good practices too that can help you do more with commits:
- Write a good commit message
- Install the Git hook that automates adding issue/merge request IDs to commit messages:
- At the root of the repository, run
ln -s ../../hooks/prepare-commit-msg .git/hooks/prepare-commit-msg. This will keep your local Git hook up-to-date. - Once installed, every time you commit, the hook will add the issues and merge requests IDs found on the staged files (and their folders) to the commit message body (e.g.
PeerTube-webui#1337orux-research!1337). - It only works if you follow the naming pattern described in the Files and folders section.
- These references automatically create a commit note in the corresponding issue/merge request, making it easy for other people to contribute and fork the design (especially important if someone is out-of-office).
- At the root of the repository, run
Large Files Storage
Sketch files or PSDs can be huge, and well above what Git is made for (files way under 100MB). But fear not, Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server.
However, you need to set it up. A tutorial can be found on GitHub's site.