Repository House Cleaning

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,38 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Desktop (please complete the following information):**
+ - OS: [e.g. iOS]
+ - Browser [e.g. chrome, safari]
+ - Version [e.g. 22]
+
+**Smartphone (please complete the following information):**
+ - Device: [e.g. iPhone6]
+ - OS: [e.g. iOS8.1]
+ - Browser [e.g. stock browser, safari]
+ - Version [e.g. 22]
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,11 @@
+# What Issue Does This PR Cover, If Any?
+
+Resolves #001 <!--fill issue number-->
+
+### What Changed? And Why Did It Change?
+
+### How Has This Been Tested?
+
+### Please Provide Screenshots
+
+### Additional Comments

CONTRIBUTING.md

@@ -0,0 +1,112 @@
+# Welcome Contributors! 👋
+We ♥ contributors! By participating in this project, you agree to abide by the Ruby for Good [code of conduct](https://github.com/rubyforgood/skillrx?tab=coc-ov-file#readme).
+
+If you're new here, here are some things you should know:
+- This is a new project, so we are still working on files like... well, like this one
+- We are launching development at [FOSDEM 2025](https://fosdem.org/2025/) on the weekend of February 1
+- Application requirements [are in our wiki](https://github.com/rubyforgood/skillrx/wiki/Requirem).
+- You can get a good overview of the project by [filtering the issues by the "Epic" label](https://github.com/rubyforgood/skillrx/issues?q=is%3Aissue%20state%3Aopen%20label%3AEPIC)
+- Issues tagged "Help Wanted" are self-contained and great for new contributors
+- Pull Requests are reviewed within a week or so
+- Ensure your build passes linting and tests and addresses the issue requirements
+- This project relies entirely on volunteers, so please be patient with communication
+
+# Communication 💬
+If you have any questions about an issue, comment on the issue, open a new issue, or ask in [the RubyForGood slack](https://join.slack.com/t/rubyforgood/shared_invite/zt-2k5ezv241-Ia2Iac3amxDS8CuhOr69ZA). SkillRX has a channel in the Slack which is currently labeled by an earlier name for the project: #medstick. We will be establishing office hours once the project is underway.
+
+We are happy to answer your questions. Just ask, and someone will be there to help you!
+
+You won't be yelled at for giving your best effort. The worst that can happen is that you'll be politely asked to change something. We appreciate any sort of contributions, and don't want a wall of rules to get in the way of that.
+
+# Wiki Contribution Workflow
+1. Follow this [SO post](https://stackoverflow.com/a/56480628/13342792) to force push the main repo's Wiki to your fork's Wiki.
+2. Make edits to your fork's Wiki.
+3. Create a documentation issue about your changes. Make sure to note which pages you changed and link to your fork's Wiki.
+4. Someone will review and approve your changes and merge them into the main Wiki following this [SO post](https://stackoverflow.com/a/56810747/13342792)
+
+# 🤝 Code Contribution Workflow
+
+1. **Identify an unassigned issue**. Read more [here](#issues) about how to pick a good issue.
+2. **Assign it** to avoid duplicated efforts (or request assignment by adding a comment).
+3. **Fork the repo** if you're not a contributor yet. Read about becoming a contributor [here](#becoming-a-repo-contributor).
+4. **Create a new branch** for the issue using the format `XXX-brief-description-of-feature`, where `XXX` is the issue number.
+5. **Commit fixes locally** using descriptive messages that indicate the affected parts of the app.
+6. If you create a new model run `bundle exec annotate` from the root of the app
+7. **Create RSpec tests** to validate that your work fixes the issue (if you need help with this, please reach out!). Read guidelines [here](#writing-browsersystemfeature-testsspecs).
+8. **Run the tests** and make sure all tests pass successfully; if any fail, fix the issues causing the failures. Read guidelines [here](#test-before-submitting-pull-requests).
+9. **Final commit** if tests needed fixing.
+10. **Squash smaller commits.** Read guidelines [here](#squashing-commits).
+11. **Push** up the branch
+12. **Create a pull request** and indicate the addressed issue (e.g. `Resolves #1`) in the title, which will ensure the issue gets closed automatically when the pull request gets merged. Read PR guidelines [here](#pull-requests).
+13. **Code review**: At this point, someone will work with you on doing a code review. The automated tests will run linting, rspec, and brakeman tests. If the automated tests give :+1: to the PR merging, we can then do any additional (staging) testing as needed.
+
+14. **Merge**: Finally if all looks good the core team will merge your code in; if your feature branch was in this main repository, the branch will be deleted after the PR is merged.
+
+15. Deploys are currently done about once a week! Read the deployment process [here](#deployment-process).
+
+## Issues
+Please feel free to contribute! While we welcome all contributions to this app, pull-requests that address outstanding Issues *and* have appropriate test coverage for them will be strongly prioritized. In particular, addressing issues that are tagged with the next milestone should be prioritized higher.
+
+All work is organized by issues.
+[Find issues here.](https://github.com/rubyforgood/skillrx/issues)
+
+If you would like to contribute, please ask for an issue to be assigned to you.
+If you would like to contribute something that is not represented by an issue, please make an issue and assign yourself.
+Only take multiple issues if they are related and you can solve all of them at the same time with the same pull request.
+
+## Becoming a Repo Contributor
+
+Users that are frequent contributors and are involved in discussion (join the slack channel! :)) may be given direct Contributor access to the Repo so they can submit Pull Requests directly instead of Forking first.
+
+### Codespaces
+When running tests in browser, visit the forwarded port 6080 URL to see the browser in Codespaces. You can also visit this port to access the GUI desktop in Codespaces.
+
+In VSCode Run and Debug view, there are some helpful defaults for running RSpec tests in browser at your cursor as well as attaching to a live server. Make sure the Ruby LSP server is started before debugging.
+
+## Squashing commits
+
+Consider the balance of "polluting the git log with commit messages" vs. "providing useful detail about the history of changes in the git log". If you have several smaller commits that serve a one purpose, you are encouraged to squash them into a single commit. There's no hard and fast rule here about this (for now), just use your best judgement. Please don't squash other people's commits. Everyone who contributes here deserves credit for their work! :)
+
+Only commit the schema.rb only if you have committed anything that would change the DB schema (i.e. a migration).
+
+## Pull Requests
+### Stay scoped
+
+Try to keep your PRs limited to one particular issue, and don't make changes that are out of scope for that issue. If you notice something that needs attention but is out of scope, please [create a new issue](https://github.com/rubyforgood/human-essentials/issues/new).
+
+### In-flight pull requests
+
+If you are so inclined, you can open a draft PR as you continue to work on it. Sometimes we want to get a PR up there and going so that other people can review it or provide feedback, but maybe it's incomplete. This is OK, but if you do it, please tag your PR with `in-progress` label so that we know not to review / merge it.
+
+## Tests 🧪
+### Writing Browser/System/Feature Tests/Specs
+
+Add a test for your change. If you are adding functionality or fixing a bug, you should add a test!
+
+If you are inexperienced in writing tests or get stuck on one, please reach out for help :)
+
+#### Guidelines
+- Prefer request tests over system tests (which run much slower) unless you need to test Javascript or other interactivity
+- When creating factories, in each RSpec test, hard code all values that you check with a RSpec matcher. Don't check FactoryBot default values. See [#4217](https://github.com/rubyforgood/human-essentials/issues/4217) for why.
+- Keep individual tests tightly scoped, only test the endpoint that you want to test. E.g. create inventory directly using `TestInventory` rather than using an additional endpoint.
+- You probably don't need to write new tests when simple re-stylings are done (ie. the page may look slightly different but the Test suite is unaffected by those changes).
+
+### Test before submitting pull requests
+Before submitting a pull request, run all tests and lints. Fix any broken tests and lints before submitting a pull request.
+
+#### Continuous Integration
+- There are Github Actions workflows which will run all tests in parallel using Knapsack and lints whenever you push a commit to your fork.
+- Once your first PR has been merged, all commits pushed to an open PR will also run these workflows.
+
+#### Local testing
+- Run all lints with `bin/lint`. (You can lint a single file/folder with `bin/lint {path_to_folder_or_file}`.)
+- Run all tests with `bundle exec rspec`
+- You can run a single test with `bundle exec rspec {path_to_test_name}_spec.rb` or on a specific line by appending `:LineNumber`
+- If you need to skip a failing test, place `pending("Reason you are skipping the test")` into the `it` block rather than skipping with `xit`. This will allow rspec to deliver the error message without causing the test suite to fail.
+
+```ruby
+  it "works!" do
+    pending("Need to implement this")
+    expect(my_code).to be_valid
+  end
+```

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Ruby for Good
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

code_of_conduct.md

@@ -0,0 +1,33 @@
+# Code of Conduct
+
+Like the technical community as a whole, the Ruby for Good team and community is made up of a mixture of professionals and volunteers from all over the world, working on every aspect of the mission - including mentorship, teaching, and connecting people.
+
+Diversity is one of our huge strengths, but it can also lead to communication issues and unhappiness. To that end, we have a few ground rules that we ask people to adhere to when they're participating within this community and project. These rules apply equally to founders, mentors and those seeking help and guidance.
+
+This isn't an exhaustive list of things that you can't do. Rather, take it in the spirit in which it's intended - a guide to make it easier to enrich all of us and the technical communities in which we participate.
+
+This code of conduct applies to all spaces managed by the Ruby for Good team or at Georgetown University. This includes IRC, Slack, the mailing lists, the issue tracker, Ruby for Good events, and any other forums created by the project team which the community uses for communication.
+
+Be welcoming, friendly, and patient. Be considerate. Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions. Remember that we're a world-wide community, so you might not be communicating in someone else's primary language.
+
+Be respectful. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It's important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the Ruby for Good community should be respectful when dealing with other members as well as with people outside the Ruby for Good community.
+
+Be careful in the words that you choose. We are a community of professionals, and we conduct ourselves professionally. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren't acceptable. This includes, but is not limited to:
+
+- Violent threats or language directed against another person.
+- Sexist, racist, or otherwise discriminatory jokes and language.
+- Posting sexually explicit or violent material.
+- Posting (or threatening to post) other people's personally identifying information ("doxing").
+- Personal insults, especially those using racist or sexist terms.
+- Unwelcome sexual attention.
+- Advocating for, or encouraging, any of the above behavior.
+- Repeated harassment of others. In general, if someone asks you to stop, then stop.
+- If you believe someone is violating the code of conduct, we ask that you report it by emailing [Teresa Finn](mailto:teresa@rubyforgood.org) or [Kalimar Maia](mailto:kalimar@rubyforgood.org). Any email received will be kept confidential.
+
+When we disagree, try to understand why. Disagreements, both social and technical, happen all the time and Ruby is no exception. It is important that we resolve disagreements and differing views constructively. Remember that we're different. The strength of Ruby comes from its varied community, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn't mean that they're wrong. Don't forget that it is human to err and blaming each other doesn't get us anywhere, rather offer to help resolving issues and to help learn from mistakes.
+
+If a participant engages in harassing behavior, the organizers may take any action they deem appropriate, including warning the offender or expulsion from the event with no refund. The organizers and volunteers will be introduced at the beginning of the event.
+
+We're people trying to make the world better.
+
+_For our Code of Conduct, we have based ours on the excellent one made by the Django Project._