Contribute-to-design.md

   1 <!-- This guide is heavily inspired by GitLab's own contributing guide for its design team. Kudos to them! -->
   2
   3 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.
   4
   5 ---
   6
   7 # Contribution guidelines
   8
   9 <!-- Table of contents generated with DocToc: https://github.com/thlorenz/doctoc -->
  10 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
  11 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
  12
  13
  14 - [Onboarding :strawberry:](#onboarding-strawberry)
  15   - [Open Source Design](#open-source-design)
  16   - [Suggested workflow](#suggested-workflow)
  17   - [Suggested Software](#suggested-software)
  18 - [Organization](#organization)
  19   - [Pages and artboards](#pages-and-artboards)
  20 - [Git](#git)
  21   - [Commits](#commits)
  22   - [Large Files Storage](#large-files-storage)
  23
  24 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
  25
  26 ## Onboarding :strawberry:
  27
  28 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.<sup>[1](https://twitter.com/jmspool/status/836955987860914176)</sup>
  29
  30 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.
  31
  32 ### Open Source Design
  33
  34 We care about [Open Source Design](http://opensourcedesign.net/goals/), 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.
  35
  36 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](issue-link) for us to help :smiley:.
  37
  38 You might want to read some more here, although these are just hints:
  39 - http://opendesignkit.org/process/
  40
  41 ### Suggested workflow
  42
  43 1. See what you think about is being tackled by others on the [issue tracker](issue-link)
  44 1. Think of using pen & paper. High-end software isn't the goal. Design is.
  45 <!-- 1. [Fork this project][fork-link] to your personal namespace. Or don't: it's just a suggested skeleton project to help you get started and structure your proposal. -->
  46 1. Create a repository from your fork.
  47    - 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.
  48 1. Create an issue on [PeerTube's repository](issue-link).
  49    - Please use this [issue template](https://gist.github.com/rigelk/3350ba0670a9b7fab9a3df08a1de6367).
  50    - Mention _only one_ of the maintainers to review.
  51    - The issue will ultimately be edited/closed as the changes need to be converted to integration/code tasks.
  52 1. High-five yourself and go brew some :coffee: while you wait for the review(s). Thanks! :raised_hands:
  53
  54 ### Suggested Software
  55
  56 Again, think of using [paper & pencil first](http://alistapart.com/article/paperprototyping).
  57
  58 We recommend first and foremost open source software such as [Inkscape](https://inkscape.org/en/) or [Pencil](http://pencil.evolus.vn/) (a few others: [mockup tools](https://mastodon.social/@jancborchardt/100746840345081751) and [design tools](http://opensourcedesign.net/resources/#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.
  59
  60 ## Organization
  61
  62 ### Pages and artboards
  63
  64 In terms of organization method, use the one that best suits you. However, if
  65 you think the file is becoming too complex, consider organizing it with different
  66 pages and/or artboards. For example, pages can be different issues and artboards can be
  67 different states. Remember to follow the [naming guidelines](#naming).
  68
  69 See the [Files and folders](#files-and-folders) section for naming and
  70 organizing Sketch files.
  71
  72 ## Git
  73
  74 Git is hard: screwing up is easy, and figuring out how to fix your mistakes is
  75 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.
  76
  77 Begin by [learning git interactively](https://try.github.io/), or with [a video](https://git-scm.com/videos). There is also that [dead simple site explaining it](http://rogerdudler.github.io/git-guide/). Or the verbose [official documentation of Git](https://git-scm.com/doc). Tons of ways, really.
  78
  79 Here are some more links and tips to help you
  80 along! :v:
  81
  82 - Revert your changes to a file and make it as if you never touched it: `git checkout FILEPATH/FILE`
  83 - If you already did a commit but want to uncommit those changes (before pushing): `git reset HEAD^`
  84 - If you feel you screwed up some more, there is the infamous [Dang it git!](http://dangitgit.com/) site, and don't be afraid to ask us.
  85
  86 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.
  87
  88 ### Commits
  89
  90 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:
  91
  92 - Write a [good commit message](https://chris.beams.io/posts/git-commit/)
  93 - Install the [Git hook][git-hooks] that automates adding issue/merge request IDs to commit messages:
  94    - 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.
  95    - 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#1337` or `ux-research!1337`).
  96    - It only works if you follow the naming pattern described in the [Files and folders](#files-and-folders) section.
  97    - 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).
  98
  99 ### Large Files Storage
 100
 101 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.
 102
 103 However, you need to set it up. A tutorial can be found on [GitHub's site](https://git-lfs.github.com/).
 104
 105 [fork-link]: https://github.com/Chocobozzz/PeerTube/#fork-destination-box
 106 [issue-link]: https://github.com/Chocobozzz/PeerTube/labels/ui
 107 [framer]: https://framer.com
 108 [git-hooks]: https://git-scm.com/docs/githooks