Skip to content
This repository has been archived by the owner on Apr 25, 2024. It is now read-only.

A collection of Vue components used in the web facing Creative Commons.

License

Notifications You must be signed in to change notification settings

cc-archive/vocabulary-components

Repository files navigation

Vocabulary logo

Creative Commons Vocabulary

Vue Vocabulary is a collection of Vue components used in the web-facing Creative Commons.

Code of conduct

CODE_OF_CONDUCT.md:

The Creative Commons team is committed to fostering a welcoming community. This project and all other Creative Commons open source projects are governed by our Code of Conduct. Please report unacceptable behavior to conduct@creativecommons.org per our reporting guidelines.

All Contributors

MIT license PRs welcome GitHub Actions Netlify

Vocabulary is the code implementation of Creative Commons' Design Language. It makes it easier to develop Creative Commons apps while ensuring a consistently familiar experience.

Installation

To set up, you will need to have Node.js and npm installed.

Project dependencies

If you have the system dependencies installed, you can install the project dependencies via npm by running:

npm install

Building the packages

To build the files for release, run the following command:

npm run build

To build the documentation, run:

npm run build:documentation

Using

To use Vocabulary in your projects, refer to this document.

Contributing

We're always looking for contributors to help us find and fix bugs, build new features, improve the project documentation or translate the project to another language.See CONTRIBUTING.md.

Vocabulary is continuously evolving and improving. You can contribute to the project in a number of ways.

What How
Code If you are a developer, feel free to resolve open issues, raise PRs, add new features to existing components, or add new components altogether.
Design If you are a designer, your inputs on making every component more intuitive, aesthetic, and joyful will reverberate throughout the entire ecosystem.
Test If you are a user of these components, your feedback, bug reports, and feature requests will drive the project forward so that we can meet your needs.
Write If you have a knack for writing technical articles, you could be the voice of the library's documentation, making it easy to use and understand.
Share If you can't contribute in these ways, you can refer the project to a friend who might be able to. Spreading the word is the easiest way to help out.

Interested?

The following instructions are in addition to the processes in our general Contribution and Pull Request guidelines on the Creative Common Open Source website. If you haven't read them already, read them first.

These instructions are a port of the general guidelines tailored specifically for Vocabulary.

Discussing Changes

For bug reports and feature requests, use GitHub issues with the appropriate labels. We can discuss the possibility of that change or new feature being implemented and released in the future. This lets us come to an agreement about the proposed idea before any work is done.

Assigning work

If the issue is already assigned to somebody, it is considered polite to give the last assignee a week's time to attempt it before you do. You can express an intention to work on it nonetheless so that it can be reassigned to you if the last assignee bails.

Submitting PRs without commenting your intent to solve an issue is risky because if someone else does ask to work on it before your PR comes in, your PR will be put on hold for a week.

Making changes

Do all work on its own branch. Use meaningful branch names.

Examples

  broken_links_readme
  typo_misspelled

Use clean commit messages, as imperative sentences in the present tense.

Examples:

  Remove the broken links from the `README.md` file
  Fix the typo on line 12, where 'misspelled' was misspelled as 'mispelled'

Update your fork from time to time. See GitHub Help pages for instructions on how to do that.

Write new tests for the changes you make and update existing ones.

Testing

While our Husky setup will prevent you from committing poorly linted code, it cannot catch logical problems. For that we have some tests.

Unit

Running unit tests is easy.

  npm run test:unit

Running this command will run a general test. Test can also be run for individual packages by running their respective commands

  npm run test:vue-vocabulary

CI/CD

We use Github Actions to automate some parts of our CI/CD pipeline. When contributing code, rather than having to commit/push every time a check fails, it will be useful to automate this process on your development environment to be sure all checks done will be successful.

Install Dependencies

- Docker

If you don't have Docker installed, you can follow the links below to set it up depending on your environment.

- Nektos/act

Install using any of the methods below depending on your environment.

Package / Method Command
Homebrew (Linux/macOS) brew install act
MacPorts (macOS) sudo port install act
Chocolatey (Windows) choco install act-cli
Scoop (Windows) scoop install act
AUR (Linux) yay -S act
Nix (Linux/macOS) Nix recipe
Go (Linux/Windows/macOS/any other platform supported by Go) go install github.com/nektos/act@latest
Manual Download (GitHub) Download the latest release and add the path to your binary into your PATH.

Running Workflows

Once you have downloaded and installed the package with its dependencies, it will automatically read the CI scripts from your /.github/workflows folder.

Trigger all workflows

To trigger all the CI workflows, cd into the root folder of this project (vocabulary) and run the command:

act

If you have permission errors, you run it as a sudo user:

sudo act

NB: When you run it for the first time, it will ask you to choose a docker image to be used as default.

Trigger a specific workflow

To run a specific workflow, for example, the build workflow, you can specify it by running:

act -j build

If you want to see all the workflows available, you run the command:

act -l

Currently, we have four CI workflows namely:

  • build
  • lint
  • test
  • update_release_draft

We recommended that you run these workflows on your development environment so that if any errors occur, you can identify and resolve them before opening a PR.

You can refer the Netktos/act Documentation for more commands and configuration options.

License

Licensed under the Expat/MIT license.

Contributors ✨

Thanks goes to these wonderful people (emoji key):


Akpan Abraham

πŸ’»

Anik Das

πŸ’»

Arushi Verma

πŸ’»

Breno Ferreira

πŸ’» πŸ‘€

Chidiebere Onyegbuchulem

πŸ’»

Dhruv Bhanushali

πŸ’» πŸ§‘β€πŸ« πŸ‘€

Dhruvi Butti

πŸ’» 🎨

Efio-esien Efiom

πŸ’»

Hitesh

πŸš‡ ⚠️ πŸ“¦ πŸ’»

Hugo Solar

πŸ’» πŸ‘€

Jahnvi Gupta

🎨 πŸ’» ⚠️

Kriti Godey

πŸ“†

Krystle Salazar

πŸ“–

Megha Varshney

πŸ’» 🎨

Mohammad Warid

πŸš‡ πŸ’»

MuluhGodson

πŸ“–

Neel Shah

πŸ’»

Nehal Nevle

πŸ’»

Silvina Tamburini

⚠️ πŸ’»

Tanuj Agarwal

πŸ“–

Vignesh Kumar

πŸ’»

kush aggarwal

πŸ’»

This project follows the all-contributors specification. Contributions of any kind welcome!