No formally defined process for working on problems

[AlexDaniel]

Currently there's no formally defined process for working on the core, the language and other aspects of the Perl 6 project. The result of this is general inconvenience (e.g. language changes are currently
proposed in rakudo/rakudo repo), and it is also the cause of misunderstanding when it comes to changes that some devs disagree with.

Some related issues:

• Lack of Clarity on Authorized Activities user-experience#33
• Official channels user-experience#32

[AlexDaniel]

Initial proposal: Create a new repo (perl6/problem-solving) for working on all issues that require discussion and/or consensus.

• Tickets filed in that repository will contain just the description of the actual problem (X of the XY), preferably starting with a short explanation and more (but not too many) details afterwards.
• Comments on issues will contain “Initial proposals” which are just short descriptions of the direction that can be taken in order to resolve the problem. The original poster is welcome to submit an initial proposal too.
• After some feedback and “ok, this sounds good, you can submit your proposed solution now” from a corresponding dev, a fullblown solution can be submitted in a Pull Request to perl6/problem-solving.
• Devs who are responsible for that category will request changes that are necessary to finalize the implementation of that solution. Once that is done, a review will be requested from all reviewers, and eventually the PR will be merged.

[AlexDaniel]

Note: This ticket may look a bit weird. It's an attempt to bootstrap this repo and provide a demonstration of how things will look like if this goes through.

I asked around and nobody seems to be against the idea, so 👍 and we can get to the PR.

[AlexDaniel]

PR: #2

[ugexe]

Much of this can be managed through GitHub projects. See https://github.com/rakudo/rakudo/projects/1 for a bare bones look, but it can handle automatically moving things around based on reviews/status/whatever.

[AlexDaniel]

I don't think GitHub projects can make things more convenient in this case, but assignees are free to use them if they so desire.

[samcv]

@AlexDaniel can you add me as a Unicode and Encoding/Decoding reviewer?

[AlexDaniel]

@samcv done, though I had to do something different than what you asked. I added you to the list of reviewers and also created a new unicode label and assigned that to you. So your review will be required for other issues (to ensure that other changes are not disturbing your work), and new problems related to unicode and encoding/decoding will be assigned to you.