design repo contribution guidelines

[guylepage3]

moved from... https://github.com/blockstack/designs/issues/293

Community contribution issues

1. No real definition of how to contribute
2. No design process
3. Undefined or not so strong Brand guide / Brand fundamentals definition

Community contribution issue solution

1. Create a “how to contribute” guide
2. blockstack.org
3. design
4. browser
5. Having a design process will allow for the community to better contribute to the design repository and streamline the design lead’s role
6. Define brand fundamentals (100%) and brand elements 80% complete brand guide (20% to be iterated to completion)

The above was developed from

• https://paper.dropbox.com/doc/Brand-design-and-UI-issues-n4BwkOA0KDVqi3Mzx6HNZ

[estermer]

I was able to replicate the changes that were made to the contribution guide on blockstack.org to the designs contribution guide and readme.

So they are:

• a trimmed up contribution guide
• the pr process is the same using the git-flow branching technique
• edited the maintainer to be just @guylepage3 and trimmed it up
• created a tl;dr on the main readme linking to the full guide

Questions:

• would we like the file naming and structure and Install & Setup Git LFS: to be on its own .md and linked to make the full guide a little cleaner?

[guylepage3]

@estermer one of the major things to add is git lfs. With design files it's quite different and we need to think up our own contribution guidelines/process for the designs branch.

Are you familiar with Git LFS?

[estermer]

@guylepage3 I am not familiar with it, I can take a little time to though

[estermer]

@guylepage3 I looked over LFS, I was curious to what our goals would be with communicating the LFS process?

Such as:

• do we want our contributors to understand how to set up lfs?
• what files we want lfs to track?
• minimize the list of files to track?
• explain the typical git lfs workflow we use like our PR process we have a git lfs process?

[guylepage3]

@estermer the following is what the "old" repo README.md looked like...

design

Blockstack Labs design and marketing files via Git LFS

Table of contents

• Quick start

Quick start

Several quick start options are available:

What's included

Each project team has a directory, seen below, and in each of the team directories are projects. Each project contains 3 standard directories for quick navigation to find files that are;

• compositions or working files
• proofs or final files
• support and reference files

design/
├── blockstack/
├── blog/
├── chord/
│   ├── example-project1/
│   │   ├── comps/
│   │   ├── proofs/
│   │   └── support/
│   └── example-project2/
│       ├── comps/
│       ├── proofs/
│       └── support/
├── harmony/
├── hyperbelt/
├── labs/
├── onename/
├── passcard/
└── pr/

Git LFS setup:

›› More info on Git LFS

• Files and folders to be tracked

*.sketch (.gitattributes)
*.psd (.gitattributes)
*.psb (.gitattributes)
*.ai (.gitattributes)
*.zip (.gitattributes)
*.indd (.gitattributes)
*.pdf (.gitattributes)
*.ppt (.gitattributes)
*.mov (.gitattributes)
*.eps (.gitattributes)
*.tif (.gitattributes)
*.mp4 (.gitattributes)
*.mp3 (.gitattributes)
*.mv4 (.gitattributes)
*.avi (.gitattributes)
*.m4v (.gitattributes)
*.aaf (.gitattributes)
*.aep (.gitattributes)
*.aet (.gitattributes)
*.indl (.gitattributes)
*.indt (.gitattributes)
*.indb (.gitattributes)
*.dmg (.gitattributes)
*.xcodeproj (.gitattributes)
*.png (.gitattributes)
*.gif (.gitattributes)
*.jpeg (.gitattributes)
*.jpg (.gitattributes)
*.svg (.gitattributes)
*.tar.gz (.gitattributes)
*.qxd (.gitattributes)
*.asc (.gitattributes)
*.csv (.gitattributes)
*.doc (.gitattributes)
*.dot (.gitattributes)
*.gdoc (.gitattributes)
*.pages (.gitattributes)
*.myo (.gitattributes)
*.myob (.gitattributes)
*.tax (.gitattributes)
*.ofx (.gitattributes)
*.qif (.gitattributes)
*.otf (.gitattributes)
*.ttf (.gitattributes)
*.woff (.gitattributes)
*.ase (.gitattributes)
*.bmp (.gitattributes)
*.icns (.gitattributes)
*.ico (.gitattributes)
*.pict (.gitattributes)
*.pdd (.gitattributes)
*.tga (.gitattributes)
*.tiff (.gitattributes)
*.cdr (.gitattributes)
*.ps (.gitattributes)
*.gslides (.gitattributes)
*.key (.gitattributes)
*.keynote (.gitattributes)
*.pez (.gitattributes)
*.pot (.gitattributes)
*.pptx (.gitattributes)
*.thmx (.gitattributes)
*.aiff (.gitattributes)
*.wav (.gitattributes)
*.m4a (.gitattributes)
*.wma (.gitattributes)
*.mp2 (.gitattributes)
*.gsm (.gitattributes)
*.aac (.gitattributes)
*.swa (.gitattributes)
*.vox (.gitattributes)
*.psf (.gitattributes)
*.band (.gitattributes)
*.logic (.gitattributes)
*.gsheet (.gitattributes)
*.xlk (.gitattributes)
*.xls (.gitattributes)
*.xlsb (.gitattributes)
*.xlsm (.gitattributes)
*.xlsx (.gitattributes)
*.xlt (.gitattributes)
*.xltm (.gitattributes)
*.xlw (.gitattributes)
*.tsv (.gitattributes)
*.asf (.gitattributes)
*.dat (.gitattributes)
*.flv (.gitattributes)
*.fla (.gitattributes)
*.mpeg (.gitattributes)
*.mpg (.gitattributes)
*.rm (.gitattributes)
*.fcp (.gitattributes)
*.ppj (.gitattributes)
*.prproj (.gitattributes)
*.imovieproj (.gitattributes)
*.bin (.gitattributes)
*.diff (.gitattributes)
*.gzip (.gitattributes)
*.rar (.gitattributes)
*.tar (.gitattributes)
*.img (.gitattributes)
*.iso (.gitattributes)
blockchainid/* (.gitattributes)
blockstack/* (.gitattributes)
blog/* (.gitattributes)
chord/* (.gitattributes)
rhythm/* (.gitattributes)
hyperbelt/* (.gitattributes)
onename/* (.gitattributes)
passcard/* (.gitattributes)
labs/* (.gitattributes)
pr/* (.gitattributes)

[guylepage3]

do we want our contributors to understand how to set up lfs?

Yes. This will encourage more designers to contribute. The easier we make it for them to download all the assets, the easier it will be for them to contribute.

[guylepage3]

what files we want lfs to track?

List is included in the "old" README.md list above

[guylepage3]

minimize the list of files to track?

Great idea. let's cherry pick the from the file types we have currently in the repo

[guylepage3]

explain the typical git lfs workflow we use like our PR process we have a git lfs process?

This is something that we need to work out. Do you want to take an initial stab at it? Let's keep it simple if we can.

[estermer]

ok I will try and take an initial stab at this and we can go from there

[guylepage3]

Awesome sir! This will be huge for the community.. Let's grow this out. 😄

[estermer]

@guylepage3 I noticed that with git lfs there are already tracked filetypes in the .gitattributes.

So I was thinking we don't need to do a process for tracking all the files, we just need to show if a user adds a new file type how to track it.

Such as:

• download git lfs - brew install git-lfs
• git install lfs in the designs repo
• check the .gitattributes file if your file type is already being tracked
• if not then git lfs track '*.filetype'
• stage and commit your work

[guylepage3]

Good catch @estermer.

Let's not actually promote others adding new file tracking. Let's create a link to the Git LFS home page where they can easily figure out how to add files to track. https://git-lfs.github.com/

[estermer]

So if I understand right:

• No longer do we need a list of what files to track because they are being tracked already in .gitattributes
• We need them to still install Git LFS

I guess the question is, are contributors to designs ever creating new files that might have new untracked file types?

[guylepage3]

No longer do we need a list of what files to track because they are being tracked already in .gitattributes

We need them to still install Git LFS

Correct. 😄

I guess the question is, are contributors to designs ever creating new files that might have new untracked file types?

It's doubtful.

[estermer]

OK so in this case then we can just display the steps to download the Git LFS and initialize it

[guylepage3]

sounds good @estermer

[estermer]

@guylepage3 I was able to get a rough draft done for the Git LFS process if you want to take a look. I also added a blurb on the main readme advising contributors if they want to become regulars they should join our daily stand up with a link to them.

Also, question about the PR process, there is no develop branch. Would you want to add one? Or would you like to just leave it as design for only this repo?

Here is the LFS rough draft:

Install & Setup Git LFS:

Our projects use Git Large File Storage to manage project assets.

First download Git LFS, then initialize it in the main project repo:

$ cd ~/designs
$ git lfs install

To track files:

$ git lfs track '*.jpg' # track a filetype
$ git lfs track '*.jpeg' '*.png' # track multiple filetypes in one command
$ git lfs track 'example-project1/*' # track all files within a folder

We have already set up tracking for most file types (found in the .gitattribute file). If your project does not have the tracking it needs, please contact the repo maintainer.

›› More info on Git LFS

[guylepage3]

This is great @estermer 👍

Here's my response.

I also added a blurb on the main readme advising contributors if they want to become regulars they should join our daily stand up with a link to them.

Nice! 😄

Our projects use Git Large File Storage to manage project assets.

Blockstack Design uses Git Large File Storage to manage design files, compositions, support files and assets.