{"id":14965960,"url":"https://github.com/raku/problem-solving","last_synced_at":"2025-04-07T05:12:22.275Z","repository":{"id":39441601,"uuid":"172426981","full_name":"Raku/problem-solving","owner":"Raku","description":"🦋 Problem Solving, a repo for handling problems that require review, deliberation and possibly debate","archived":false,"fork":false,"pushed_at":"2025-01-27T14:33:40.000Z","size":173,"stargazers_count":71,"open_issues_count":248,"forks_count":13,"subscribers_count":38,"default_branch":"main","last_synced_at":"2025-04-07T05:12:09.894Z","etag":null,"topics":["raku"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"artistic-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Raku.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-02-25T03:22:06.000Z","updated_at":"2025-01-27T14:28:30.000Z","dependencies_parsed_at":"2024-09-14T01:21:48.834Z","dependency_job_id":"c09d5973-a00f-4325-a943-090ff2cc9c62","html_url":"https://github.com/Raku/problem-solving","commit_stats":{"total_commits":155,"total_committers":15,"mean_commits":"10.333333333333334","dds":0.5483870967741935,"last_synced_commit":"e1a76d0ea0f312ef1fa8645e6e680a4b8941c553"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Raku%2Fproblem-solving","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Raku%2Fproblem-solving/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Raku%2Fproblem-solving/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Raku%2Fproblem-solving/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Raku","download_url":"https://codeload.github.com/Raku/problem-solving/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247595335,"owners_count":20963943,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","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":["raku"],"created_at":"2024-09-24T13:35:37.409Z","updated_at":"2025-04-07T05:12:22.251Z","avatar_url":"https://github.com/Raku.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# 🦋 Problem Solving\n\n`Raku/problem-solving` repository is used for working on all issues\nthat require discussion and/or consensus. This document describes the\nprocess in more detail.\n\n## The Problem-Solving Process\n### Step 1: Reporting a problem\n\nAnyone is welcome to report a problem by creating a new issue. The issue should *only*\ncontain the description of the actual problem (X of the\n[XY](https://en.wikipedia.org/wiki/XY_problem)). The issue you\ncreate should start with a short description of the problem,\nfollowed by any additional details, if needed.\n\nThis repository has broad scope, but not all problems belong\nhere – only problems where consensus needs to exist but doesn't yet.\nFor example, if everyone already agrees on the proper approach to \nsolving a problem, then that issue isn't appropriate for this repo \n(even if a few technical questions about the implementation still \nneed to be worked out).  As a more concrete example, bugs in the \nRakudo compiler should be reported in\n[rakudo repository](https://github.com/rakudo/rakudo/issues).\n\nIf someone opens an issue that doesn't belong in Problem Solving,\nthen anyone with sufficient GitHub permissions to do so should close\nthe issue and either direct the user to the correct place to address \nthis issue (e.g., the Rakudo repo) or open an issue themselves.\n\n### Step 2: Initial proposed solution\n\nAnyone (including the person who opened the issue) can\nsubmit an initial proposal as a comment in reply to the issue. \n\nTo do so, start a comment with “Initial proposal:” and provide a short and\nclear description of the solution you're suggesting. Include just enough \ndetails to paint the general picture and refrain from writing too much \n(which will be required for the next step, but not now).\n\nGood solutions may resolve more than one problem: if so, link all other\nrelated problems that will be affected by your solution.\n\nBy proposing a solution, you are _typically_ volunteering to implement \nthat solution.  If you know that you won't be able to work on a \nfull solution, please **say so when proposing that solution**. Having a \nhero who will carry a solution though to implementation is often \nessential, but it is also  important to hear out good heroless ideas.\n\n### Step 3: Discussion of the proposal\n\nAfter the initial proposal, everyone is encouraged to discuss the idea and point\nout any flaws, implementation details, suggested changes, etc. that \nthey might see.  (Of course, both before and during step 3, people \ncan discuss the problem generally rather than a particular solution.)\n\nIn step 3, anyone can comment, but two people have an especially \nimportant role to play: the person who wrote the original proposal\nand the _assignee_ for the issue.\n\n#### Assignees\n\nIssues are assigned to corresponding devs (see\n[the list](#labels-and-responsible-devs)). The assignee's job is\nto help drive the process, provide vision, and assist everyone\ninvolved. Assignees can provide feedback, ask for clarifications,\nsuggest changes and so on as they see fit. \n\nAssignees can provide feedback on an initial solution, provide guidance\nabout what the full solution should include (e.g. what should be\ncovered in the document, additional requirements, etc). They can also \nreject initial proposals at step 3 (though this shouldn't happen often).\n\nIf an assignee is pleased with the initial proposal, they can ask to\nsubmit a fullblown solution.  Alternatively, if the person who suggested \nthe solution feels they have received enough feedback, they can decide to\nsubmit a full solution.  Either way, submitting a solution moves us to the\nnext step.\n\n\n### Step 4: Submitting a full solution\n\nAfter a problem/solution has been discussed sufficiently, someone should\nsubmit a Pull Request with a detailed proposal that would solve the problem.  \nThis PR should add a document to the \"solutions\" directory in this repo.\nTypically, the solution will come after a user has officially proposed an\ninitial solution (as described in Step 2, above) and, typically, the PR would\nbe written by the same user who wrote that initial solution.\n\nHowever, neither of these part of the above is _absolutely_ required.  For \nexample, if someone writes an initial solution but doesn't have time (or no\nlonger has time) to work on implementing the solution, it's fine for someone \nwho does have time to submit the PR.  Similarly, if an initial solution has \nbeen discussed without anyone _formally_ writing an \"initial solution\" comment,\nsomeone who was involved in that discussion can step forward and draft a PR. \n(This can sometimes happen when one user has a partial solution and other\nusers add to it without anyone drafting a formal initial solution.)  That said,\nit's still better to have a written initial solution and for the PR to be written\nby the same person.\n\nThe PR should act as a documentation for the solution and should provide\nall details that are required to implement the solution. Keep your document\nconsistent with other files in the solutions directory (naming, directory\nstructure, markup and so on).\n\nAt this point, anyone can provide feedback on the full solution and, if\ndesired, the PR author can revise the PR based on that feedback.\n\n\n### Step 5: Solution resolution\n\nOnce someone has submitted a PR, it can be resolved in one of 4 ways:\n\n1. Consensus acceptance\n2. Speedy acceptance\n3. Acceptance without consensus\n4. Non-acceptance\n\n#### Consensus acceptance\n\nThe most common way for a proposal to be accepted is for the discussion to\nproceed to a point where a consensus exists in favor of the solution.  A \nconsensus does not require _unanimity_, but it should be clear that the\nRaku community as a whole supports the solution.  In particular, if 14 days\npass between the time when the PR (or the latest revision of the PR, if it's \nedited) was proposed and none of the [reviewers](#reviewers) (listed below) \nhave objected, then the proposer of the PR can use their judgement to determine\nwhether consensus exists.  However, if any of the reviewers objects to the PR's \nsolution or 14 days have not yet passed, then consensus does *not* support\nthat solution.\n\n#### Speedy acceptance\n\nIf all reviewers approve a solution, then it can be accepted even if 14 days\nhave not passed.\n\n#### Acceptance without consensus\n\nIn **very** rare cases, a PR's solution can be accepted even when the Raku\ncommunity cannot reach consensus.  When the Problem Solving process was first\nadopted, the way Raku solved problems when consensus couldn't be reached was by\nan action by the Benevolent Dictator for Life (Larry Wall).  After the [Raku \nSteering Council Code](https://github.com/Raku/Raku-Steering-Council/blob/main/papers/Raku_Steering_Council_Code.md) \nwas adopted, the process for resolving deadlock shifted to the RSC as \ndescribed in that document.  In either case, this power should be exercised \nonly as a last resort and in extremely exceptional cases.\n\n#### Non-acceptance\n\nIf a solution is not accepted by any of the methods described above, then \nit is not accepted.  Arguably, this isn't a resolution at all – the problem\nremains unsolved and the issue stays open.  But that particular solution\nhas failed to gain acceptance (though, of course, a different solution or \neven a revised version of the same solution could later be accepted).\n\n\n## Edge cases and other notes\n\n* If any of the merged solutions needs an adjustment, the process should\n  start from the beginning. That is, an issue should be filed stating\n  the problem with the current solution, and the process continues as\n  normal. PRs are allowed to change, modify and shadow existing\n  solutions.\n* Assignees are allowed to call for a “shortcut” to any problem, in\n  which case the solution is applied directly without going through\n  the whole process.\n* Non-functional changes to existing solutions automatically go\n  through a shortcut (typos, grammar, formatting, etc.), just submit\n  a PR right away.\n* If a shortcut receives any criticism from the corresponding\n  development team or other affected parties, it can be reverted and\n  the full formal process should begin.\n* Passing the assignee status is allowed provided that the receiving\n  party agrees. One-time assignees are allowed through this process.\n* People are allowed to be assigned to their own PRs.\n\n\n\n## Labels and responsible devs\n\nFile a `meta` issue if you want to create a new label or if you want\nto be added as a responsible dev.\n\n* `meta` – changes to the `problem-solving` repo and this document\n  * [@codesections](https://github.com/codesections)\n* `language` – changes to the [Raku language](https://github.com/perl6/roast/)\n  * –\n* `rakudo` – big changes to [Rakudo](https://github.com/rakudo/rakudo/)\n  * –\n* `moarvm` – big changes to [MoarVM](https://github.com/MoarVM/MoarVM)\n  * –\n* `documentation` – big changes to\n  [Raku documentation](https://github.com/Raku/doc/) and other learning\n  resources\n  * [@coke](https://github.com/coke)\n* `unicode` – Unicode and encoding/decoding\n  * [@samcv](https://github.com/samcv)\n* `infrastructure` - servers, hosting, cloud, monitoring, backup and automation\n  * [@rba](https://github.com/rba)\n  * [@maettu](https://github.com/maettu)\n* `fallback` – if no other label fits\n  * [@codesections](https://github.com/codesections)\n\n## Reviewers\n\nFile a `meta` issue if you want to be added to this list.\n\n* [@codesections](https://github.com/codesections)\n* [@FCO](https://github.com/FCO)\n* [@JJ](https://github.com/JJ)\n* [@lizmat](https://github.com/lizmat/)\n* [@maettu](https://github.com/maettu)\n* [@masak](https://github.com/masak)\n* [@MasterDuke17](https://github.com/MasterDuke17)\n* [@rba](https://github.com/rba)\n* [@samcv](https://github.com/samcv)\n* [@timo](https://github.com/timo)\n* [@tony-o](https://github.com/tony-o)\n* [@vrurg](https://github.com/vrurg)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fraku%2Fproblem-solving","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fraku%2Fproblem-solving","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fraku%2Fproblem-solving/lists"}