Why is this repo not being created by using the existing process?

[AlexDaniel]

Putting https://github.com/Raku/Raku-Steering-Council/issues/6 aside, which is more general, here I want to ask a very specific question.

The problem-solving repository describes itself like this:

Raku/problem-solving repository is used for working on all issues that require discussion and/or consensus.

So why is the proposal for creating a steering council not being submitted in that repo? There we could have discussed the details and ironed out some rough edges. It would've been also possible to define exactly what's going to happen to problem-solving and do appropriate changes in the same pull request.

According to @vrurg, they wanted to do some minor changes but now it's “too late”. How come the Steering Council Code popped out into existence, and is now cast in stone? All that without using the existing process?

[AlexDaniel]

There are two relatively easy solutions that I came up with, pick any:

1. Pause this repo, submit a PR to the problem-solving repo with inevitable changes to its README and a link to this repo, which will be reviewed according to the existing process.
2. Let the voting and everything else happen, and only then submit a PR to the problem-solving repo (so same solution as ①, just later in time). This way people can keep doing what they want here, and later the council can properly take over the existing process.

[lizmat]

How come the Steering Council Code popped out into existence, and is now cast in stone?

The Steering Council did not pop into existence. The current state is that there will be an election. In which people that have had anything to do with Raku now and in its past can take part in as a candidate and as a voter.

Let the voting and everything else happen, and only then submit a PR to the problem-solving repo (so same solution as ①, just later in time). This way people can keep doing what they want here, and later the council can properly take over the existing process.

Yes, that would be an excellent way of solidifying both processes.

[AlexDaniel]

Yes, that would be an excellent way of solidifying both processes.

Just the new one. The existing process is pretty solid, and in fact it will become much weaker after your intended changes.

[vrurg]

According to @vrurg, they wanted to do some minor changes but now it's “too late”. How come the Steering Council Code popped out into existence, and is now cast in stone? All that without using the existing process?

Once again about the reason why I dislike IRC for such serious discussions. Being talking two parallel subjects at once it's easy to get lost. My "too late" statement didn't relate to the problem-solving status and rules. It was only related to RSC Code paper.

Just the new one. The existing process is pretty solid, and in fact it will become much weaker after your intended changes.

How come would it become weaker? You think people would start escalating up to RSC? Probably they will. Will their requests be accepted? A few perhaps. But most would still be subject for problem-solving process. Any other matters will be subject for consideration when the first RSC gets elected. It's most definitely not the time to discuss its not yet taken decisions.

[AlexDaniel]

It was only related to RSC Code paper.

I understood that and it's exactly what I meant.

How come would it become weaker? You think people would start escalating up to RSC? Probably they will.

Not only that, but there will be less incentive to actually work on improving proposals and discuss them because there will be an “easy way out”. The bar in the proposed council is significantly lower. Moreover, the problem-solving process was designed to avoid issues we had in the past. The problem-solving repo requires consensus and understanding of the upcoming changes, but here with a 4 vs 3 vote you can still have devs bullying each other over the things they misunderstood or don't agree with (example, but keep in mind that even though it talks about lack of clarity on authorized actions, it was more about the lack of clarity about which actions were actually authorized, and also to some extent about disagreement with the actions in general).

There are more interesting properties in the problem-solving repo that are there by design, for example the idea of “rejecting” solutions doesn't even exist. If there is a problem, you can solve it, and you can work on the solution as long as you need. The notion that a solution can be simply rejected is what, in my opinion, delayed the inevitable rename. Anyway, I can go on about these things but it seems like the majority just wants all that gone, which I don't mind, just do it right.

[vrurg]

It was only related to RSC Code paper.

I understood that and it's exactly what I meant.

Ok, then anyway you made wrong assumption over my words. The meaning of "too late" reflecting the fact that the election has been announced and I wasn't sure if the timing for changing the paper is good. I was mistaken. But even in this case nothing is said about the code to be cast in stone. Overall, I would say you're too fast on judging. And basically to me it looks now as if you're mostly fighting with your own understanding of the situation.

How come would it become weaker? You think people would start escalating up to RSC? Probably they will.

Not only that, but there will be less incentive to actually work on improving proposals and discuss them because there will be an “easy way out”. The bar in the proposed council is significantly lower. Moreover, the problem-solving process was

There is not going to be any easy way. It's like you're missing the key point: the council is about to minimize its actions as much as possible. Thus, most issues are to be passed via other channels with problem-solving being the most likely one.

designed to avoid issues we had in the past. The problem-solving repo requires consensus and understanding of the upcoming changes, but here with a 4 vs 3 vote you can still have devs bullying each other over the things they misunderstood or don't agree with

Here you contradict to the basic principle of democracy, actually. As long as the council is elected contributors give it their trust and authority. Thus it becomes the legitimate body. It's decisions are to be accepted because of the legally delegated credentials.

The problem-solving reviewers authority could though be disputed because the reviewers is rather a closed club accepting new members on their own will. So far other contributors trust it. But how far would this trust go in a critical situation?

My bottom line would be to ask you to let it cool down and think thoroughly. It is likely and even certain that the route we're taking isn't ideal. But neither is problem-solving. It's the problems we've got into with it which resulted in the idea of the council. Perhaps what must be eventually implemented is the classical separation of powers where each institution is capable of controlling the other one. I don't know yet, the life will show.

[AlexDaniel]

Here you contradict to the basic principle of democracy, actually. As long as the council is elected contributors give it their trust and authority. Thus it becomes the legitimate body. It's decisions are to be accepted because of the legally delegated credentials.

No, not exactly. First of all, I think we're in a situation when it's not possible that a council won't be elected. If it's not so, then how would that work? Secondly, I don't see how any group of people can self-declare that there will be a team whose decisions will override something that already exists, therefore democracy. For example, if one month later somebody creates a yet another process, with a new election and everything that overrides this council, that'd be fine because democracy?

It is likely and even certain that the route we're taking isn't ideal. But neither is problem-solving.

I think you're generally confusing the process which problem-solving describes on how to reach consensus with how tasks in Raku can be delegated. It “isn't ideal”, okay, can you show me a problem-solving pull request that didn't work to your expectations? What isn't actually ideal is that I deliberately left out the details on how people should delegate the tasks, leaving it all for the subject-matter experts to delegate to others and to provide documents on how they think things should be done. For example, I asked jnthn several times to post the document that they wrote about approaching language problems, but it just didn't happen. To be honest, I don't see how a team of 7 suddenly resolves that, but who knows.

[AlexDaniel]

Ah, also, please don't imply that the problem-solving repo is not democracy. It's an example of direct democracy, because anyone was free to join as a reviewer.

[vrurg]

will be a team whose decisions will override something that already exists,

"Override" is the key mistake you make. It's not about overriding.

[AlexDaniel]

"Override" is the key mistake you make. It's not about overriding.

What do you mean? How is it not?

[vrurg]

My bottom line would be to ask you to let it cool down and think thoroughly.

Sorry for self-reference, but it already takes too much time and doesn't worth it anymore as we're making circles.

[AlexDaniel]

I suggest you do the same. The document says this:

The Steering Council has broad authority to make decisions about the project. For example, it can:

• Accept or reject problem-solving proposals

Now, it's unclear as to what is meant by that exactly, which is why asked for clarifications in the first place. If this is about PRs, then yes, it does override the existing process. If not, then… well, it overrides it as well through other means, but let's start with the first part maybe.

[lizmat]

In my mind, this applies to PRs in the problem solving repo that for some reason have remained unresolved. RSC meetings won't be happening that often, I expect about every 2 months or so. So a PR must have been unresolved for at least 2 months before the RSC is asked to make a decision about it.

[AlexDaniel]

@lizmat thanks! Finally, some details.

[codesections]

Since the RSC has been voted in and begun work, I am closing this.