Update Raku_Steering_Council_Code.md

[finanalyst]

The original document proposed here was copied with minor alterations, but contains excess words, unclear statements, poor grammar, and refers to concepts that are not defined. The original document was created - apparently - to deal with problems in another software community. Whilst copying is good, there is no need to copy obvious mistakes. There are changes I have made

• to remove unnecessary words and clarify grammar
• to clarify aspects of elections based on experience
• to change emotive language, such as expulsion, to more widely accepted electoral processes, such as recall votes. The processes described in the original proposal are confusing and would allow someone in the core group to demand constant recalls. Specifying when a recall can take place for a member of the Council or for the whole Council means a recall only happens for cause, not out of pique. When there is a generally perceived need for the whole council to be recalled, then something is truly wrong, so a new Council will be needed in any case, and the people demanding the change would probably want to be elected in their place.
• to add the Raku philosophy, basically be minimally editing Damian Conway's excellent response to issue #3.
• to add explicitly a Code of Conduct, based on the original text, responses in the issues. I have also explicitly included the Netiquette rules of Virginia Shea as they are widely quoted for internet interactions and cover almost all virtual interactions.
• I have added a power to the Council to declare some people Core development team. For example, I cannot imagine that Larry Wall, Damian Conway, Patrick Michaud (I think other names should be added that I haven't done) should ever be removed from the Core development team, even if they not longer make comits. The existing proposal would force such a change.

[lizmat]

Thank you for your PR. Since the whole issue around Standards of Conduct / Code of Conduct have been extensively discussed in https://github.com/Raku/problem-solving/issues/134 , with a stalled PR at https://github.com/Raku/problem-solving/pull/136 , I think the RSC should make it one of the first points of business to resolve that. Adding a CoC now just like that, will not be acceptable to a lot of people.

In light of the handling of CoC's in different conferences in the past year, this feels extra sensitive at the moment: having a certain CoC has been reason for people to not visit a conference, and the absence of a CoC has also been reason for people to not visit a conference. So this subject needs to be dealt with with the utmost of caution: just putting it in a PR will not work :-(

I will have a closer look at the other changes tomorrow.

[taboege]

Pierre Michaud

I think you mean Patrick Michaud -- just in case that bullet point would make it into the git log or similar.

[lizmat]

Ok, having read the PR now a little more in depth, and I generally like the changes.

Still I have an issues wrt to timing and mandate. I copied the Python one for a reason: that we won't have many discussions about it before the first election. And under which mandate should we allow changes to be made to the original proposal?

So I'm leaning towards keeping this PR alive, but actually make it an action point of the first elected RSC to actually change it. And this also goes for the CoC

[vrurg]

Is it possible to have this PR split in a few, focused on particular subjects? Because in the current monolithic form it's easy to get it buried in discussions. Whereas some bits could be accepted now and with no disagreement.

[finanalyst]

@vrurg I did think about that after I had submitted the PR. If you would suggest the parts that you think might be agreeable to a majority now, I would be happy to resubmit a number of PRs.

At the same time, I am aware of the force of Liz's idea, which is to start with a body that can take time and in small steps work on a larger document.

[vrurg]

At the same time, I am aware of the force of Liz's idea, which is to start with a body that can take time and in small steps work on a larger document.

Perhaps this is the best solution. The initial draft is good enough to start with.

With regard to splitting this PR into smaller ones – I can't even find enough spare time to eventually read it through. One thing where I definitely agree with Alex is that the philosophy section is better get extracted into a dedicated document.

[finanalyst]

Actually I like Alex's idea too. I was thinking of a Governance document more in line with a Raku program; essentially a fairly simple analog of a 'MAIN' with few title lines with minimal detail, and a bunch of "Module" analogs that are explicitly 'used' or made a part of the Governance document. eg

This is the overall Governance document. 

The following Documents are explicitly a part of this document, and contain relevant details:
ELECTIONS, STEERING COUNCIL, CORE DEVELOPMENT TEAM, RAKU USERS COMMUNITY, 
CODE OF CONDUCT, and RAKU PHILOSOPHY.

The Raku Language is developed and promoted by an elected Steering Council, an elected Core Development Team, and a Users Community.

Members of the Steering Committee, Core Development Team and Users Community are expected to abide by a Code of Conduct, and may be reminded of this if the Code is regularly breached.

The Raku Language was developed and is maintained according to the Raku Philosophy, except when it isn't, that is raku -ofun.