simplification of the design onboarding, typos and open design
authorPierre-Antoine Rault <par@rigelk.eu>
Sun, 25 Feb 2018 14:33:05 +0000 (15:33 +0100)
committerPierre-Antoine Rault <par@rigelk.eu>
Sun, 25 Feb 2018 14:34:43 +0000 (15:34 +0100)
Contribute-to-design.md

index f0676ec582f8b90c37c1d5c306a983b0fd510d32..770fefebc092486a369db0e254f8433027a50da4 100644 (file)
@@ -1,7 +1,5 @@
 <!-- This guide is heavily inspired by GitLab's own contributing guide for its design team. Kudos to them! -->
 
-## Contribute to PeerTube's design
-
 Thank you for your interest in contributing to PeerTube's design. This guide details how
 to contribute in a way that is efficient for everyone.
 
@@ -15,14 +13,15 @@ to contribute in a way that is efficient for everyone.
 
 
 - [Onboarding :strawberry:](#onboarding-strawberry)
-  - [Software](#software)
+  - [Open Source Design](#open-source-design)
+  - [Suggested workflow](#suggested-workflow)
+  - [Suggested Software](#suggested-software)
     - [Sketch](#sketch)
     - [Adobe XD](#adobe-xd)
 - [Organization](#organization)
   - [Naming](#naming)
   - [Files and folders](#files-and-folders)
   - [Pages and artboards](#pages-and-artboards)
-  - [Major design proposals :bulb:](#major-design-proposals-bulb)
 - [Git](#git)
   - [Commits](#commits)
   - [Large Files Storage](#large-files-storage)
@@ -31,30 +30,33 @@ to contribute in a way that is efficient for everyone.
 
 ## Onboarding :strawberry:
 
-Everyone can contribute to PeerTube. 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.
+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>
+
+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](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.
 
-For all kinds of changes:
+### Suggested workflow
 
-1. Think of using pen & paper. Hi-end software isn't the goal. Design is.
-1. [Fork this project][fork-link] to your personal namespace.
-1. Make your changes while following the [naming](#naming) guidelines.
-1. Replace `PeerTube-elements.sketch` in your fork with the changed version. Make sure you select the branch you created before.
-1. Create a merge/pull request from your fork, selecting the appropriate source branch and this project's `develop` branch as the target.
+1. See what you think about is being tackled by others on the [issue tracker](issue-link)
+1. Think of using pen & paper. High-end software isn't the goal. Design is.
+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.
+1. 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.
+1. Create an issue on [PeerTube's repository](issue-link).
+   - Please use this [issue template](https://gist.github.com/rigelk/3350ba0670a9b7fab9a3df08a1de6367).
    - Mention _only one_ of the maintainers to review.
-   - It's normal to have merge conflicts because we're dealing with binary files, please ignore.
-   - The merge request will ultimately be closed as the changes need to be merged manually, instead of using Git.
-   - please use the [PR template](https://gist.github.com/rigelk/3350ba0670a9b7fab9a3df08a1de6367).
-1. High-five yourself and go brew some coffee while you wait for the review. Thanks! :raised_hands:
+   - The issue will ultimately be edited/closed as the changes need to be converted to integration/code tasks.
+1. High-five yourself and go brew some :coffee: while you wait for the review(s). Thanks! :raised_hands:
 
-### Software
+### Suggested Software
 
 Again, think of using [paper & pencil first](http://alistapart.com/article/paperprototyping).
 
 We recommend first and foremost open source software such as [Inkscape](https://inkscape.org/en/) or [Pencil](http://pencil.evolus.vn/) (a [complete list](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.
 
-Here are some software suggestions:
-
 #### Sketch
 
 Some pointers to open files from [Sketch](https://www.sketchapp.com/):
@@ -80,7 +82,7 @@ Some pointers to open files from [Adobe XD](https://www.adobe.com/fr/products/xd
 ### Naming
 
 Follow these guidelines when naming files and folders, as well as
-layers and styles in Sketch:
+layers and styles in your source files:
 - Adhere to [BEM naming convention](http://getbem.com/naming/): `block-name__element-name--modifier-name`
 - Readability above truncation: `background` instead of `bg`
 - `lowercase` everywhere
@@ -99,19 +101,6 @@ layers and styles in Sketch:
           - asset.svg
 ```
 
-1. - The 1st-level folders are named after the [Group label)](https://PeerTube.com/PeerTube-org/PeerTube-ce/blob/master/CONTRIBUTING.md#team-labels-cicd-discussion-edge-platform-etc) (also called team label) assigned to the issue/merge request (the green one; except [UX](https://PeerTube.com/PeerTube-org/PeerTube-ce/issues?label_name=UX))
-    - The 2nd-level folders are named after [subject labels](https://PeerTube.com/PeerTube-org/PeerTube-ce/blob/master/CONTRIBUTING.md#subject-labels-wiki-container-registry-ldap-api-etc) assigned to the issue/merge request (the blue ones). If there are multiple Subject labels assigned, the folder is named after all labels, in alphabetical order, separated by a dash (e.g. `settings-wiki`).
-       - Sketch files are named after their related issue/merge request:
-          - The basic naming pattern is: `projecthandle#issueID-title.sketch`:
-             - Starts with the project handle (found in the project URL). Use the compact versions `ce` or `ee` for the Community Edition and Enterprise Edition, respectively. All other projects should have their full project handle (e.g. `ux-research` for the [UX Research project](https://PeerTube.com/PeerTube-org/ux-research))
-             - The project handle is followed by `#<ID>` for issues or `!<ID>` for merge requests (e.g. `#1337` or `!1337`)
-             - The rest of the name should be a “compact” version of the issue/merge request title
-             - For example, the Sketch file for the issue [#28481 Display time tracking totals on milestone page](https://PeerTube.com/PeerTube-org/PeerTube-ce/issues/28481) on the Community Edition (CE) issue tracker could be named `ce#28481-time-tracking-totals.sketch`
-          - The Git hook that automates adding issue/merge request numbers to commit messages depends on using this naming pattern, so please follow it so that everything is nicely referenced (see [how to install it](#commits))
-          - If the work is related to multiple issues and/or merge requests, just duplicate the prefix and separate with a dash (e.g. `ce#1234-ee#5678-awesome-design.sketch`). In the Sketch file, each page can be named after an issue/merge request (see the [Sketch](#sketch-) section).
-          - If you have assets or other files related to the main Sketch file, consider creating an “umbrella” folder to keep everything together. The folder should be named after the issue/merge request, following the same pattern as described before (e.g. `ce#1234-awesome-design`).
-          - If you think the Sketch file is becoming too complex, consider breaking it down into separate files, suffixing the file names with a double dash modifier (e.g. `ce#1234-awesome-design--anonymous.sketch` and `ce#1234-awesome-design--logged-in.sketch`). Then, create an “umbrella” folder, as described in the previous point. Alternatively, you can organize the Sketch file internally to deal with this complexity (see the [Sketch](#sketch-) section).
-
 In any case, if the project becomes too complex (i.e. for a complete redesign proposal, please refer to the [design proposals section](#major-design-proposals).
 
 ### Pages and artboards
@@ -124,25 +113,21 @@ different states. Remember to follow the [naming guidelines](#naming).
 See the [Files and folders](#files-and-folders) section for naming and
 organizing Sketch files.
 
-### Major design proposals :bulb:
-
-Anything significant enough/complex enough to require further explanation that what a git repository and an issue can do, should be put in shape. We know issue threads are not enough in these cases, so feel free to put in shape a fully-fledged proposal such as [rethinkscape](https://github.com/PIWEEK/rethinkscape/).
-
 ## 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](https://try.github.io/), or with a video.
+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.
 
 Here are some more links and tips to help you
 along! :v:
 
 - 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!](http://dangitgit.com/) site.
+- 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.
 
-Note that as design files are usually binary files, merge conflicts can easily happen. We do the file merging manually instead of resolving with Git.
+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
 
@@ -162,5 +147,6 @@ Sketch files or PSDs can be huge, and well above what Git is made for (files way
 However, you need to set it up. A tutorial can be found on [GitHub's site](https://git-lfs.github.com/).
 
 [fork-link]: https://github.com/Chocobozzz/PeerTube/#fork-destination-box
+[issue-link]: https://github.com/Chocobozzz/PeerTube/labels/ui
 [framer]: https://framer.com
 [git-hooks]: https://git-scm.com/docs/githooks