From f45f549b29ee510546492381a10cf622940750a2 Mon Sep 17 00:00:00 2001 From: Zac Wood Date: Sun, 16 Dec 2018 11:28:27 -0500 Subject: [PATCH] README update and added CONTRIBUTING.md --- CONTRIBUTING.md | 179 ++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 44 +++++------- 2 files changed, 197 insertions(+), 26 deletions(-) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..36afb80 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,179 @@ +# Contributing to Schedules + +We would love for you to contribute to Schedules and help make it even better +than it is today! As a contributor, here are the guidelines we would like you to +follow: + + - [Question or Problem?](#question) + - [Issues and Bugs](#issue) + - [Feature Requests](#feature) + - [Coding Style](#style) + - [Submission Guidelines](#submit) + - [Submitting a Pull Request](#submit-pr) + +## Got a Question or Problem? + +Please, do not open issues for the general support questions as we want to keep +GitLab issues for bug reports and feature requests. You've got much better +chances of getting your question answered on [Slack Group][slack] where +questions should be asked in their respective channels. + +## Found a Bug? + +If you find a bug in the source code, you can help us by +[submitting an issue](#submit-issue) to our [GitLab Repository][gitlab]. Even +better, you can [submit a Merge Request](#submit-pr) with a fix. + +## Missing a Feature? + +You can *request* a new feature by [submitting an issue](#submit-issue) to our +GitLab Repository. If you would like to *implement* a new feature, please ensure +an issue already exists to be associated with your commits. + +* For any **contribution**, first [open an issue](#submit-issue) and outline your proposal so that it can be +discussed. This will also allow us to better coordinate our efforts, prevent duplication of work, +and help you to craft the change so that it is successfully accepted into the project. + +## Coding style + +The style for this project is the [Relaxed Ruby Style](http://relaxed.ruby.style), which is a subset of the community-driven [Ruby style guide](https://github.com/bbatsov/ruby-style-guide) with more relaxed rules. + +A great tool for making sure your code meets the project's style is [RuboCop](https://github.com/bbatsov/rubocop). To use RuboCop, install it by running the command + + gem install rubocop + +Then, when inside the `/schedules/` directory, you can run the command `rubocop` to see where your style does not match the project's. + +## Submission Guidelines + +### Submitting an Issue + +Before you submit an issue, please search through open issues, maybe an issue for +your problem already exists and the discussion might inform you of workarounds +readily available. + +We want to fix all the issues as soon as possible, but before fixing a bug we +need to reproduce and confirm it. In order to reproduce bugs we may +ask you to describe a use-case that fails to assist in the debugging process. + +In GitLab there are issue templates that you can use which paste in a sample +format for you to use. + +Check out the following issue for an example: [https://git.gmu.edu/srct/schedules/issues/11](https://git.gmu.edu/srct/whats-open/issues/31) + +You can file new issues by filling out our [new issue form][new-issue]. + +### Steps to contribute and submit a Merge Request (MR) + +Before you submit your Merge Request (MR) consider the following steps: + +* Search [GitLab][merge-request] for an open or closed MR that relates to your + submission. You don't want to duplicate effort. + +* Pull the latest commits from GitLab + + ```sh + git pull + ``` + +* Check into the current development branch: + + All new commits are merged into this development branch before going live on + the site in a tagged release (merge into master branch). + + ```sh + git checkout consolidation + ``` + +* Create a new git branch: + + ```sh + git checkout -B ##-shortdescription + # Example + git checkout -B 31-contibution-guidelines-proposal + ``` + + All branches need to follow the above convention (`##-shortdescription`) `##` + in this case represents the issue number that your branch is related to. Each + issue has one and only one branch and each branch has one and only one purpose: + to add, modify, or remove a feature/bug from the repo. `shortdescription` is + a few hyphon (`-`) seperated words that consisely describe the branch. This helps people + who may be unfamiliar with the issue number to know at a glance what the branch + +* Now you're ready to write your code in your new branch! Make sure to follow + listed [style](#rules) & [commit](#commit) guidelines/rules when contributing + code. + +* Before you push your code to GitLab it is suggested that you run all unit tests locally. + + ```sh + rails test + ``` + +* Commit your changes using a descriptive commit message. + + ```sh + git add --all + git commit # first line is title, two newlines is description + ``` + +* You will need to ask in the slack channel to be added to the GitLab repo. This + step is necessary such that you have the necessary permissions to push up your + branch. + +* Push your branch to GitLab: + + ```sh + git push origin ##-shortdescription + # ex. + git push origin 31-contibution-guidelines-proposal + ``` + +* In GitLab, send a merge request to the current development branch. + +* If we suggest changes to your branch then: + * Make the required updates. + * Re-run the unit tests to ensure tests are still passing. + * Rebase your branch and force push to your GitLab repository (this will update + your Merge Request): + + ```sh + git rebase consolidation -i + git push -f + ``` + +That's it! Thank you for your contribution! :tada: + +#### After your merge request is merged + +After your merge request is merged, you can safely delete your branch and merge +the changes from the main (upstream) repository: + +* Delete the remote branch on GitLab either through the GitLab web UI or your + local shell as follows: + + ```sh + git push origin --delete ##-shortdescription + # ex. + git push origin --delete 31-contibution-guidelines-proposal + ``` + +* Check out the current development branch: + + ```sh + git checkout consolidation -f + ``` + +* Delete the local branch: + + ```sh + git branch -D ##-shortdescription + # ex. + git branch -D 31-contibution-guidelines-proposal + ``` + +* Update your current development branch with the latest upstream version: + + ```sh + git l --ff upstream consolidation + ``` diff --git a/README.md b/README.md index 24847c4..a626019 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,29 @@ # Schedules -Schedules is a web app that is written with Ruby on Rails and allows students to import their class schedules into popular calendar managers. +Schedules is a web app that is written with Ruby on Rails and allows students build, share, and export their Schedules. It includes a powerful search engine which lets students get information about both courses and professors at GMU. The project manager for Schedules is Zac Wood. ## Contributing -Schedules is currently being completely rewritten from scratch, so all help is much appreciated. See the current project [issues](https://git.gmu.edu/srct/schedules/issues) to see what needs to get done. +Schedules is currently in version 2 and is a somewhat mature web application. However, there are always new features that can be added and old bugs that need fixing, so all help is much appreciated. See the current project [issues](https://git.gmu.edu/srct/schedules/issues) to see what needs to get done, or submit an issue of your own if you have a feature request or found a bug. If you need any help, please feel free to reach out in the `#schedules` channel in our [Slack group](https://srct.slack.com/). This is where most of the discussion about the project occurs, so if you are interesting in contributing, please join and say hi! +### Learning Ruby on Rails + +Rails is a web framework written in Ruby that makes developing web applications fun and productive. However, it does have quite a steep learning curve. Before you contribute to Schedules, it's worth learning the basics of Rails first. This will give you the ability to understand and navigate through the project structure before trying to make your contribution. +Thankfully, there are tons of great free online resources to learn Rails. Here are a few that we recommend to newcomers: +- [Derek Banas' Ruby on Rails Tutorial (30min)](https://www.youtube.com/watch?v=GY7Ps8fqGdc) +- [Rails Tutorial (free online ebook)](https://www.railstutorial.org/book) +- [Official Getting Started with Rails](https://guides.rubyonrails.org/getting_started.html) + +### Modifying and Deploying Code + +Please read through the CONTRIBUTING.md document for in depth +instructions on the process of making and submitting changes to +Schedules. + ## Setup instructions ### Install Ruby and Rails @@ -27,7 +41,7 @@ the SRCT code respository, with SSH. git clone git@git.gmu.edu:srct/schedules.git -Run `cd schedules/` to enter the cloned directory +Run `cd schedules/` to enter the cloned directory. ## Setting up Project @@ -37,7 +51,7 @@ Execute `cd schedules/` to enter the Project directory. To install the project dependencies, run the `bundle install` command. ### Database -To populate your local database, run `rake db:migrate` and `rake db:seed`. This sets up your local database and loads it with data from Patriot Web. +To populate your local database, run `rails db:migrate` and `rails db:seed`. This sets up your local database and loads it with data from Patriot Web. **NOTE:** Sometimes Patriot Web doesn't appriciate being parsed. If you're having problems, please let us know in [Slack](https://srct.slack.com/)! @@ -47,25 +61,3 @@ please let us know in [Slack](https://srct.slack.com/)! While developing for schedules, it is useful to have development servers running. To start the Project, run the `rails server` command in the `/schedules` directory. The website should now be accessible from `localhost:3000` - - -## Testing -Before you make a commit, you should ensure you new code passes the project's tests. - -It is recommended that you write tests for any new code you add, but this is not required. - -To run the Project's tests, run the command `rails test` from the `schedules` directory. - -## Opening issues - -Please use the issue templates located on the new issue page when opening issues. Any issues that do not follow a template will not be accepted. - -## Coding style - -The style for this project is the [Relaxed Ruby Style](http://relaxed.ruby.style), which is a subset of the community-driven [Ruby style guide](https://github.com/bbatsov/ruby-style-guide) with more relaxed rules. - -A great tool for making sure your code meets the project's style is [RuboCop](https://github.com/bbatsov/rubocop). To use RuboCop, install it by running the command - - gem install rubocop - -Then, when inside the `/schedules/` directory, you can run the command `rubocop` to see where your style does not match the project's. -- GitLab