Governance Community and Language

[finanalyst]

Hi to everyone here. I got an email this morning adding me to this Repo, and for the first time I discover what is happening! I am not a regular visitor to IRC, but I read the perl6-users mailing list. I have been involved in founding organisations in the past - I chaired the founding group for the CFA Association in Russia and was its President for 10 years. So I feel I have some experience in creating an organisation and a community. That sort of experience is very different to language design.

Some thoughts, and comments that refer to subjects related to all of the issues and comments in this repo. a) It should be clear that there we have a distinct Language - Raku - and a distinct community. The two are connected but have different needs. Consequently, the decision processes and interventions for each of them should be different.

The Language needs people with specific deep skills in some very arcane areas. These people tend not to have the social skills needed to coordinate a community. This is not a jab at anyone in this group. It is a general comment that people with skills in one area may not have skills in another. Einstein was the most brilliant of theoreticians, but he was not a community organiser, nor did he really like society.

So it is entirely reasonable and necessary for there to be one space in which the Raku Language is developed, and the problems associated with the Language are considered. This would be the Problem-Solving Repo.

It is also necessary for there to be a space that is dedicated to the Community, and expanding the Community.

b) Without a Community the language would not be able to attract designers or users. As the Community expands and more people and companies use Raku, so will the funding and interest in Raku grow, and this will provide resources to those who are developing the language Raku.

In addition, a Community will include many people with only a bare understanding of the language or any acquaintance with the developers. The core team will of course interact far more with each other and will get to understand the way they express themselves. A wider community will not have that experience and may react unpredictably to unexpected commentaries. There needs to be mechanisms to manage such situations in a timely and gentle manner.

c) The Raku Community at present is helpful, friendly and patient. In a world that is partisan and polarised, this is a very valuable and rare asset. It is something that should be encouraged. It should be baked into the Founding Documents from the very outset.

d) I just read all the documents in this repo quickly. Although an aim is to be Bland and Boring, I do not think that those are really ideal qualities for a new language community, and I do not think they will conserve the value that the Raku community already has. I understand the desire not to reinvent the wheel, but the world has seen a great deal of social interaction and there are many lessons already learnt that can be incorporated. For example, the voting methods are not specified, and there are many ways of voting. It is not bland to leave out necessary material.

e) I was struck by the amount of words put into things like expulsion of members, votes of no confidence, but nothing about the qualities of friendliness and helpfulness in the Community.

To be frank, a community that has reached the extremes of expelling members from the governing board has ALREADY failed. People are spending more time doing partisan politics and persuading voters to go with them than they are on developing the language and writing fabululous software.

It is far easier, and requires less emotion, to make a gentle but firm intervention with someone who is getting angry or being repulsive when they are just getting angry, than it is to allow negative emotions to blow into flame wars, and votes of no confidence. Reminding someone clearly that the Raku community has a culture of cooperation and mild words will allow time to cool off, for people to recognise they have more in common than otherwise. Friendly relationships are not destroyed. Valuable contributors will not disappear without trace.

I would strongly suggest that emphasis is put on the expected culture and code of conduct, and on the sort of gentle interventions that are reasonable. Then in a single paragraph describe that in extreme circumstances, such as disaffection with a single individual or group given authority in the community or language development, a resolution is proposed and subject to a vote. This allows for all sorts of remedies to be proposed without the binary expulsion remedy taking up so much wording.

f) There must be more time for things that affect the community to become understood. I have only just become aware of these documents and changes. I spend a lot of time using Raku and writing Raku modules. I have followed the development of the Language from its inception. But I am not a language professional, and I have not been able - perhaps through a failing of my own - to follow all the forums.

I am sure there may be others like me.

The Founding Documents presented here are not good ones - for a community. They focus on the wrong things, and do not clearly address the relationships that are needed.

g) Do I understand that these are the final documents? And that they are going to be put to the vote in the near future? It seems to me that there should be more discussion and a longer time frame. I would be very interested in trying to improve them

Richard Hainsworth aka finanalyst

[AlexDaniel]

Here are some of my thoughts. You decide if they make sense and if they're helpful at all :)

e) I was struck by the amount of words put into things like expulsion of members, votes of no confidence, but nothing about the qualities of friendliness and helpfulness in the Community.

Yeah, that surprised me as well and I commented on that before. You seem to be a much better communicator so maybe it will be heard this time :)

d) So it is entirely reasonable and necessary for there to be one space in which the Raku Language is developed, and the problems associated with the Language are considered. This would be the Problem-Solving Repo.

Yeah, I'm OK with that, but right now I see that the Raku Steering Council is trying to somehow claim all power over the problem-solving repo. Should it? I was told that the two processes are meant to be completely separate, but they factually are just not. Maybe you can define what each of the processes should do exactly?

To be frank, a community that has reached the extremes of expelling members from the governing board has ALREADY failed. People are spending more time doing partisan politics and persuading voters to go with them than they are on developing the language and writing fabululous software.

Yeah, that's what I kept in mind when designing the problem-solving repo. No exclusion, no persuading voters to get the majority, just make the PR right so that everyone is OK with it. Yeah, it is naïve, but I believe that the reviewers in the problem-solving repo are capable of talking to each other and adjusting both the solution and their position in order to achieve something that is good for the project.

c) The Raku Community at present is helpful, friendly and patient. In a world that is partisan and polarised, this is a very valuable and rare asset. It is something that should be encouraged. It should be baked into the Founding Documents from the very outset.

Yes and no. It's nice to be friendly, but I think the community has been lacking some disagreement for years. In a situation like this, any change is OK, and those who disagree are framed as unfriendly or impatient. This is why the problem-solving repo creates a more formal setting for expressing how a change can negatively affect you, and gives you a full right to pause everything and start a discussion even if you're a minority. In contrast, a 4 to 3 vote in the proposed council will probably lead to people telling the unfortunate 3 to effectively “suck it up” and move on because a decision was made.

The Founding Documents presented here are not good ones - for a community. They focus on the wrong things, and do not clearly address the relationships that are needed.

And I'd say that they also don't solve any actual issues that we currently have. See, the problem-solving repo requires anyone to first define a problem and then construct a solution that addresses it. Because the steering council was created outside of this process, it's not just unclear if it is fixing anything, but it's even unclear what it is trying to resolve in the first place.

Here's some context. Problem-solving repo assigns people to specific topics, and they are then supposed to provide guidance and insight on how to proceed with issues. My hope was that people would delegate to others and submit documents that describe their decision-making process so that people wouldn't need to ping them for every little thing. However, it was made clear to me that delegation and sharing of responsibilities will not happen and no documents were submitted (even though there exists one, and I repeatedly asked to just publish it).

Then we get this ticket which claims that the process itself is at fault. OK, let's say it is, but how is the Raku Steering Council going to make the mentioned issues go away? Will it suddenly become easier to make decisions about the language? Why?

g) Do I understand that these are the final documents? And that they are going to be put to the vote in the near future? It seems to me that there should be more discussion and a longer time frame. I would be very interested in trying to improve them

Yeah, I personally wasn't even given a chance to look at them before it all happened. From what I understand there were some private emails discussing it, and then it went live. I'm not sure, maybe the repo was up a few days before the announcement? I did see something about “RSC” in my github notifications (which I have hundreds) but I didn't click on it because I was trying to have a break. Moreover, when I started asking why they are trying to create a new process when we already have one, people told me that they just forgot that we already had an existing process… Heh.

It's a mess, yeah. I kinda wish I was able to do something to make it better, but I don't think there's anything I can actually do. Honestly, I'm now feeling like taking an L on my efforts for this project and moving somewhere else :)

[JJ]

El jue., 30 jul. 2020 14:39, Aleks-Daniel Jakimenko-Aleksejev < notifications@github.com> escribió:

Here are some of my thoughts. You decide if they make sense and if they're helpful at all :)

e) I was struck by the amount of words put into things like expulsion of members, votes of no confidence, but nothing about the qualities of friendliness and helpfulness in the Community.

Yeah, that surprised me as well and I commented on that before. You seem to be a much better communicator so maybe it will be heard this time :)

d) So it is entirely reasonable and necessary for there to be one space in which the Raku Language is developed, and the problems associated with the Language are considered. This would be the Problem-Solving Repo.

Yeah, I'm OK with that, but right now I see that the Raku Steering Council is trying to somehow claim all power over the problem-solving repo. Should it? I was told that the two processes are meant to be completely separate, but they factually are just not. Maybe you can define what each of the processes should do exactly?

To be frank, a community that has reached the extremes of expelling members from the governing board has ALREADY failed. People are spending more time doing partisan politics and persuading voters to go with them than they are on developing the language and writing fabululous software.

Yeah, that's what I kept in mind when designing the problem-solving repo. No exclusion, no persuading voters to get the majority, just make the PR right so that everyone is OK with it. Yeah, it is naïve, but I believe that the reviewers in the problem-solving repo are capable of talking to each other and adjusting both the solution and their position in order to achieve something that is good for the project.

The problems are not PRs ( although they could be). The problems are issues without PRs, and PRs affected by Warnock's dilemma.

[AlexDaniel]

The problems are not PRs ( although they could be). The problems are issues without PRs, and PRs affected by Warnock's dilemma.

And a steering council is going to resolve that in what way exactly? Also, as a bonus question, how would it be different from let's say listing 7 people under the language label (and possibly other labels) here?

By the way, this is why every ticket in the problem-solving repo has an assignee, so that you can go on IRC and talk to a specific person directly. Lately, however, @lizmat was removing assignees for some reason, leaving tickets subject to Warnock's dillema instead of having a clear indication that there wasn't a response by the assignee yet.

[lizmat]

@AlexDaniel having @jnthn always as the assignee, does NOT mean that anybody can just go on IRC and discuss that with him. That is the reason I have removed only @jnthn as assignees, as it was just creating stress for him. But I shall refrain from doing so in the future.

With regards to the rest of the comments. I have read them and I will be responding to them in time.

[AlexDaniel]

@AlexDaniel having @jnthn always as the assignee, does NOT mean that anybody can just go on IRC and discuss that with him. That is the reason I have removed only @jnthn as assignees, as it was just creating stress for him. But I shall refrain from doing so in the future.

Actually, my intent has been that it'd be exactly like that, that people would be able to talk to the assignee (otherwise what's the point of having an assignee at all). I understand that it's unacceptable that everything points at a single person, but I've been saying it countless times now that @jnthn should do something about it. @jnthn can delegate subtopics to another person or a group of people. He can also finally publish the document that described some expectations for new changes to the language. There are many ways to address this, and the problem-solving repo doesn't impose any specific one, do anything that helps.

Have you talked to jnthn (like I suggested a long time ago)? What's his stance on delegating some of the decision making that he has to do wrt language tickets? Note that the steering council is not going to magically resolve that, in fact it's very unrelated.

[finanalyst]

It is inevitable that there will be disagreement. That is life. The trick is to find a way to manage disagreements and agreements, so that even when there are fundamental disagreements of principle, the community (and the development team) finds a way to go forward without pulling the community apart, or for people to loose their desire to contribute.

In addition, it is never a sustainable strategy for a community to be led by a single person, or for a single person to design the rules of a community. At the same time, some things have to be decided. When there is a collective leadership, it means the majority will have the decision. But the minority is not always the same for every decision. And if there is sufficient understanding about why a decision is made, then it is possible for the minority members to 'acquiesce' for the benefit of the community. I am not being idealistic here. I know from experience this approach works.

[AlexDaniel]

It is inevitable that there will be disagreement. That is life. The trick is to find a way to manage disagreements and agreements, so that even when there are fundamental disagreements of principle, the community (and the development team) finds a way to go forward without pulling the community apart, or for people to loose their desire to contribute.

Not sure if I understand what you're trying to say. Not pulling the community apart is something that problem-solving repo managed to do in the past, or am I wrong? It seemed to work for the rename, even though it wasn't perfectly smooth.

When there is a collective leadership, it means the majority will have the decision. But the minority is not always the same for every decision. And if there is sufficient understanding about why a decision is made, then it is possible for the minority members to 'acquiesce' for the benefit of the community. I am not being idealistic here. I know from experience this approach works.

Again, I don't understand. The problem-solving repo pretty much requires people to acquiesce in the end, or requires those who propose the change to adjust it so that it doesn't hurt the minority. What are you trying to say? Can you dumb it down a bit for me?

[finanalyst]

AlexDaniel: "Yeah, I'm OK with that, but right now I see that the Raku Steering Council is trying to somehow claim all power over the problem-solving repo. Should it? I was told that the two processes are meant to be completely separate, but they factually are just not. Maybe you can define what each of the processes should do exactly?" There are different sorts of problem. Problems dealing with Language design and implementation are about evidence, logic, design parameters, and so on. Problems involving the behaviour of individuals, such as abusive language, implicit prejudice against women, minorities, non-English speakers, etc, or where highly creative individuals are subject to emotional stress or even financial stress, these are problems that need a different approach and a different type of governance. The two obviously are inter-related. Again a balance needs to be found

[finanalyst]

"Again, I don't understand. The problem-solving repo pretty much requires people to acquiesce in the end, or requires those who propose the change to adjust it so that it doesn't hurt the minority. What are you trying to say? Can you dumb it down a bit for me?" Actually I think both are necessary. When there is a group on the governing council see they have a majority for their point of view, it is their responsibility to find a way to adjust their proposal in a way that will gain more support (or less resistance) from those in the minority. When the members of the group who see they are in a minority on a proposal, they should adapt to the proposal. Sometimes for a period of time. I have been in a minority of a council where I was convinced I was right. I adapted to the majority. In the end I was right because I had understood reality better. But by supporting the majority first, and by putting the process of decision making first, it was much easier to suggest a change in policy later. Time is a great way for discovering the truth,

[finanalyst]

AlexDaniel: "Have you talked to jnthn (like I suggested a long time ago)? What's his stance on delegating some of the decision making that he has to do wrt language tickets? Note that the steering council is not going to magically resolve that, in fact it's very unrelated." My comments here are somewhat at a distance because I have not been involved in the detail of Raku development. I have seen the huge number of tickets, and I can see that it might be very discouraging not to see any progress. I can only give a comment related to the single proposal I made to the compiler (a change in --doc ). I made a proposal, talked about it, changed some part of my proposal, but I don't know how or whether it will be incorporated. Ideally, there would be a FAQ about how PRs are processed, who decides what get included, and some form of time line. I am not pushing for any decision here on "my" tiny tiny proposal, but for a way that would encourage people to take part and feel they are making a contribution.

As the community of users and developers grows, the number of changes is going to grow, and the number of tickets will rise, not fall. A governing council will not change this. There is no magic here, or a formula for solving all problems.

But a governing council can look at the process of solving problems, managing who solves which problem, which problem needs solving, and constructing metrics that demonstrate progress is being made. It can look at how to encourage progress.

(I remember when Rakudo was being developed and the number of tests being passed was much smaller than those failing. There was a time when I wondered whether Raku would EVER appear!!!! Progress seemed to be glacial. People in other language communities would laugh at us - they still do. But Raku is still the best language I know.)

I think what is being proposed here is more about the "meta" questions of development, not development itself.

[lizmat]

@finanalyst

Hi to everyone here. I got an email this morning adding me to this Repo, and for the first time I discover what is happening! I am not a regular visitor to IRC, but I read the perl6-users mailing list.

Indeed, I have forgotten to put a mail about this on the perl6-users mailing list. For a long while I followed that mailing list, bit ToddAndMargo have completely soured my appetite to follow that. My apologies. It was advertised in the Rakudo Weekly News, on Reddit in /r/rakulang and on Twitter. It was not like I was trying to keep it a secret.

The reason you got the email this morning, was that we found out yesterday that way fewer people had write access to the repo than was thought: I assume you were added because you did some kind of commit / PR in the past.

I have been involved in founding organisations in the past - I chaired the founding group for the CFA Association in Russia and was its President for 10 years. So I feel I have some experience in creating an organisation and a community. That sort of experience is very different to language design.

Indeed. And welcome that experience.

a) It should be clear that there we have a distinct Language - Raku - and a distinct community. The two are connected but have different needs. Consequently, the decision processes and interventions for each of them should be different.

I would argue that we are moving in that direction. For too long a time, the developers were the community. A community that looked at a BDFL for guidance. Which sadly led to a complete burnout of said BDFL. Which caused too many issues to just linger and cause people to drop out. And that's why there are changes needed.

The Language needs people with specific deep skills in some very arcane areas. These people tend not to have the social skills needed to coordinate a community. This is not a jab at anyone in this group. It is a general comment that people with skills in one area may not have skills in another. Einstein was the most brilliant of theoreticians, but he was not a community organiser, nor did he really like society.

FWIW, I think the social skills of many of the core developers, have brought us to where we are in a community that is considered to be one of the most friendly by many. In that sense, Larry has set a good example.

So it is entirely reasonable and necessary for there to be one space in which the Raku Language is developed, and the problems associated with the Language are considered. This would be the Problem-Solving Repo. It is also necessary for there to be a space that is dedicated to the Community, and expanding the Community.

So you're suggesting the problem-solving repo should only be for technical issues? And that there should be a separate repo for solving non-technical issues? In my opinion, in the foreseeable future a single problem-solving repo should be able to serve all aspects of community and language issues. For the simple reason that there are issues with aspects on both sides of the technical <-> community spectrum. Having to have two repos also feels like a premature optimization to me: we don't have enough people wanting to do stuff in one repo already.

b) Without a Community the language would not be able to attract designers or users. As the Community expands and more people and companies use Raku, so will the funding and interest in Raku grow, and this will provide resources to those who are developing the language Raku.

That is a hope, indeed.

In addition, a Community will include many people with only a bare understanding of the language or any acquaintance with the developers. The core team will of course interact far more with each other and will get to understand the way they express themselves. A wider community will not have that experience and may react unpredictably to unexpected commentaries. There needs to be mechanisms to manage such situations in a timely and gentle manner.

So what mechanisms are you suggesting here?

c) The Raku Community at present is helpful, friendly and patient. In a world that is partisan and polarised, this is a very valuable and rare asset. It is something that should be encouraged. It should be baked into the Founding Documents from the very outset.

Agree.

d) I just read all the documents in this repo quickly.

I would urge you to read them more thoroughly than just quickly. And to digest what it says. Time is a great way for discovering the truth.

Although an aim is to be Bland and Boring, I do not think that those are really ideal qualities for a new language community, and I do not think they will conserve the value that the Raku community already has. I understand the desire not to reinvent the wheel, but the world has seen a great deal of social interaction and there are many lessons already learnt that can be incorporated. For example, the voting methods are not specified, and there are many ways of voting. It is not bland to leave out necessary material.

Not having a voting process specified (except for the initial election) frees the Steering Council from being restricted to a particular way of voting. I see this first election of the RSC as a bootstrap process that will give us something to allow us to get out of the current situation, where we've basically lost the BDFL to burnout, and the current "pumpking" is very close to one as well.

e) I was struck by the amount of words put into things like expulsion of members, votes of no confidence, but nothing about the qualities of friendliness and helpfulness in the Community.

You could consider membership of a Steering Council as a marriage. Even though people can be madly in love with each other, Marriages nowadays are seldom performed without a prenuptial agreement. Some provisions in such an agreement apply to when things go wrong. This is nothing different from that. It provides clarity for everybody involved.

The reason these provisions are in there, are because of the problems that Python community has had in the past. Which are very similar to the flamewars on p5p in the late 90s, which was one of the reasons Perl 6 was started anyway (because Larry also wanted to reconstruct the community).

To be frank, a community that has reached the extremes of expelling members from the governing board has ALREADY failed. People are spending more time doing partisan politics and persuading voters to go with them than they are on developing the language and writing fabululous software.

I would argue that in the EXTREME case a member would be expelled from the RSC, it is to ensure that the language and the community can continue. Sadly, some people who spent a lot of time on developing Perl 6 that would have been in a Steering Council had there been one, have turned on the project in such a way that they at least appear to want to damage the project in any way they can. And we've observed something similar happening in the past month, where the remarks of a prominent member of the community made a returnee to the community seriously consider going away again.

It is far easier, and requires less emotion, to make a gentle but firm intervention with someone who is getting angry or being repulsive when they are just getting angry, than it is to allow negative emotions to blow into flame wars, and votes of no confidence. Reminding someone clearly that the Raku community has a culture of cooperation and mild words will allow time to cool off, for people to recognise they have more in common than otherwise. Friendly relationships are not destroyed. Valuable contributors will not disappear without trace.

Alas, these have already happened. Relationships have been damaged, valuable contributors have left for the wrong reasons.

I would strongly suggest that emphasis is put on the expected culture and code of conduct, and on the sort of gentle interventions that are reasonable. Then in a single paragraph describe that in extreme circumstances, such as disaffection with a single individual or group given authority in the community or language development, a resolution is proposed and subject to a vote. This allows for all sorts of remedies to be proposed without the binary expulsion remedy taking up so much wording.

I would welcome a PR for rewording. On the other hand, this is also something a properly elected RSC can do.

f) There must be more time for things that affect the community to become understood. I have only just become aware of these documents and changes. I spend a lot of time using Raku and writing Raku modules. I have followed the development of the Language from its inception. But I am not a language professional, and I have not been able - perhaps through a failing of my own - to follow all the forums.

I would not be against postponing the deadline for the nomination process, and consequently for the election process. I think many people need to be involved in this process. I'm glad you've decided to let your voice be heard. And as such would appreciate adding a nomination for yourself.

I am sure there may be others like me. The Founding Documents presented here are not good ones - for a community. They focus on the wrong things, and do not clearly address the relationships that are needed.

They've been good for a few other communities so far. It really was 99% a cat-license job (that would be a dog-license with the word "dog" crossed out and replaced by "cat"). I think it does address the relationships that are needed. But, again, I would welcome PR's for changes to the wording.

g) Do I understand that these are the final documents? And that they are going to be put to the vote in the near future? It seems to me that there should be more discussion and a longer time frame. I would be very interested in trying to improve them

That's the thing: I think the Raku community needs clarity on where it is going. I had one big reason for putting this into a repo separate from the problem-solving repo. I consider this a meta-meta-issue that should provide structure for solving all other issues, whether they be technical (like many issues in the rakudo repo are), or technical issues in the problem-solving repo. If this had been put in the problem-solving repo, it would have gotten Warnocked and nothing would have happened.

One of the nominees for the RSC has taken it upon them to eradicate this repo if they're elected. I would against that, to provide history. But to have this repo archived, no problem! It would prove that we would have a functioning Raku Steering Council.

But nothing is cast in stone, and everything becomes fluid under pressure. For the sake of the process, I would prefer making changes to the documents after an election. For the simple reason that there is no clarity about the mandate of making changes to it. That's the reason I used an established document as a template. But please, by all means, make PRs with text suggestions: if they're not changed before the election, they can definitely be a source of discussion / inspiration or just be merged as is in the future.

[lizmat]

@AlexDaniel

And a steering council is going to resolve that in what way exactly? Also, as a bonus question, how would it be different from let's say listing 7 people under the language label (and possibly other labels) here?

A steering council is going to resolve that with a formal vote. It would be different from listing 7 people under the language label, because a Raku Steering Council would have a mandate from the entire community, instead of just from the people who happen to have voting rights in the problem-solving repo.

I have been accused of not wanting the problem-solving repo, of sabotaging it, and what not. The thing is, is that I think the problem-solving repo has been a good bootstrap. But the main thing it is missing, is decisiveness. And the decisiveness is lacking because it lacks a proper mandate. As @finanalyst pointed out, people with a stake in Raku who are not core developers, also need to be able to be heard. And they are not in the current format. Nor has the larger community any way of making their interests represented. Which I hope a RSC will allow the larger community and its stakeholders to do.

[AlexDaniel]

But the main thing it is missing, is decisiveness. And the decisiveness is lacking because it lacks a proper mandate. As @finanalyst pointed out, people with a stake in Raku who are not core developers, also need to be able to be heard. And they are not in the current format. Nor has the larger community any way of making their interests represented. Which I hope a RSC will allow the larger community and its stakeholders to do.

I'm failing to deconstruct what you're trying to say here. Can you explain? Anyone can become a reviewer in the problem-solving repo. How will the steering council be better than that?

[lizmat]

@AlexDaniel

Actually, my intent has been that it'd be exactly like that, that people would be able to talk to the assignee (otherwise what's the point of having an assignee at all).

The point of an assignee, is that someone is responsible for getting the ticket to a good result. Or if not, close the issue. It is not intended, nor can it ever be, an open invitation to have everybody just start talking to you about that on IRC.

Have you talked to jnthn (like I suggested a long time ago)?

Yes. Do you think I came up with the proposal for the RSC without consulting him, or his final ok to go ahead?

What's his stance on delegating some of the decision making that he has to do wrt language tickets? Note that the steering council is not going to magically resolve that, in fact it's very unrelated.

The RSC is not going to be able to magically resolve anything. Whatever decisions it will make, will at least have the mandate of the whole Raku community.

[AlexDaniel]

Yes. Do you think I came up with the proposal for the RSC without consulting him, or his final ok to go ahead?

I'm not talking about this new RSC thing. I'm asking you if you have figured out how language decisions can be made without jnthn, especially if we consider the amount of tickets in the problem-solving repo and how fast they're coming in. And if you think RSC is going to resolve that, please explain how.

[lizmat]

In addition, it is never a sustainable strategy for a community to be led by a single person, or for a single person to design the rules of a community.

But this is effectively what happened with the BDFL not being present anymore, and the project lead Patrick Michaud to also silently leave. All of a sudden, Jonathan had all of those roles thrown in his lap. And the problem-solving repo was a step in the good direction, but it still in the end, mostly points to a single person. And that person is taking that responsibility very seriously.

At the same time, some things have to be decided. When there is a collective leadership, it means the majority will have the decision. But the minority is not always the same for every decision. And if there is sufficient understanding about why a decision is made, then it is possible for the minority members to 'acquiesce' for the benefit of the community. I am not being idealistic here. I know from experience this approach works.

If anything, I see the RSC as collective leadership.

[lizmat]

@finanalyst

I made a proposal, talked about it, changed some part of my proposal, but I don't know how or whether it will be incorporated. Ideally, there would be a FAQ about how PRs are processed, who decides what get included, and some form of time line. I am not pushing for any decision here on "my" tiny tiny proposal, but for a way that would encourage people to take part and feel they are making a contribution.

There is no real process for this. In my view, a community member could put this on the agenda of the next RSC meeting, to force at least visibility of the issue, and if that in itself doesn't provide a resolution, go have it put to a vote.

[AlexDaniel]

Sadly, some people who spent a lot of time on developing Perl 6 that would have been in a Steering Council had there been one, have turned on the project in such a way that they at least appear to want to damage the project in any way they can. And we've observed something similar happening in the past month, where the remarks of a prominent member of the community made a returnee to the community seriously consider going away again.

If you want to get personal then you can write my name instead of being vague. Turns out having an opinion that the project went into a wrong direction is “wanting to damage the project in any way they can”.

But at the same time:

Alas, these have already happened. Relationships have been damaged, valuable contributors have left for the wrong reasons.

Can I remind you that you were pretty much the reason that a valuable contributor left. A lot about that situation made me design the problem-solving repo in a particular way. And yes, the RSC is a step back in that regard.

[lizmat]

I'm failing to deconstruct what you're trying to say here. Can you explain? Anyone can become a reviewer in the problem-solving repo. How will the steering council be better than that?

Please don't focus too much on the problem-solving repo itself. It is a tool, it is not a goal! A useful tool. But a tool.

What the problem-solving issue ultimately is missing, is a defined mandate from the community. An election of a RSC hopefully will provide that mandate. As it should allow all stakeholders to have a say. And with rules, protect from future degradation: rules such as only having 1 person per company in the RSC, to prevent one group skewing the decision processes.

[AlexDaniel]

What the problem-solving issue ultimately is missing, is a defined mandate from the community. An election of a RSC hopefully will provide that mandate. As it should allow all stakeholders to have a say. And with rules, protect from future degradation: rules such as only having 1 person per company in the RSC, to prevent one group skewing the decision processes.

I don't get it. You first said “people with a stake in Raku who are not core developers, also need to be able to be heard”. I think I made it clear that it is absolutely false, because anyone can become a reviewer. Now you respond with what is seemingly another problem: “rules such as only having 1 person per company in the RSC”. I can explain that as well, but it seems like in this discussion the goal posts are constantly being moved for the sake of moving them.

[lizmat]

If you want to get personal then you can write my name instead of being vague. Turns out having an opinion that the project went into a wrong direction is “wanting to damage the project in any way they can”.

Oddly enough, it was not you who I had in mind.

Can I remind you that you were pretty much the reason that a valuable contributor left. A lot about that situation made me design the problem-solving repo in a particular way. And yes, the RSC is a step back in that regard.

Assuming you're talking about Zoffix, yes: I have had a big disagreement with him and I have been very vocal about that. And I frequently am reminded of that, not just by you. But I think Zoffix and I have been able to talk about it and that there was a whole set of events that happened in a way, that could have happened in a better way. I was defending Larry's vision, in that Perl 6 is the successor to Perl 5 and interpreted Zoffix actions as a direct attack on that. Zoffix waited for 2 months for Larry to come out and say something about the situation. He didn't. That's when Zoffix left.

In hindsight I should have joined Zoffix' request for a name change much earlier. And should have realized that Larry was incapable of decision. I can only hope that I've redeemed myself a bit by initiating the actual name change to Raku. Not only has that given new air to the project, it also has given new air to the Perl project. But it still hurts.

[lizmat]

I don't get it. You first said “people with a stake in Raku who are not core developers, also need to be able to be heard”. I think I made it clear that it is absolutely false, because anyone can become a reviewer.

A reviewer can review and give their thoughts. But has no way to force a decision. A community member can as the RSC for a decision if it turned out to be impossible to get to a decision without reaching out to the RSC.

Now you respond with what is seemingly another problem: “rules such as only having 1 person per company in the RSC”. I can explain that as well, but it seems like in this discussion the goal posts are constantly being moved for the sake of moving them.

I was referring to the conflicts of interest section, which specifically states:

the mere appearance of any one company dominating Raku development could itself be harmful and erode trust. In order to avoid any appearance of conflict of interest, at most 2 members of the council can work for any single employer.

And thank you for making me look this up, as I had it in my mind that only 1 person per company would be allowed in the RSC simultaneously.

[sjn]

Heya all!

I'm super happy that this topic is discussed, so I hope you don't mind if I offer some perspectives. I hope they can add something useful. :grin:

To me, there are a couple points worth keeping in mind when it comes to establishing a good governance model. Here are some that come to my mind (note, these are my opinions, please accept them as such :smile:)

1. When establishing a new governing body, we're not solving existing problems here and now. This is about preparing for those problems we don't expect and where the simple and obvious methods of solving have been tried and found lacking.
2. A good governance model is clear and understandable, and focuses on describing a conflict resolution process – How do we vote? – Who gets to vote? – How are complaints about the process handled? – What steps do we have to go through to ensure that the process is fair and gets it's due attention? – What's the final step in this process, and what steps lead to it? – What are there consequences if the process is ignored? – What are the consequences if the outcome/decision that comes out of the process is ignored? If answers to these questions aren't spelled out, we'll at least need some clarity about who gets to decide and how this happens.
3. A good governance model includes also instructions on how it can change itself as we gather experience about it. How do we change the process when it turns out wasn't good enough? How do we change or replace the constituents of the governing body?
4. And finally, the governance body & model makes an effort to ensure that different stakeholder groups are represented. Diversity leads to strength, and I think ensuring all stakeholder groups are represented is a good way to do that.

So a governance method or body doesn't exist to take away or replace well-working existing methods or bodies, but rather to offer a clear and understandable way to resolve issues when the existing ones fail us. Ideally, the governance body has nothing to do, because the other existing (primary) problem-solving processes.

I hope this is useful for the discussion. :smile:

[finanalyst]

@AlexDaniel, I do not know any of the history that Liz has discussed. But this interaction and the words you have used would indicate you are a person whose interpersonal skills are difficult to absorb. Having read your comments and reviews in the PRs, I am in awe of your abilities and deeply appreciative of your contributions to the Language. So please do not think I am trying to attack or criticise you. But objectively, your reactions do elicit a desire to step back and defend. It seems to me that your language and approach are those of a young person who sees everything as black and white, where if a person is not for something, then he is against. I do not know how old you are, but I was born in 1957. I do however completely sympathise with you, for I was such an individual as you some 30 years ago. It is my profound belief that you too will see in a few decades that using a different form of language, finding ways to agree with a person you want to persuade will in fact help you to change things far more efficiently than demanding a duel at dawn.

I think that my approach now to all contentious disagreements is expressed in terms of Boolean conjunctions. Modern society seems obsessed in describing all positions in terms of OR. Either this or that. I prefer to view conflicts of opinion in terms of AND. Both this suggestion AND that one too. And the intellectual challenge is to find a way to make both work.

As a matter of history, I too was against a name change, and I only changed my view when Larry aligned himself. So I really do understand the feelings you have just expressed. You can search the Perl6 mailing list to see my view point.

It is far better in the long run to have a collective decision-making body whose mandate is supported by the majority of active people in the Raku community.

[lizmat]

@AlexDaniel

I'm not talking about this new RSC thing.

You could at least try to speak about it with a little more respect. It is not just a "new thing". It is a serious attempt at moving the Raku community forward. The fact that it doesn't match your idea of how the Raku community should be moving forward, does not make it something you can dismiss or trivialise.

I'm asking you if you have figured out how language decisions can be made without jnthn, especially if we consider the amount of tickets in the problem-solving repo and how fast they're coming in. And if you think RSC is going to resolve that, please explain how.

Because, if push comes to shove, it will be a majority decision.

[finanalyst]

@lizmat I would be happy to serve on the proposed council. Do I put my name forward, or must the nomination be from someone else?

[lizmat]

@finanalyst

You can do that yourself by adding a file with your nick in https://github.com/Raku/Raku-Steering-Council/tree/main/nominations/2020 . There are some examples there already.

Consider your text there to be part of the email that will be sent to the voters, to describe why you would like to be elected.

[finanalyst]

@lizmat Done. Thank you for the encouragement

[AlexDaniel]

If you want to get personal then you can write my name instead of being vague. Turns out having an opinion that the project went into a wrong direction is “wanting to damage the project in any way they can”.

Oddly enough, it was not you who I had in mind.

Actually, it was about me (especially towards the end of the paragraph). Confirmed in a private conversation.

@finanalyst yes, I prefer direct language and clear terms instead of vague blabbering.

[AlexDaniel]

I think that my approach now to all contentious disagreements is expressed in terms of Boolean conjunctions. Modern society seems obsessed in describing all positions in terms of OR. Either this or that. I prefer to view conflicts of opinion in terms of AND. Both this suggestion AND that one too. And the intellectual challenge is to find a way to make both work.

You'd find a lot of support for that way of thinking here. Even the Raku rename at first was exactly that – Raku AND Perl 6. I personally no longer think like that, some solutions/opinions are objectively better than others, some are wrong or need more work, and some solutions cannot be applied together at the same time.

As a matter of history, I too was against a name change, and I only changed my view when Larry aligned himself.

I was against a name change. I changed my opinion when I realized that it'd be objectively better to change the name.

[JJ]

Just go ahead and put your name in a file in the repo, just like the others.

El jue., 30 jul. 2020 19:55, Richard Hainsworth notifications@github.com escribió:

@lizmat https://github.com/lizmat I would be happy to serve on the proposed council. Do I put my name forward, or must the nomination be from someone else?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Raku/Raku-Steering-Council/issues/17#issuecomment-666563638, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAD5C2KC3BEU54RENQPFDR6GXYLANCNFSM4PNJOIEQ .

[codesections]

Discussion in this issue seems to have lost focus and the issue has largely been superseded by events in the last ~3 months. Accordingly, I'm closing this, but please feel free to reopen it (or open a new issue) if you disagree.