{"id":20358180,"url":"https://github.com/irods/irods_rfcs","last_synced_at":"2026-03-19T15:28:12.008Z","repository":{"id":56659788,"uuid":"114126566","full_name":"irods/irods_rfcs","owner":"irods","description":"iRODS RFCs","archived":false,"fork":false,"pushed_at":"2021-12-31T01:50:46.000Z","size":94,"stargazers_count":2,"open_issues_count":0,"forks_count":2,"subscribers_count":5,"default_branch":"main","last_synced_at":"2025-06-09T19:49:17.848Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/irods.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2017-12-13T13:50:24.000Z","updated_at":"2023-01-12T08:44:30.000Z","dependencies_parsed_at":"2022-08-15T22:50:17.096Z","dependency_job_id":null,"html_url":"https://github.com/irods/irods_rfcs","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/irods/irods_rfcs","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/irods%2Firods_rfcs","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/irods%2Firods_rfcs/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/irods%2Firods_rfcs/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/irods%2Firods_rfcs/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/irods","download_url":"https://codeload.github.com/irods/irods_rfcs/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/irods%2Firods_rfcs/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28929701,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-31T04:05:25.756Z","status":"ssl_error","status_checked_at":"2026-01-31T04:02:35.005Z","response_time":128,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-14T23:25:42.964Z","updated_at":"2026-01-31T04:32:55.054Z","avatar_url":"https://github.com/irods.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# iRODS RFCs\n\n# About this repository\n\nThis repository contains RFCs (requests for comments, or design documents) that describe\nproposed major changes to iRODS or new feature development spanning\nmultiple repositories / plugins.\n\n# Why and when to send a RFC?\n\nBefore making major changes, consider sending an RFC for discussion.\nThis is a lightweight design-document process modified from the\n[cockroachdb project](https://github.com/cockroachdb/cockroach/tree/master/docs/RFCS).\n\nWhat is a major change?\n\nA change is \"major\" and requires a RFC when any of the following\nconditions apply:\n\n- completing the change will cost you more than two weeks of work.\n- users will need to change the way they use iRODS as a result.\n- other iRODS contributors will need to change the way\n  they work as a result.\n- the architecture of the software or the project changes in a way visible\n  to more than a handful of developers.\n\n# RFC process\n\n1. Copy `0000_template.md` to a new file, rename it (increment from largest current RFC),\n   and fill in the details. Commit this version in your own fork of the\n   repository or a branch.\n\n2. Submit a pull request (PR) to add your new file to the main repository.\n   Each RFC should get its own pull request.\n\n   Ideally, an RFC sent out for review for the first time will ask a\n   number of questions, soliciting answers/advice from experts.\n\n   **Before you consider the RFC ready to be reviewed, give extra\n   attention to the section \"Rationale and Alternatives\". It's\n   important for the reviewers to understand why the solution chosen\n   was right. It is an unfortunate fact that often a solution is\n   determined first and the RFC is then written to support that\n   solution, without much consideration being given to the\n   alternatives. You should be mindful of this when it happens and\n   attempt to compensate by a serious review of alternatives.**\n\n3. Go through the PR review, iterating on the RFC to answer questions\n   and concerns from the reviewer(s). This process can last a while,\n   depending on the complexity of the proposal. The PR must\n   remain open for at least one week, to allow collaborators sufficient\n   time to review the RFC.\n\n   If it becomes apparent that the proposal is acceptable during\n   review within a few days, you need not go through the RFC process.\n   Update the relevant issue with the proposal, and get the reviewer\n   to sign off on the proposal in the issue. Both the reviewer\n   and you should feel confident that the implementation is going to take\n   less than two weeks, or else defer back to the RFC process. Start\n   implementing and accept that someone might disagree later on during the\n   review of the implementation. Disagreement on such a code review can\n   often get channelled back into an RFC; that is perfectly fine!\n\n4. At some point, the author(s) and/or shepherd will seek to\n   decide that the \"dust has settled\".\n\n   The author(s) and/or shepherd can move this process along\n   by pushing to conclude open discussions one way or another. This\n   includes, but is not limited to:\n\n   - answering unanswered questions themselves,\n   - seeking participation from other engineers to answer open questions,\n   - reducing the scope of the RFC so that open questions become out of scope,\n   - postponing a decision or answer to a later implementation phase,\n   - organize a meeting where open concerns are discussed orally,\n   - postponing/cancelling the work altogether.\n\n   In either case, the process to push for conclusion should seek\n   approval to conclude from the reviewer(s) who have opened the\n   discussions so far, allowing sufficient time for them to evaluate\n   the proposed conclusion.\n\n   Often disagreement on an RFC can be resolved by holding a meeting\n   between the interested parties to achieve consensus. The meeting notes\n   or a summary should be added to the RFC comments.\n\n5. At the point where the author(s) and/or shepherd\n   estimate there is consensus to proceed with the project, begin the\n   final comment period (FCP) by posting a comment on the PR.\n   For RFCs with lengthy discussion, the motion to FCP is usually preceded\n   by a summary comment laying out the current state of the\n   discussion and major tradeoffs/points of disagreement. The FCP\n   should last a minimum of two working days to allow collaborators\n   to voice any last-minute concerns.\n\n   In most cases, the FCP period is quiet, and the RFC is merged.\n   However, sometimes substantial new arguments or ideas are raised,\n   the FCP is canceled, and the RFC goes back into development mode.\n\n6. If there is still consensus to proceed after the FCP:\n\n   - change the `Status` field of the document to `in-progress`;\n   - update the `RFC PR` field;\n   - and merge the PR.\n\n   If the project is rejected, either abandon the PR or merge it\n   with a status of `rejected` (depending on whether the document and\n   discussion are worth preserving for posterity). The project may\n   receive a status of `postponed` rather than `rejected` if\n   it is likely to be implemented in the future.\n\n   Note that it is possible for an RFC to receive discussion after it\n   has been approved and its PR merged, e.g. during implementation.\n   While this is undesirable and should generally be avoided, such\n   discussion should still be addressed by the initiator (or\n   implementer) of the RFC. For instance, this can happen when an\n   expert is not available during the initial review (e.g. because she\n   is on vacation).\n\n7. Once the changes described in the RFC have been made, change the\n   status of the PR from `in-progress` to `completed`. If subsequent\n   developments render an RFC obsolete, set its status to `obsolete`.\n\n   When you mark a RFC as obsolete, ensure that its text references the\n   other RFCs or PRs that make it obsolete.\n\n# Overhead of the RFC process\n\nThere is a trade-off between the impetus to make\nmore time for decision-making and consensus-reaching, mandating\nminimum wait times to let every participant evaluate the work, and\nthe impetus to move fast and often discover/fix problems later.\n\n# RFC Status\n\nDuring its lifetime an RFC can have the following status:\n\n- Draft\n\n  A newly minted RFC has this status, until either the proposal is\n  accepted (next possible status: in-progress), deferred (next possible\n  status: postponed) or that it is DOA (next possible status: rejected).\n\n- Rejected\n\n  A RFC receives this status when the PR discussions have concluded\n  the proposal should not be implemented.\n\n  Next possible status: none. If you want to ressucitate an idea, make\n  a new RFC and refer to earlier RFCs.\n\n- In-progress\n\n  A RFC receives this status when the PR discussions have concluded\n  the proposal should be implemented, and the RFC is ready to commit\n  (merge) to the main repository.\n\n  Next possible status: completed (when the work is done), rejected\n  (proposal not implemented/implementable after all), obsolete (some\n  subsequent work removes the need for the feature).\n\n- Completed\n\n  A RFC receives this status when the described feature has been\n  implemented. It may stay with this status indefinitely or until made\n  obsolete.\n\n- Obsolete\n\n  A RFC receives this status when the described feature has been\n  superseded.\n\n- Postponed\n\n  A RFC receives this status when the PR discussions have concluded that\n  due to implementation complexity, lack of customer demand, or other\n  issues with the proposal, the work should be postponed to a later date.\n\n  Next possible status: draft (the decision has been made to reconsider\n  this proposal), rejected (proposal not implemented/implementable after all),\n  obsolete (some subsequent work removes the need for the feature).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Firods%2Firods_rfcs","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Firods%2Firods_rfcs","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Firods%2Firods_rfcs/lists"}