docs: integrate UC OSPO community health templates and guides

Author: jt14den

CONTRIBUTING.md

@@ -1,85 +1,217 @@
-# Contributing to the UC OSPO Education Website
+# CONTRIBUTING
 
-We welcome contributions to the UC OSPO Education Website! This project aims to provide a welcoming and accessible platform for learners interested in open source.
+[TODO: rename this file to `README.md`; i.e. remove the template reference]
 
-This guide will help you get started with contributing to this project.
+This is a template document for UC projects can use to help build the documentation in your project repos. It requires editing before it is ready to use, and you can find guides for using these templates on [our website](https://ucospo.net/oss-resources/#template-guides). Please feel free to [reach out to our Laura](mailto:[email protected]), our Community Manager, if you have any questions!
 
-## Code of Conduct
+Search for the word `TODO` in this template to identify parts that require customization; e.g. line 3 above lets you know you should rename this file.. When you finish editing the template, remove the `TODO` bits.
+
+[TODO: delete the lines between line 1 and the "Welcome" heading]
+
+## Welcome!
+
+[TODO: edit welcome text below]
+
+Welcome! We're glad you want to contribute to our project! 💖
+
+As you get started, you're in the best position to give us feedback on areas of our project that we need help with including:
+
+* Problems found during setting up a new developer environment
+* Gaps in our Quickstart Guide or documentation
+* Bugs in our automation scripts
+
+If anything doesn't make sense, or doesn't work when you run it, please open a bug report and let us know!
+
+## Table of Contents
+
+[TODO: edit the Table of Contents]
+
+* [Ways to Contribute](#ways-to-contribute)
+* [Come to Community Calls](#come-to-community-calls)
+* [Finding an Issue](#finding-an-issue)
+* [Setting Up a Dev Environment](#setting-up-a-dev-environment)
+* [Running Tests](#running-tests)
+* [Asking for Help](#asking-for-help)
+* [Norms for Commits](#norms-for-commits)
+* [Pull Request Lifecycle](#pull-request-lifecycle)
+* [Code of Conduct](#code-of-conduct)
+
+## Ways to Contribute
+
+[TODO: edit this to reflect the kinds of contributions you'd like to receive for your project]
+
+We welcome many different types of contributions, including:
+
+* New features
+* Builds, CI/CD
+* Bug fixes
+* Documentation
+* Issue Triage
+* Answering questions on Slack/Mailing List
+* Web design
+* Communications/Social Media/Blog Posts
+* Release management
+
+Not everything happens through a GitHub pull request. Please come to our meetings](TODO) or [contact us](/UC-OSPO-Network/templates/blob/d8ba9301beb523c10a7195ddf0fb70a068312022/TODO) and let's discuss how we can work together.
+
+## Come to Community Calls
+
+[TODO: Maybe your project doesn't have [community calls](https://opensource.com/open-organization/16/1/community-calls-will-increase-participation-your-open-organization), in which case you can omit this section. But you might consider trying them out!]
+
+Anyone interested in our project is welcome to come to any of [our community calls](TODO: add a link to your community calls)! You never need an invite to join us. In fact, we want you to join us, even if you don’t have anything you feel like you want to contribute. Just being there is enough!
+
+You don’t have to turn on your video. The first time you come, just introducing yourself is perfectly fine. Over time, we hope that you feel comfortable voicing your opinions, giving feedback on others’ ideas, and even sharing your own ideas, and experiences.
+
+## Finding an Issue
 
-Please note that this project is released with a [Code of Conduct](CODE_OF_CONDUCT.md). By participating in this project, you agree to abide by its terms.
-
-## How to Contribute
-
-There are many ways to contribute, not just by writing code:
-
-*   **Reporting Bugs:** If you find a bug, please open an [issue](https://github.com/UC-OSPO-Network/education/issues) and describe the problem in detail.
-*   **Suggesting Enhancements:** Have an idea for a new feature or improvement? Open an [issue](https://github.com/UC-OSPO-Network/education/issues) to discuss it.
-*   **Writing Documentation:** Improving our documentation (guides, explanations, examples) is always welcome.
-*   **Submitting Code:**
-    1.  **Fork** the repository.
-    2.  **Clone** your forked repository to your local machine.
-        ```bash
-        git clone https://github.com/YOUR_GITHUB_USERNAME/education.git
-        cd education
-        ```
-    3.  **Install dependencies**:
-        ```bash
-        npm install
-        ```
-    4.  **Create a new branch** for your feature or bug fix:
-        ```bash
-        git checkout -b feature/your-feature-name
-        # or
-        git checkout -b bugfix/issue-description
-        ```
-    5.  **Make your changes**.
-    6.  **Run the development server** to preview your changes:
-        ```bash
-        npm run dev
-        ```
-    7.  **Test your changes**: Ensure everything works as expected and doesn't introduce new bugs.
-    8.  **Commit your changes** with a clear and concise commit message. Follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) guidelines (e.g., `feat: add new filter option`, `fix: correct typo on homepage`).
-        ```bash
-        git add .
-        git commit -m "feat: your commit message"
-        ```
-    9.  **Push your branch** to your forked repository:
-        ```bash
-        git push origin feature/your-feature-name
-        ```
-    10. **Open a Pull Request (PR)** to the `main` branch of the original repository.
-        *   Provide a clear title and description for your PR.
-        *   Reference any related issues (e.g., `Closes #123` or `Fixes #123`).
-
-## Development Setup
-
-### Local Development
-
-1.  **Clone the repository:**
-    ```bash
-    git clone https://github.com/UC-OSPO-Network/education.git
-    cd education
-    ```
-2.  **Install dependencies:**
-    ```bash
-    npm install
-    ```
-3.  **Start the development server:**
-    ```bash
-    npm run dev
-    ```
-    This will start a local server, usually at `http://localhost:4321`.
-
-### Build for Production
-
-To build the project for production, run:
-
-```bash
-npm run build
+[TODO: edit this section as needed]
+
+We have good first issues for new contributors and help wanted issues suitable for any contributor. [good first issue](/UC-OSPO-Network/templates/blob/d8ba9301beb523c10a7195ddf0fb70a068312022/TODO) has extra information to help you make your first contribution. [help wanted](/UC-OSPO-Network/templates/blob/d8ba9301beb523c10a7195ddf0fb70a068312022/TODO) are issues suitable for someone who isn't a core maintainer and is good to move onto after your first pull request.
+
+Sometimes there won’t be any issues with these labels. That’s ok! There is likely still something for you to work on. If you want to contribute but you don’t know where to start or can't find a suitable issue, you can [TODO: explain how people can ask for an issue to work on].
+
+Once you see an issue that you'd like to work on, please post a comment saying that you want to work on it. Something like "I want to work on this" is fine.
+
+## Setting up a Dev Environment
+
+[TODO: edit the steps provided for what's needed for your project]
+
+Clone the project:
+
+```shell
+git clone yourprojecturl
+```
+
+Install dependencies:
+
+```shell
+install command
 ```
 
-This will generate the static files in the `dist/` directory.
+## Running Tests
+
+[TODO: Describe the process you use to test code in your project]
+
+1. Step one
+2. Step two
+
+## Asking for Help
+
+The best way to reach us with a question when contributing is to ask on:
+
+[TODO: Pick the way(s) that you prefer people ask for help]
+
+* The original Github issue
+* The developer mailing list
+* Our Slack channel
+
+## Norms for Commits
+
+[TODO: edit this section to reflect what's needed for your project]
+
+Our project uses [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), and we require [commit signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). Please let us know if you need help with these!
+
+## Pull Request Lifecycle
 
-## Getting Help
+[TODO: Edit the text below to describe your pull request process. You don't need to adopt every aspect! Pick and choose what makes sense for *your* project]
+
+### Before You Submit
+
+When you submit your pull request, or you push new commits to it, our automated systems will run some checks on your new code. We require that your pull request passes these checks, but we also have more criteria than just that before we can accept and merge it. We recommend that you check the following things locally before you submit your code:
+
+* First thing to check
+* Another thing to check
+
+#### When to Submit
+
+Submit your pull request when you have a working implementation that addresses the issue or feature request. Your code should be tested and ready for review, even if you're open to suggestions for improvements.
+
+#### Draft vs. Ready PRs
+
+* Use **Draft PRs** when your work is incomplete or you want early feedback on your approach
+* Convert to **Ready for Review** when your implementation is complete and tested
+* Mark as ready even if you expect minor changes during review
+
+#### Branch Strategy
+
+Create a feature branch from the latest `main` branch. Use descriptive branch names like `feature/add-user-authentication` or `fix/memory-leak-in-parser`.
+
+### Submission Process
+
+#### PR Scope
+
+We prefer **small, focused pull requests** that address a single issue or implement one feature. Large PRs are harder to review and more likely to conflict with other changes. If your feature is large, consider breaking it into multiple PRs.
+
+#### Signaling Readiness
+
+* Remove "Draft" status when ready for review
+* Ensure all CI checks are passing
+* Include a clear description of what the PR does and why
+* Link to relevant issues using "Fixes #123" or "Addresses #456"
+
+### Review Process
+
+**Initial Review Timeline**: Expect an initial review within **3-5 business days**. Complex PRs may take longer.
+
+**Follow-up Reviews**: After addressing feedback, expect follow-up reviews within **2-3 business days**.
+
+#### Requesting Reviews
+
+* After pushing changes, add a comment like "Ready for re-review" or "@mention" specific reviewers
+* If your PR hasn't been reviewed after the expected timeline, add a polite comment requesting status
+* For urgent fixes, mention the urgency in your comment
+
+### Handling Common Situations
+
+#### Stalled Pull Requests
+
+If your PR appears stalled:
+
+1. First, check if all feedback has been addressed
+2. After 1 week of no activity, add a polite comment requesting status
+3. If still no response after another week, reach out via [preferred communication channel]
+
+#### Abandoned Pull Requests
+
+If you can no longer continue work on your PR:
+
+* Comment on the PR explaining the situation
+* Maintainers may either:
+    * Take over the PR and push additional commits to complete it
+    * Close the PR and create a new issue for others to pick up
+    * Close the PR if the change is no longer needed
+
+#### Follow-up Work
+
+* Small follow-up changes should be addressed in the same PR when possible
+* Larger follow-ups or new issues discovered during review should be handled in separate issues/PRs
+* Use "TODO" comments sparingly and create follow-up issues for any deferred work
+
+### After Your PR is Merged
+
+**Release Timeline**: Merged pull requests are included in the next release, which typically happens:
+
+* **Patch releases**: Every 2-4 weeks for bug fixes
+* **Minor releases**: Every 1-3 months for new features
+* **Major releases**: As needed for breaking changes
+
+#### Release Process
+
+After merge, your changes will:
+
+1. Be available immediately in the `main` branch
+2. Go through additional testing in our staging environment
+3. Be included in the next scheduled release
+4. Be documented in the changelog with attribution
+
+#### Staying Updated
+
+Watch the repository to be notified when your contributions are released. We'll also tag you in release notes when your PR introduces significant changes.
+
+---
+
+*Questions about the PR process? Feel free to ask in the issue comments, discussions, or reach out to the maintainers directly.*
+
+## Code of Conduct
 
-If you have any questions or get stuck, please open an [issue](https://github.com/UC-OSPO-Network/education/issues), and we'll do our best to help you out!
+Please read our [Code of Conduct](TODO: link to your project's CoC)

LICENSE

@@ -1,21 +1,38 @@
-MIT License
-
-Copyright (c) 2025 UC OSPO Network
-
-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.
+[TODO: rename this file to `license.txt`; i.e. remove the template reference]
+
+This is a template document for UC projects can use to help build the documentation in your project repos. It requires editing before it is ready to use, and you can find guides for using these templates on [our website](https://ucospo.net/oss-resources/#template-guides). Please feel free to [reach out to our Laura](mailto:[email protected]), our Community Manager, if you have any questions!
+
+Search for the word `TODO` in this template to identify parts that require customization; e.g. line 3 above lets you know you should rename this file.. When you finish editing the template, remove the `TODO` bits.
+
+IMPORTANT: WE'VE INCLUDED THE BSD 3-CLAUSE LICENSE BELOW, BUT THIS DOESN'T CONSTITUTE LEGAL ADVICE AND YOU SHOULD CHECK WITH YOUR CAMPUS'S TECH TRANSFER OFFICE TO SEE WHAT THE BEST OPTIONS ARE FOR YOUR PROJECT. You can also check out a list of [UC-approved licenses](https://security.ucop.edu/resources/open-source-software-licensing.html) provided by the UC Office of the President.
+
+[TODO: delete the lines above the "BSD 3-Clause License]
+
+BSD 3-Clause License
+
+Copyright (c) 2025, UC OSPO Network
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this
+   list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice,
+   this list of conditions and the following disclaimer in the documentation
+   and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its
+   contributors may be used to endorse or promote products derived from
+   this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.