From 3620c226115af6bd2bd527a505e732279019c9c1 Mon Sep 17 00:00:00 2001 From: Ivan Ogasawara Date: Tue, 7 Jul 2026 23:08:41 +0000 Subject: [PATCH] update: Update page about affiliation and incubation --- pages/projects/affiliation/index.md | 371 +++++++++++++++-- pages/projects/incubation/index.md | 604 +++++++++++++++++++++++----- pages/projects/index.md | 160 ++++++-- pages/projects/list/index.md | 8 + 4 files changed, 966 insertions(+), 177 deletions(-) diff --git a/pages/projects/affiliation/index.md b/pages/projects/affiliation/index.md index 8b9a917d..4ed50490 100644 --- a/pages/projects/affiliation/index.md +++ b/pages/projects/affiliation/index.md @@ -8,60 +8,353 @@ template: main.html # Open Science Labs Project Affiliation Program -Open Science Labs (OSL) is excited to introduce the Project Affiliation Program, -designed to support and promote projects that align with our mission of -fostering open science, open source, and technology. This program aims to create -a collaborative ecosystem where affiliated projects can thrive through various -support mechanisms. +The Open Science Labs (OSL) Project Affiliation Program is for independent +open-source projects that align with OSL's mission and want to be connected to +the OSL ecosystem. -## Program Benefits +Affiliation is a lightweight relationship. It gives aligned projects visibility, +community connection, and access to OSL opportunities, while project governance, +maintenance, technical decisions, releases, and roadmap ownership remain with +the project's own maintainers. -Affiliated projects will have access to a range of benefits, including: +> **Affiliation is a relationship, not a transfer of ownership.** -- **Participation in the OSL Internship Program:** Affiliated projects can - become part of our internship program, gaining access to enthusiastic interns - eager to contribute and learn. +## Purpose -- **Eligibility for OSL Grants:** Projects will be eligible to apply for future - funding opportunities through the **OSL Grants Program**, supporting further - development and growth. +The purpose of affiliation is to: -- **Promotion and Visibility:** OSL will actively promote affiliated projects - through our social media channels and at events organized by OSL, increasing - their visibility within the community. +- recognize projects aligned with open science, open source, education, + research, public-interest technology, or related infrastructure; +- help contributors discover healthy projects; +- allow projects to participate in OSL opportunities when appropriate; +- create pathways for collaboration between maintainers, contributors, mentors, + researchers, and partner organizations; +- promote projects that share OSL's values of openness, inclusion, learning, + mentorship, and responsible maintenance. -- **More Benefits to Come:** We are continuously working on adding more - advantages to this program and will announce new benefits as they become - available. +## Benefits + +Affiliated projects may receive: + +- **Project directory listing**: inclusion in the OSL public project list. +- **Visibility and promotion**: amplification through OSL channels, events, blog + posts, demos, or community updates when relevant. +- **Program eligibility**: ability to submit project ideas for OSL internships, + Google Summer of Code, grants, sponsorship opportunities, or similar programs + when available. +- **Community access**: connection with the OSL Discord community and related + contributor networks. +- **Collaboration opportunities**: introductions to mentors, reviewers, partner + communities, or funding opportunities when there is a good fit. +- **Contributor pathways**: a clearer route for newcomers to discover and + contribute to the project. + +Affiliation does not guarantee that a project will receive funding, interns, +contributors, grants, sponsorship, or long-term maintenance support from OSL. + +## Google Summer of Code and Limited Programs + +Affiliated projects may submit ideas for Google Summer of Code (GSoC), +internships, grants, or similar programs when OSL is participating and when the +project is ready to mentor contributors. + +Participation is not guaranteed. OSL will do its best to participate in GSoC and +similar opportunities when possible, but these programs depend on external +selection, OSL capacity, mentor availability, project readiness, and a limited +number of contributor slots. Even when OSL participates, not every affiliated +project idea can be selected or funded. + +Projects that want to participate in GSoC or internships should provide clear +project ideas, public issues, active mentors, communication channels, and enough +review capacity to support contributors responsibly. + +## Acknowledging OSL Affiliation + +Affiliated projects should acknowledge their relationship with OSL in their +`README.md` and, when applicable, in their public documentation. + +Suggested wording: + +> This project is affiliated with Open Science Labs (OSL). Affiliation means +> that the project aligns with OSL's mission and is connected to the OSL +> ecosystem, while governance, roadmap, maintenance, and releases remain the +> responsibility of the project maintainers. + +Projects should avoid language that suggests OSL owns, governs, certifies, or +guarantees the project unless there is a separate written agreement. ## Eligibility Criteria -To become an affiliated project, applicants should: +To become and remain affiliated with OSL, a project must: + +- be released under an **OSI-approved open-source license**; +- include a public `LICENSE` file; +- include a `CODE_OF_CONDUCT.md` or equivalent public Code of Conduct; +- provide a maintainer contact or public communication path; +- have at least one active or reachable maintainer; +- use public development practices, such as a public repository, issue tracker, + contribution guide, project board, or documented contact process; +- align with OSL's mission and values; +- maintain an open and inclusive project environment. + +Recommended, but not always required at the time of application: + +- `CONTRIBUTING.md`; +- public roadmap or project ideas; +- issue labels for newcomers; +- security reporting instructions; +- basic user and developer documentation; +- recent release notes or changelog. + +## Affiliation Fit Checklist + +Use this checklist before opening an affiliation request. A project does not +need to be large or mature, but it should be healthy enough for OSL to list it +publicly and direct community attention toward it. + +### Required for Affiliation + +- [ ] The project has a clear open-source, open-science, research, education, + public-interest, or open-technology purpose. +- [ ] The project uses an **OSI-approved open-source license**. +- [ ] The repository includes a public `LICENSE` file. +- [ ] The project includes a `CODE_OF_CONDUCT.md` or equivalent public Code of + Conduct with a reporting path. +- [ ] The project has at least one active or reachable maintainer. +- [ ] The project has a public repository. +- [ ] The project has a public issue tracker, discussion channel, project board, + or documented way to contact maintainers. +- [ ] The project is not archived, closed-source, abandoned, misleading, or + unsafe for contributors. +- [ ] The maintainers agree that affiliation does not transfer ownership, + governance, intellectual property, or maintenance responsibility to OSL. +- [ ] If accepted, the project will acknowledge its OSL affiliation in its + `README.md` and, when applicable, public documentation. + +### Recommended for Affiliation + +- [ ] The repository has a `README` explaining the project, users, and current + status. +- [ ] The project has contributor instructions or a `CONTRIBUTING.md`. +- [ ] The project has basic user or developer documentation. +- [ ] The project has a public roadmap, project ideas, or issue labels for + contributors. +- [ ] The project has a `SECURITY.md` or vulnerability reporting path when + relevant. +- [ ] The project has recent releases, commits, issue responses, or a documented + stable-maintenance status. +- [ ] The project can explain what kind of collaboration it is seeking through + OSL. + +## Maintenance Expectations + +Affiliated projects can be fast-moving, mature, or stable. OSL does not require +constant feature development. However, affiliated projects must remain +maintained enough that contributors, users, and OSL can understand the project +status. + +OSL uses the following maintenance levels: + +| Level | Meaning | +| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | +| **Active** | The project shows regular commits, reviews, releases, issue responses, roadmap progress, or contributor support. | +| **Maintained / Stable** | The project has lower activity because it is mature or stable, but maintainers remain reachable and respond to important issues. | +| **At Risk** | The project has missing required files, stale public activity, unanswered maintainer pings, broken links, or repeated failed health checks. | +| **Inactive** | The project appears abandoned, archived, unreachable, closed-source, unsafe for contributors, or no longer aligned with OSL requirements. | + +For affiliation, both **Active** and **Maintained / Stable** are acceptable +states. A stable project should make that status clear in its documentation so +contributors understand what to expect. + +## Automated Maintenance Checks + +OSL may use automated bots to help review affiliated projects. The goal is to +keep the public project directory accurate and to avoid sending contributors to +unmaintained repositories. + +For affiliated projects, bots may check quarterly: -- Be aligned with the mission and values of open science, open source, and - technology. -- Have a demonstrable track record of active development and community - engagement. -- Commit to maintaining an open and inclusive project environment. +- whether the repository is public and reachable; +- whether the repository has an OSI-approved `LICENSE`; +- whether the repository has a `CODE_OF_CONDUCT.md`; +- whether the project is archived; +- whether the listed website, documentation, and community links are reachable; +- whether there has been recent public activity or a documented stable status; +- whether maintainers are still listed and reachable; +- whether important issues or pull requests have gone unanswered for a long + period; +- whether project metadata in the OSL website remains accurate. + +Bots should support human review. A bot warning does not automatically mean a +project is abandoned. Maintainers may explain that the project is stable, +low-maintenance, between maintainers, or temporarily paused. + +## Review and Removal Workflow + +When an affiliated project appears to be unmaintained or out of compliance, OSL +may follow this workflow: + +| Time | Action | +| ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Day 0 | The bot detects a concern, such as missing license, missing Code of Conduct, broken project URL, archived repository, no public activity, or unreachable maintainers. | +| Day 1 | The bot opens a maintenance review issue or a pull request against the OSL website and pings the listed maintainers. | +| Day 30 | If there is no response or fix, the project may be marked **At Risk**. | +| Day 60 | If the issue remains unresolved, the bot may open or update a pull request removing the project from the OSL public list. Maintainers are pinged in the pull request. | +| Day 90 | If there is still no response, OSL may merge the removal pull request after human review. | + +Projects can avoid removal by: + +- restoring the required license or Code of Conduct; +- updating broken links; +- responding to the maintenance review; +- identifying a new maintainer; +- documenting that the project is stable and maintained with lower activity; +- publishing a realistic maintenance plan; +- asking OSL to pause the listing temporarily while maintainership is being + resolved. + +Removal from the OSL list is not permanent. A project may request affiliation +again after it restores the baseline requirements and maintenance status. + +## Limits and Responsibilities + +Affiliated projects remain independent. OSL does not: + +- own the project or its intellectual property; +- control the roadmap, releases, governance, or technical decisions; +- guarantee funding, contributors, interns, mentors, reviews, or adoption; +- guarantee participation in Google Summer of Code, internships, grants, or + sponsorship opportunities; +- guarantee a Google Summer of Code contributor slot, even when OSL + participates; +- provide legal, security, medical, or financial certification; +- endorse every technical choice or public statement made by the project. + +Maintainers are responsible for: + +- keeping the project open-source and properly licensed; +- maintaining the Code of Conduct and responding to community concerns; +- reviewing issues and pull requests when they invite contributions; +- keeping project links and OSL metadata accurate; +- keeping the OSL affiliation acknowledgement accurate in the project's + `README.md` and public documentation; +- communicating major changes in ownership, scope, license, governance, or + maintenance status; +- protecting contributors from unsafe or hostile community behavior. + +OSL may pause, remove, or decline affiliation if a project becomes inactive, +closed-source, unsafe, misleading, hostile, or misaligned with OSL values. ## How to Apply -Interested projects can apply for affiliation by submitting a detailed proposal -outlining their project's goals, current status, and how they align with OSL’s -mission. Proposals should be sent to `team@opensciencelabs.org`. +Interested projects should request affiliation through the OSL affiliation +requests repository: -## Review Process +[https://github.com/OpenScienceLabs/affiliation-requests](https://github.com/OpenScienceLabs/affiliation-requests) + +An affiliation request should include links to evidence, not only written +statements. Useful evidence includes: -All applications will undergo a thorough review by the OSL team to ensure -alignment with our values and goals. Successful applicants will be notified and -onboarded into the program. +- project name and repository URL; +- project website or documentation URL, if available; +- maintainer names and contact information; +- license link; +- Code of Conduct link; +- short project description; +- current maintenance status; +- public communication channel or contact path; +- contribution instructions, roadmap, project ideas, or starter issues when + available; +- security reporting path when relevant; +- why the project aligns with OSL; +- what kind of collaboration or visibility the project is seeking; +- whether the project wants to submit ideas for internships, Google Summer of + Code, grants, or other OSL opportunities. -## Conclusion +If GitHub is not accessible to an applicant, they may contact +`team@opensciencelabs.org` and ask for support opening the request. + +## Affiliation Request Workflow + +OSL uses a lightweight, transparent workflow for affiliation requests: + +1. **Request opened**: maintainers open an issue in the affiliation requests + repository with the requested information and evidence links. +2. **Completeness check**: OSL checks that required information is present, + including license, Code of Conduct, maintainer contact, repository link, and + project description. +3. **Eligibility review**: OSL reviews mission alignment, openness, maintenance + status, community safety, and whether the project is appropriate for OSL's + public project list. +4. **Maintainer follow-up**: OSL may ask questions, request missing links, or + suggest changes before approval. +5. **Decision**: the request is approved, declined, or marked as needing + changes. Declined or incomplete projects may apply again after addressing the + feedback. +6. **Listing update**: if approved, OSL opens or merges a website update adding + the project to the public project list. +7. **Onboarding**: OSL confirms the listed metadata, preferred communication + channel, maintainer contact, and whether the project wants to participate in + any eligible OSL opportunities. +8. **Periodic review**: the project remains subject to automated and human + maintenance checks while it is listed by OSL. + +Affiliation requests are not first-come, first-served. OSL may prioritize +requests based on completeness, mission fit, community safety, available review +capacity, and whether the project is seeking participation in time-sensitive +programs. + +## Review Criteria + +OSL reviews affiliation requests using these criteria: + +- **Mission fit**: the project contributes to open science, open source, + research, education, public-interest technology, or useful open + infrastructure. +- **Openness**: the project is publicly developed and uses an OSI-approved + license. +- **Community safety**: the project has a Code of Conduct and does not create a + hostile or unsafe environment for contributors. +- **Maintenance status**: maintainers are reachable and the project is active or + clearly documented as stable. +- **Contributor readiness**: contributors have a way to ask questions, open + issues, or understand how to participate. +- **Metadata quality**: the project provides enough accurate information for OSL + to list and periodically review it. +- **Program readiness**: if the project wants internships, Google Summer of + Code, grants, or similar opportunities, it has enough maintainer capacity and + project ideas to support contributors responsibly. + +## Boundaries of Affiliation + +Affiliation creates a public relationship between OSL and an independent +project. It does not make the project an OSL-governed or OSL-owned project. + +Affiliation does **not** mean: + +- OSL owns the repository, name, logo, code, data, intellectual property, or + governance of the project; +- OSL is responsible for maintaining the project; +- OSL certifies the technical, scientific, security, legal, medical, financial, + or ethical correctness of the project; +- OSL endorses every decision, release, public statement, dependency, or + integration made by the project; +- the project is guaranteed funding, contributors, interns, mentors, grants, + sponsorship, fiscal hosting, promotion, or event participation; +- the project may imply that OSL controls or guarantees its work; +- the project may use OSL branding in a way that suggests ownership, + certification, or formal sponsorship without written permission. + +Affiliated projects may describe themselves as an "OSL affiliated project" only +while they are listed by OSL and remain in good standing. If affiliation is +paused or removed, the project should stop presenting itself as currently +affiliated with OSL. + +## Review Process -The Project Affiliation Program is a testament to our commitment to nurturing -and promoting open science and technology projects. We look forward to welcoming -new projects into the OSL family and working together towards a future of open -and collaborative innovation. +OSL reviews affiliation requests for mission alignment, openness, maintenance +status, community safety, and readiness for contributors. If approved, the +project is added to the OSL project list and may participate in relevant OSL +programs according to each program's requirements and capacity. -For more information or inquiries, please contact us at -`team@opensciencelabs.org`. +For more information or inquiries, contact `team@opensciencelabs.org`. diff --git a/pages/projects/incubation/index.md b/pages/projects/incubation/index.md index 041157c8..e5a60f96 100644 --- a/pages/projects/incubation/index.md +++ b/pages/projects/incubation/index.md @@ -6,128 +6,514 @@ authors: ["OSL Team"] template: main.html --- -# Open Science Labs (OSL) Incubator Program - -Open Science Labs is committed to fostering the growth and development of -innovative scientific projects and/or software for support tasks like DevOps, -Automation, etc. Our Incubator Program is designed to provide structure and -support at various stages of development, helping projects grow from a mere idea -to a fully-fledged, sustainable project. The program is divided into three -distinct phases: +# Open Science Labs Incubator Program + +The Open Science Labs (OSL) Incubator Program is a structured pathway for +open-source projects that need active support to become sustainable. It is for +projects that are early-stage, restarting, transitioning into open source, or +ready to improve their maintenance, documentation, governance, contributor +onboarding, and release practices. + +Incubation is deeper than affiliation. Affiliation connects an independent +project with the OSL ecosystem. Incubation creates a shared growth plan between +project maintainers and OSL. + +> **Incubation is a growth pathway from idea to sustainable project.** + +## What Incubation Is For + +The Incubator Program helps projects: + +- turn promising ideas into usable open-source projects; +- define a public roadmap, milestones, and contribution path; +- improve documentation, testing, packaging, releases, and maintainability; +- onboard contributors through clear issues, mentoring, and review practices; +- prepare ideas for internships, Google Summer of Code, grants, sponsorships, or + other opportunities when available; +- build a maintainer model that can continue beyond the original author; +- graduate into an independent and sustainable project. + +Incubated projects may be scientific software, research infrastructure, +educational tools, public-interest technology, or support tools for open-source +work such as automation, DevOps, documentation, data workflows, and community +infrastructure. + +## What OSL May Provide + +Depending on project needs and OSL capacity, incubated projects may receive: + +- project-structure and roadmap guidance; +- mentorship for maintainers and contributors; +- support defining newcomer-friendly issues and internship ideas; +- visibility through OSL channels, events, blog posts, demos, or community + updates; +- guidance on documentation, packaging, testing, releases, governance, and + contributor workflows; +- help identifying grants, sponsors, fiscal-hosting paths, reviewers, or partner + organizations; +- periodic maintenance and health checks. + +Incubation does not guarantee funding, contributors, interns, mentors, external +program acceptance, publication, adoption, or long-term OSL maintenance. + +## Google Summer of Code and Limited Programs + +Incubated projects may prepare ideas for Google Summer of Code (GSoC), +internships, grants, or similar programs when OSL is participating and when the +project has enough mentor capacity. + +Participation is not guaranteed. OSL will do its best to participate in GSoC and +similar opportunities when possible, but these programs depend on external +selection, OSL capacity, mentor availability, project readiness, and a limited +number of contributor slots. Even when OSL participates, not every incubated +project idea can be selected or funded. + +Projects that want to participate in GSoC or internships should provide clear +project ideas, scoped tasks, public issues, active mentors, communication +channels, and enough review capacity to support contributors responsibly. + +## Acknowledging OSL Incubation + +Incubated projects should acknowledge their relationship with OSL in their +`README.md` and, when applicable, in their public documentation. + +Suggested wording: + +> This project is incubated by Open Science Labs (OSL). Incubation means that +> OSL supports the project through mentorship, structure, community connection, +> and sustainability guidance, while day-to-day maintenance, roadmap decisions, +> and releases remain the responsibility of the project maintainers. + +Projects should update this acknowledgement if their status changes, such as +moving from PoC to incubation, graduating, leaving the OSL organization, or +being removed from OSL public listings. + +## Incubation Fit Checklist + +Use this checklist before applying. A project does not need to be perfect, but +it should be ready for public collaboration and active maintainer engagement. + +### Required for Incubation + +- [ ] The project has a clear purpose and public-interest, open-science, + research, education, or open-technology alignment. +- [ ] The project uses an **OSI-approved open-source license**. +- [ ] The repository includes a public `LICENSE` file. +- [ ] The project includes a `CODE_OF_CONDUCT.md` or equivalent public Code of + Conduct with a reporting path. +- [ ] The project has at least one active and reachable maintainer. +- [ ] The project has a public repository or a public proposal repository. +- [ ] The project has a public issue tracker, project board, or documented way + to discuss work. +- [ ] The project has at least one public communication channel or documented + contact path for users and contributors. +- [ ] The maintainer is willing to communicate with OSL mentors or reviewers + during incubation. +- [ ] The project can be maintained in public and can welcome contributors in a + respectful environment. +- [ ] If accepted, the project will acknowledge its OSL incubation status in its + `README.md` and, when applicable, public documentation. + +### Strongly Recommended Before Acceptance + +- [ ] The repository has a `README` explaining the project, users, and current + status. +- [ ] The project has a `CONTRIBUTING.md` or contributor instructions. +- [ ] The project has an initial roadmap or milestones for the next 3 to 6 + months. +- [ ] There are starter issues or planned tasks for contributors. +- [ ] The project has basic user or developer documentation. +- [ ] The project has tests, validation examples, or a plan to add them. +- [ ] The project has an architecture, design, or technical overview when + relevant. +- [ ] The project has a release, versioning, or publication plan when relevant. +- [ ] The project has a `SECURITY.md` or vulnerability reporting path when + relevant. +- [ ] The project has a documented maintainer list, roles, or decision-making + process. +- [ ] The project has early user, adopter, contributor, citation, deployment, or + pilot evidence when available. +- [ ] The maintainers can explain what kind of help they need from OSL. + +### Scientific Software Review Expectations + +For scientific software, OSL may require an external or community review path as +part of graduation: + +- [ ] Scientific Python projects that are in pyOpenSci scope should follow + pyOpenSci guidelines during incubation and must be accepted by pyOpenSci + before graduating. +- [ ] Scientific R projects that are in rOpenSci scope should follow rOpenSci + guidelines during incubation and must be accepted by rOpenSci before + graduating. +- [ ] Scientific projects outside pyOpenSci or rOpenSci scope should define an + equivalent review path with OSL during incubation. + +## How to Apply + +Applications for incubation should be submitted through the OSL Incubator +project applications repository: + +[https://github.com/osl-incubator/project-applications](https://github.com/osl-incubator/project-applications) + +An application should include links to evidence, not only written statements. +Useful evidence includes: + +- project name and short description; +- repository, documentation, or proposal link; +- maintainer names and contact information; +- license and Code of Conduct links; +- current project stage and maintenance status; +- problem statement and intended users; +- roadmap or milestones for the next 3 to 6 months; +- contributor and mentoring needs; +- expected OSL support; +- links to contribution instructions, starter issues, release notes, security + policy, governance, or architecture documentation when available; +- evidence of users, adopters, citations, deployments, pilots, or community + interest when available; +- whether the project is scientific Python, scientific R, or another scientific + software project that may need external review before graduation. + +OSL reviews applications for mission alignment, openness, maintainer readiness, +community safety, feasibility, and available mentor capacity. + +## How OSL Reviews Projects + +OSL uses a lightweight due-diligence process inspired by mature open-source +foundation practices. The review should be transparent, evidence-based, and +proportional to the project's stage. + +For incubation applications and stage changes, OSL may review: + +- **Application completeness**: required links and project information are + present. +- **Maintainer readiness**: maintainers are reachable and have enough capacity + to support contributors. +- **Governance and continuity**: roles, decision-making, ownership, and + maintainer succession are clear enough for the project stage. +- **Contributor readiness**: issues, contribution instructions, communication + channels, and review expectations are discoverable. +- **Technical readiness**: the problem, design, roadmap, release process, and + quality practices are appropriate for the project stage. +- **Security and safety**: the project has a way to report sensitive issues and + maintainers can respond to community or safety concerns. +- **Adoption or usefulness evidence**: the project can show intended users, + early users, pilots, citations, deployments, or community interest when + appropriate. +- **Scientific review path**: scientific projects have a pyOpenSci, rOpenSci, or + equivalent review plan when relevant. + +Detailed issue templates, labels, bot configuration, and operational review +checklists should live in the +[project applications repository](https://github.com/osl-incubator/project-applications), +not on this overview page. + +## Incubation Lifecycle + +The Incubator Program has three main stages and one non-active lifecycle +outcome. + +| Stage | Purpose | Main question | +| -------------------------- | -------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | +| **Proof of Concept (PoC)** | Explore whether the idea is feasible, useful, and aligned with OSL. | Should this become a real open-source project? | +| **Incubation** | Build the project with structure, mentorship, contributors, and public development practices. | Can this project become sustainable? | +| **Graduated** | Recognize that the project can operate with less direct OSL support. | Is this project ready to stand on its own? | +| **Inactive / Archived** | Mark a project that is no longer maintained, no longer recommended, or no longer supported by OSL. | Should OSL stop listing or supporting this project until it is revived? | ### 1. Proof of Concept (PoC) -**Description:** The PoC phase is the first step, aimed at experimenting with -new ideas and technologies to determine their feasibility and potential. -Projects in this phase can be found at -[OSL PoC GitHub Repository](https://github.com/osl-pocs). +The PoC stage is for ideas, prototypes, or early repositories that need +validation before becoming full incubated projects. -**Criteria:** +PoC projects should have: -- Preliminary design and concept. -- A clear vision of the problem the project aims to solve. -- Must be licensed under a license approved by Open Source Initiative (OSI). +- a clear problem statement; +- an early design, prototype, or proposal; +- an OSI-approved license; +- a Code of Conduct; +- at least one named maintainer or project author; +- a public repository or proposal space; +- initial issues, questions, or planned tasks; +- a lightweight roadmap for the next 1 to 3 months. -**Application Process:** +PoC projects are expected to show active exploration. They do not need mature +releases, but maintainers must be responsive. -- Submit a proposal through - [OSL PoC GitHub Issues](https://github.com/osl-pocs/tickets/issues), including - the concept, objectives, and a high-level design. -- Undergo a review process by the OSL selection committee. +A PoC project may move into Incubation when it demonstrates feasibility, +alignment with OSL, maintainer commitment, and a realistic development plan. ### 2. Incubation -**Description:** This phase focuses on nurturing the project, providing -resources, mentorship, and facilitating access to grants and partners. Projects -in this stage can be found at -[OSL Incubator GitHub Repository](https://github.com/osl-incubator). - -**Criteria:** - -- Successful completion of the PoC phase. -- Clearly defined milestones and development plan. -- Strong community engagement and collaboration. -- Adherence to OSL’s guidelines, including licensing under an OSI-approved - license. +The Incubation stage is for projects that are ready for structured development +and contributor support. -**Ascending Process:** +Incubating projects should have: -- Complete the PoC phase with positive evaluations. -- Obtain approval from OSL mentors and stakeholders. +- active maintainer participation; +- public roadmap and milestones; +- contribution instructions; +- public issues or project tasks; +- regular communication with OSL mentors or reviewers; +- progress toward documentation, tests, packaging, releases, governance, and + sustainability; +- enough mentor capacity before accepting interns or major contributor programs. -**Support for Raising Funds:** - -- OSL will assist in identifying suitable grants and partner organizations. -- Facilitate collaborations to support the project's financial needs. +Incubating projects are normally expected to be **Active**. If maintainers need +to pause, they should communicate the pause and publish a maintenance plan. ### 3. Graduated -**Description:** The Graduated phase is the final step, indicating that the -project has matured and is ready for widespread adoption and sustainable growth. -Graduated projects are available at -[OSL Graduated GitHub Repository](https://github.com/osl-projects). - -**Criteria:** - -- Successful completion of the Incubation phase. -- Demonstrated stability, sustainability, and active community engagement. -- Ongoing adherence to OSL guidelines, including OSI-approved licensing. - -**Ascending Process:** - -- Successfully meet all the milestones during the Incubation phase. -- Submit a graduation application at - [OSL Graduated GitHub Issues](https://github.com/osl-projects/tickets/issues), - detailing achievements and future plans. -- Undergo a final review and approval by OSL’s governing board. - -#### Peer review of scientific Python Projects via pyOpenSci - -For all scientific Python projects under the Open Science Labs Incubator -program, the evaluation process will be conducted via -[pyOpenSci](https://www.pyopensci.org/), a community-led organization that -offers peer reviews of Python software to enhance its quality, usability, and -long-term maintainability. These peer reviews are pivotal in advancing the -open-source tools that underpin open science initiatives. - -#### Benefits of Using pyOpenSci for Evaluation - -1. **High-Quality Review**: pyOpenSci's review process focuses on ensuring that - your Python package meets high standards in terms of code quality, - documentation, and usability. - -2. **JOSS Acceptance**: The Journal of Open Source Software (JOSS) accepts a - pyOpenSci review as their own. As such your project, if it is in scope for - JOSS, can reap the benefits of both pyOpenSci and JOSS through a single peer - review process. - -3. **Community-Led**: Gain insights and recommendations from experts in the open - science and Python communities. - -##### Guidelines and Review Process - -- **Project Guidelines**: All projects should follow pyOpenSci's packaging - guidelines which can be accessed - [here](https://www.pyopensci.org/python-package-guide/). - -- **Peer Review Process**: The detailed guide for pyOpenSci's peer review - process can be found - [here](https://www.pyopensci.org/about-peer-review/index.html). We highly - recommend going through this guide to understand what to expect during the - review. - -The pyOpenSci review process offers a valuable opportunity to enhance the -quality, usability, and maintainability of your software. Additionally, your -tool will gain increased visibility and community support once it is accepted -into the pyOpenSci ecosystem. - -## Conclusion - -The OSL Incubator Program is a robust pathway for innovative scientific projects -and projects for support tasks to grow and succeed. We invite all creators, -researchers, and enthusiasts to explore our program and become part of this -thriving ecosystem. Detailed information on applying for each phase, as well as -guidelines, can be found on our official website. - -For any further inquiries, please contact our dedicated Incubator Program team -at OSL. Together, we can shape the future of open science. +Graduation means that the project has reached a sustainable state and no longer +needs active incubation support. + +Graduated projects may stay under an OSL-controlled GitHub organization or move +outside OSL to an independent organization, maintainer-owned organization, lab, +foundation, company, or community home. + +A graduated project may still be listed by OSL, but its maintainers remain +responsible for governance, maintenance, releases, licensing, Code of Conduct, +and community safety. + +## Graduation Criteria + +A project may request graduation when it has met its incubation milestones and +can show that it is responsibly maintained. + +General graduation expectations: + +- successful completion of incubation milestones; +- active or stable maintenance; +- clear maintainer team or governance model; +- a maintainer team appropriate to the size and risk of the project; +- at least two maintainers preferred, or a documented continuity plan when the + project has only one maintainer; +- public documentation and contribution process; +- documented decision-making, ownership, and maintainer onboarding/offboarding + practices appropriate to the project stage; +- release, deployment, publication, citation, user, or adoption evidence + appropriate to the project scope; +- documented release or versioning process when relevant; +- security or vulnerability reporting process when relevant; +- ongoing OSI-approved licensing; +- ongoing Code of Conduct; +- sustainable communication and issue-review practices; +- clear plan for where the repository will live after graduation. + +Additional scientific software expectations: + +- scientific Python projects in pyOpenSci scope must be accepted through the + pyOpenSci review process before graduation; +- scientific R projects in rOpenSci scope must be accepted through the rOpenSci + review process before graduation; +- scientific projects outside those scopes must complete an equivalent review + path agreed with OSL during incubation. + +A graduation request should include links to evidence for: + +- completed milestones; +- current maintainer list and maintainer roles; +- current maintenance status; +- governance or decision-making process; +- future roadmap or maintenance plan; +- documentation, contribution instructions, and release process; +- security or vulnerability reporting process when relevant; +- user, adoption, deployment, citation, or publication evidence when available; +- desired repository location after graduation; +- pyOpenSci acceptance link for in-scope scientific Python projects; +- rOpenSci acceptance link for in-scope scientific R projects; +- explanation of the equivalent review path for scientific projects outside + pyOpenSci or rOpenSci scope. + +## Graduation Review Workflow + +Graduation should be public and evidence-based. OSL may use the following +high-level workflow: + +1. **Graduation request**: maintainers open a request in the project + applications repository with links to evidence. +2. **Completeness check**: OSL checks that required information is present and + asks for missing evidence if needed. +3. **Readiness review**: OSL reviewers evaluate maintenance, governance, + contributor readiness, documentation, security, adoption or usefulness, and + any scientific review requirement. +4. **Public comment period**: OSL may leave the request open for community + feedback, usually for about two weeks. +5. **Decision and transition**: OSL approves graduation, asks for additional + work, pauses the request, or declines it with documented reasons. +6. **Website and repository update**: OSL updates project listings, repository + location, status, and maintenance metadata. + +OSL maintainers, mentors, or governance representatives review graduation +requests before approving the transition. + +## Scientific Python Projects and pyOpenSci + +Scientific Python projects under the OSL Incubator Program should follow +[pyOpenSci](https://www.pyopensci.org/) guidelines during incubation. pyOpenSci +provides community-led guidance and review criteria for Python packages used in +scientific and open-science contexts. + +Maintainers should use these resources while preparing the project: + +- [pyOpenSci Python Package Guide](https://www.pyopensci.org/python-package-guide/) +- [pyOpenSci Peer Review Process](https://www.pyopensci.org/about-peer-review/index.html) +- [pyOpenSci Packaging Guide](https://www.pyopensci.org/python-package-guide/package-structure-code/python-package-structure.html) +- [pyOpenSci Documentation Guide](https://www.pyopensci.org/python-package-guide/documentation/index.html) +- [pyOpenSci Testing Guide](https://www.pyopensci.org/python-package-guide/tests/index.html) + +For scientific Python projects that are in pyOpenSci scope, graduation from the +OSL Incubator Program depends on acceptance through the pyOpenSci review +process. Maintainers should prepare the package, submit it for review, respond +to reviewer feedback, and provide the acceptance link as part of the OSL +graduation request. + +## Scientific R Projects and rOpenSci + +Scientific R projects under the OSL Incubator Program should follow +[rOpenSci](https://ropensci.org/) guidelines during incubation. rOpenSci +provides community-led guidance and peer review for scientific R packages, +including packages related to scientific data lifecycles and statistical +software. + +Maintainers should use these resources while preparing the project: + +- [rOpenSci Software Peer Review](https://ropensci.org/software-review/) +- [rOpenSci Packages: Development, Maintenance, and Peer Review](https://devguide.ropensci.org/) +- [rOpenSci Packaging Guide](https://devguide.ropensci.org/pkg_building.html) +- [rOpenSci Software Peer Review Policies](https://devguide.ropensci.org/softwarereview_policies.html) +- [rOpenSci Guide for Authors](https://devguide.ropensci.org/softwarereview_author.html) +- [rOpenSci Statistical Software Peer Review](https://stats-devguide.ropensci.org/) +- [rOpenSci Package Maintenance Cheatsheet](https://devguide.ropensci.org/maintenance_cheatsheet.html) + +For scientific R projects that are in rOpenSci scope, graduation from the OSL +Incubator Program depends on acceptance through the rOpenSci review process. +Maintainers should prepare the package, submit it for review, respond to +reviewer and editor feedback, and provide the acceptance link as part of the OSL +graduation request. + +## Equivalent Review for Out-of-Scope Scientific Projects + +Some scientific projects may not fit pyOpenSci or rOpenSci scope. In those +cases, OSL may define an equivalent graduation criterion during incubation, such +as review by another appropriate community, publication venue, domain experts, +standards group, or an OSL-appointed review group. + +The equivalent review path should be documented before graduation so maintainers +know what evidence is required. + +## Maintenance Levels + +Incubation requires active stewardship because OSL may direct contributors, +interns, mentors, and public attention to the project. + +| Level | Meaning | Incubation interpretation | +| ----------------------- | ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | +| **Active** | Regular commits, reviews, releases, issue responses, roadmap progress, or contributor support. | Expected for PoC and Incubation. | +| **Maintained / Stable** | Lower activity, but maintainers are reachable and respond to important issues. | Acceptable for Graduated projects and temporarily acceptable for Incubation with a documented maintenance plan. | +| **At Risk** | Missing required files, stale milestones, unanswered pings, broken links, or repeated failed health checks. | Requires maintainer response and OSL review. | +| **Inactive** | Appears abandoned, unreachable, closed-source, unsafe, or misaligned. | May lead to paused incubation, removal from public lists, or archival review. | +| **Archived** | No longer supported or recommended by OSL as an active incubated or graduated project. | May be restored only after maintainers resolve requirements and request reactivation. | + +## Automated Incubation Checks + +OSL may use bots to monitor project health, keep public listings accurate, and +flag problems early. Bots support human review; they do not replace maintainer +judgment. + +Bots may check: + +- whether the repository is public and reachable; +- whether the project has an OSI-approved `LICENSE`; +- whether the project has a `CODE_OF_CONDUCT.md`; +- whether the repository has been archived; +- whether maintainer information is available; +- whether project website and documentation links are reachable; +- recent commits, releases, merged pull requests, and issue activity; +- stale pull requests or unanswered issues; +- progress against milestones or roadmap items; +- whether contributor-friendly issues exist when the project is seeking + contributors; +- whether OSL website metadata matches the actual project status. + +Suggested check frequency: + +| Stage | Suggested frequency | +| ---------- | ---------------------------: | +| PoC | Monthly | +| Incubation | Monthly | +| Graduated | Quarterly | +| At Risk | Every 2 weeks until resolved | + +## At-Risk, Pause, Removal, and Archive Workflow + +When a project appears inactive or out of compliance, OSL may use the following +workflow: + +| Time | Action | +| ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Day 0 | Bot detects a concern, such as missing license, missing Code of Conduct, no maintainer response, broken links, stale milestones, archived repository, or long inactivity. | +| Day 1 | Bot opens a maintenance review issue or website pull request and pings maintainers and, when applicable, OSL mentors. | +| Day 30 | If unresolved, the project may be marked **At Risk** and incubation activity may be paused. | +| Day 60 | If still unresolved, OSL may stop sending contributors to the project and open a pull request to remove or hide the project from public OSL lists. | +| Day 90 | For repositories hosted under an OSL-controlled organization, OSL may consider archival after human review. External repositories are not archived by OSL, but may be removed from OSL lists. | + +Maintainers can resolve an at-risk status by: + +- responding to the maintenance review; +- restoring missing license or Code of Conduct files; +- updating broken links and project metadata; +- closing, triaging, or responding to stale community requests; +- documenting a stable-maintenance status; +- transferring or adding maintainers; +- publishing a new roadmap or maintenance plan; +- asking OSL to pause incubation while maintainership is reorganized. + +## Graduated Projects Outside OSL + +After graduation, a project may move outside an OSL GitHub organization. This is +acceptable and often healthy: graduation means the project can operate with less +direct OSL support. + +When a graduated project moves outside OSL: + +- the project may still be listed as a graduated OSL project; +- the external maintainers remain responsible for maintenance, governance, + licensing, releases, Code of Conduct, and community safety; +- OSL bots may continue checking public signals such as repository reachability, + license, Code of Conduct, archived status, and maintenance activity; +- if the external project becomes inactive or no longer meets the baseline + requirements, the bot may open a pull request to remove it from OSL lists and + ping maintainers in that pull request; +- OSL does not archive repositories outside OSL-controlled organizations. + +A removed graduated project can be restored to the OSL list if maintainers +respond, restore the baseline requirements, and show that the project is active +or responsibly maintained as stable. + +## Responsibilities and Limits + +Project maintainers are responsible for: + +- maintaining the repository and community spaces; +- reviewing contributor work; +- communicating project status; +- upholding the Code of Conduct; +- keeping license and governance information accurate; +- keeping the OSL incubation acknowledgement accurate in the project's + `README.md` and public documentation; +- telling OSL when the project needs to pause, transfer maintainership, or + change direction. + +OSL may pause or end incubation if a project loses maintainers, repeatedly fails +baseline requirements, becomes unsafe for contributors, moves closed-source, or +no longer aligns with OSL's mission. + +OSL does not guarantee: + +- funding, grants, sponsorship, or paid contributors; +- acceptance into Google Summer of Code or any external program; +- a Google Summer of Code contributor slot, even when OSL participates; +- publication, adoption, external review acceptance, or long-term success; +- indefinite OSL maintenance; +- that every incubated project will graduate. diff --git a/pages/projects/index.md b/pages/projects/index.md index 93e338a6..ce6359fe 100644 --- a/pages/projects/index.md +++ b/pages/projects/index.md @@ -4,41 +4,143 @@ title: Programs # Open Science Labs Projects -Open Science Labs (OSL) champions the intersection of open science and -open-source technology, fostering a vibrant community where researchers, -developers, and enthusiasts can collaborate and innovate. OSL supports this -mission through robust programs designed to facilitate growth and development. +Open Science Labs (OSL) supports open-source projects through two complementary +paths: -## Incubator and Affiliated Projects +- **Project Affiliation**: a relationship for independent projects that align + with OSL's mission and want visibility, community connection, and access to + OSL programs. +- **Project Incubation**: a structured growth pathway for early-stage or + transitioning projects that need active support, mentorship, contributors, and + a sustainability plan. -### Incubator Program +In short: -The **Incubator Program** at OSL supports emerging open-source libraries and -tools to support scientific and general projects, providing them with necessary -resources, mentorship, and a collaborative community. Projects in this program -benefit from guidance on best practices in open-source development and -scientific research, helping to enhance their visibility and impact. +> **Affiliation is a relationship. Incubation is a growth pathway.** -### Affiliation Benefits +Both paths help projects grow in public, welcome contributors, and create +practical impact for open science, research, education, and public-interest +technology. -Projects that become affiliated with OSL enjoy several advantages. They gain -eligibility to participate in special programs such as the OSL Internship -Program, the Google Summer of Code, and potentially receive OSL Development -Grants aimed at accelerating their growth and expanding their reach within the -global community. +## Affiliation vs Incubation -## Internship Program +| Program | Purpose | Best for | OSL role | +| --------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | +| **Affiliation** | Connect aligned external projects with the OSL ecosystem. | Existing projects with maintainers, direction, and public activity. | Community ally, amplifier, connector, and program gateway. | +| **Incubation** | Help projects move from idea or early stage toward sustainable open-source practice. | Projects that need structure, mentorship, contributor onboarding, governance, and growth support. | Active mentor, guide, and development partner. | -The **Internship Program** offers hands-on experience to aspiring professionals -by pairing them with both incubated and affiliated projects under the OSL -umbrella. Modeled after successful initiatives like Google Summer of Code, this -program allows interns to work on substantive projects, sharpening their skills -and contributing to significant advancements in open science. +Affiliated projects normally remain governed and maintained by their own +communities. Incubated projects receive more active OSL support and are expected +to follow milestones, communicate regularly, and progress toward a stable or +graduated state. -## Bridging Theory and Practice +## Shared Requirements -Through these initiatives, OSL is dedicated to transforming theoretical -knowledge into practical application, fostering a dynamic environment where -continuous learning and active contribution drive scientific progress. Whether -you are developing an innovative project or seeking to engage with the -open-source community, OSL provides the resources and platform to thrive. +All affiliated and incubated projects must meet the following baseline +requirements: + +- **OSI-approved license**: the project must include a clear `LICENSE` file + using an Open Source Initiative approved license. +- **Code of Conduct**: the project must include a `CODE_OF_CONDUCT.md` or an + equivalent public Code of Conduct with a reporting path. +- **Active maintenance**: the project must identify at least one reachable + maintainer and show ongoing maintenance or a clearly documented stable status. +- **Public development**: the repository, issue tracker, contribution process, + or contact path must be publicly visible. +- **Community alignment**: the project must align with OSL values around open + science, open source, education, research, public-interest technology, + inclusion, and respectful collaboration. + +These requirements are not only entry criteria. They are ongoing expectations. +Projects that become closed-source, lose maintainers, remove their Code of +Conduct, become unsafe for contributors, or stop being maintained may be marked +at risk or removed from OSL public listings. + +## Maintenance Levels + +OSL treats maintenance as a spectrum. A project does not need constant feature +development to remain in good standing, but it does need responsible +stewardship. + +| Level | Meaning | Typical fit | +| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | +| **Active** | The project shows regular commits, reviews, releases, issue responses, roadmap progress, or contributor support. | PoC, incubating, and fast-moving affiliated projects. | +| **Maintained / Stable** | The project has lower activity because it is mature or stable, but maintainers remain reachable and respond to important issues. | Affiliated and graduated projects. | +| **At Risk** | Required files are missing, maintainers are not responding, public activity has stalled, or health checks fail repeatedly. | Temporary warning state before removal, pause, or archival. | +| **Inactive** | The project appears abandoned, archived, unreachable, or no longer aligned with OSL requirements. | Removed from public OSL lists; archived when hosted under an OSL-controlled organization and approved by maintainers or OSL governance. | + +The goal of these levels is not to punish maintainers. The goal is to keep OSL +lists trustworthy, direct contributors toward projects that can support them, +and make it clear when a project needs help. + +## Automated Project-Health Checks + +OSL may use automated bots to help maintain public project lists and identify +projects that need attention. Bots should support human review; they should not +replace maintainer judgment. + +Bots may check: + +- whether the repository is public and reachable; +- whether the repository has an OSI-approved `LICENSE`; +- whether the repository has a `CODE_OF_CONDUCT.md`; +- whether the project is archived; +- whether listed project URLs still resolve; +- whether maintainers are listed and reachable; +- recent commits, releases, merged pull requests, and issue activity; +- long-running unanswered issues or pull requests; +- missing contribution or security information, when applicable; +- whether the project remains aligned with the status shown on the OSL website. + +Suggested review frequency: + +| Project status | Suggested bot check frequency | +| -------------- | ----------------------------: | +| PoC | Monthly | +| Incubating | Monthly | +| Affiliated | Quarterly | +| Graduated | Quarterly | +| At Risk | Every 2 weeks until resolved | + +Suggested review workflow: + +| Time | Action | +| ------ | ----------------------------------------------------------------------------------------------------------------------------------- | +| Day 0 | Bot detects missing requirements, inactivity, broken links, archived repository, or another health concern. | +| Day 1 | Bot opens a maintenance review issue or website pull request and pings the listed maintainers. | +| Day 30 | If there is no response or fix, the project may be marked **At Risk**. | +| Day 60 | If still unresolved, the bot may open or update a pull request removing the project from the public OSL list or pausing incubation. | +| Day 90 | For inactive repositories hosted under an OSL-controlled organization, OSL may consider archival after human review. | + +Maintainers can resolve a warning by responding, restoring required files, +documenting a stable-maintenance status, transferring maintainership, updating +project metadata, or publishing a realistic maintenance plan. + +## Which Path Should I Choose? + +Choose **Project Affiliation** if: + +- your project already exists and has maintainers; +- you want visibility through OSL and access to programs such as internships or + Google Summer of Code when available; +- you want to remain independent while collaborating with the OSL community. + +Choose **Project Incubation** if: + +- your project is early-stage, restarting, or transitioning into open source; +- you need help with structure, milestones, documentation, onboarding, + governance, or releases; +- you are ready to work actively with OSL mentors and contributors. + +## Internship and Contributor Programs + +OSL internships and contributor programs may include both affiliated and +incubated projects. Participation is not automatic: projects must provide +maintainers, project ideas, public issues, a contribution path, and enough +mentor availability to support contributors responsibly. + +## Explore the Programs + +- [Project Affiliation](/projects/affiliation/) +- [Project Incubation](/projects/incubation/) +- [Affiliated and Incubated Projects](/projects/list/) diff --git a/pages/projects/list/index.md b/pages/projects/list/index.md index 6a36e93d..63ca19b4 100644 --- a/pages/projects/list/index.md +++ b/pages/projects/list/index.md @@ -213,3 +213,11 @@ driving forward our shared goals. These collaborations not only strengthen our community but also contribute significantly to the broader field of open source and scientific research. Below, you'll find information about affiliated and incubated projects. + +Projects listed here are expected to remain open source, follow an OSI-approved +license, include a Code of Conduct, and have reachable maintainers. OSL may +periodically review project health using automated checks and human follow-up. +Projects that become inactive, archived, unreachable, closed-source, or no +longer aligned with OSL requirements may be marked at risk or removed from this +list. If a project is removed because of inactivity, maintainers may ask to +restore it after the baseline requirements and maintenance status are resolved.