Closed AlexDaniel closed 4 years ago
It is not the intention to get rid of the problem-solving repo, afaik.
With the Raku Steering Council we hope to make it easier to get to a decision made whenever the decision making process in the problem-solving repo has stalled. And not pile everything on Jonathan.
Regarding renaming the repo: will Github automatically create redirects from the old repo name?
Yeah, it creates redirects.
But this:
Since there is also no formal voting process installed yet, the voting for the first elected Raku Steering Council will be done by email.
Hmmmmmm… Interesting. I don't want to assume that this is intentional gaslighting, but it's a bit hard to interpret it any other way.
With the Raku Steering Council we hope to make it easier to get to a decision made whenever the decision making process in the problem-solving repo has stalled. And not pile everything on Jonathan.
Well, then just assign more people to specific topics in the problem-solving repo, what's the problem? You don't need two repos. If you want to have the documents that you uploaded here to have any meaning for let's say the language
label in the problem-solving repo, then just upload them there and say that the rules apply for that label.
Repo renamed.
also no formal voting process
The voting process in problem solving repo is public and it does not allow selecting 5 people each with a value of 1..5.
then just assign more people to specific topics in the problem-solving repo
The authority to assign issues to people, needs to be formally founded. This is what we're doing now.
The authority to assign issues to people, needs to be formally founded. This is what we're doing now.
What? Anyone can just submit a pull request adding themselves, if nobody minds then it happens.
We already had this discussion before, and jnthn was against it:
jnthn: I'm fully supportive of @vrurg being on the reviewers list. I'm not so keen on the language tag being shared.
Now I'm even more confused. Can somebody summarize what's going on?
So, thinking a bit more about what's going on here. The problem-solving repo requires anyone to define the problem first, and then people can come up with solutions and discuss them. There was a very annoying problem in the past – people appearing with their awesome solutions (like with PRs to rakudo/rakudo), without any clarity on what they actually tried to solve in the first place. But here you are taking a step back it seems, you intentionally worked around the process, and now it's completely unclear what you're trying to do.
As for the “7-person committee”, there is already a list, so we can guess how it's going to look. Those are the ones who volunteered themselves to be relatively passive parts for decision making in the Raku project. It's 13 people, but some of them are no longer active (like me), so it's pretty close to 7 people, give or take (but mostly take). This makes me wonder, if only 13 people decided to add themselves to the problem-solving repo (and stay), what are your expectations of a 7-person list?
@AlexDaniel I think your confusion stems from a belief that the Raku Steering Council exists entirely to replace or subvert the problem-solving repo. Which is not at all the case. Part of its job is to better handle the problem-solving repo, but looking at Raku_Steering_Council_Code.md (specifically the bullet points under Mandate, Powers, and Membership) shows it's meant to do much more than that.
From what I gather, the point of RSC in terms of problem-solving is to provide a more formal process for giving people authority to make decisions on tickets than just "submit a pull request saying you want in" (which IMO feels a bit too disorganized for my tastes; the default-accepted behavior in particular requires everyone who might want to object to a new member to keep an eye out on the problem-solving repo for specific "add me" tickets, as opposed to something like being sent a specific "we're gonna vote on a new team member" email).
As I gather from the proposal, the point of the problem-solving repo and how it functions will be unchanged. The only change to the process would, by my reckoning, not be real changes, but instead just clarifying how people with authority should approach their decision making. And I hardly think changing how people come to their decisions on tickets counts as much of a change to the basic process of submitting problems and working on them.
Also,
Since there is also no formal voting process installed yet, the voting for the first elected Raku Steering Council will be done by email.
Hmmmmmm… Interesting. I don't want to assume that this is intentional gaslighting, but it's a bit hard to interpret it any other way.
Gaslighting? Where? Please explain more clearly where you think gaslighting is taking place, since that, in my book, is a serious accusation to level against someone, especially when it's so unclear as in this case.
As I gather from the proposal, the point of the problem-solving repo and how it functions will be unchanged
OK, so problem-solving repo remains unchanged? Can somebody confirm? If not, please describe the changes.
@ShimmerFairy unfortunately, I can't really answer your long comment. On IRC you said that I don't understand how problem-solving repo works even though I created it, and then followed by describing the process incorrectly. But I do agree though that I didn't describe it very clearly in the README, so I can't really blame you.
The problem-solving repo will remain the main place where suggestions are made for solving problems. To quote:
The council has broad authority, which they seek to exercise as rarely as possible; instead, they use this power to establish standard processes.
The problem-solving repo is one of those processes already established.
We've seen in the past that having a BDFL has its pros and its cons. When Patrick Michaud silently left the Raku project because of personal circumstances, Jonathan effectively became project leader. When Larry became more and more invisible, Jonathan effectively became the Language Architect as well. The problem-solving repo was one way of trying to solve that.
The problem-solving repo ensured that there was a place where people could put their problems, or even solutions in the hope for a resolution. But the resolution part is still ill-defined, or perhaps better stated: ill-maintained. There are many issues out there of which it is not clear whether the voting period has started or ended, and nobody has taken the authority to close issues if they've effectively exceeded their voting period and should be denied.
I think the reason is that ultimately, we're all looking at Jonathan to make a final decision. And Jonathan is a rare resource that we should not stress to their limits. Having a Raku Steering Council, one can force a decision to be made by asking the RSC to decide.
Furthermore, the Raku Steering Council will be forced to have regular meetings to decide on matters it has been asked to decide on. This will allow the people in the council to also be able to work on forming ideas about future goals, if necessary. Something that has happened in the past in the Hallway Tracks of conferences, but in this era of Covid-19 will not happen as frequently, if at all anymore.
Also, although the problem-solving repo was "community approved", I don't think we actually let "the community at large" approve it. As Stefan pointed out in IRC yesterday, we should actually let all the people with a commit bit in roast also give the passive and active voting rights. That is another reason why I think a formal election is a good way to ensure the core team approves of the direction we're taking Raku now.
Finally, we need more structure in the project, so that the Raku project will be able to continue without any of its current members, and not devolve into chaos. That's if we want Raku to become the 100-year language. Which at least I know I do!
From my perspective, problem-solving
has helped organize the bottom-up, but - being centered on individual problems - hasn't really managed to take on the things that more naturally happen top-down. I see the steering council as trying to provide a bit of structure there.
While we point to the rename as being a success of the problem-solving
repo, and I don't dispute that it played a critical role, in reality the rename issue only appeared there after an amount of behind-the-scenes back and forth, and it was messy and unstructured because it ultimately boiled down to an individual having to figure out a coalition to build around it.
It's a bit similar with language design/development. The problem-solving
is a good way of knowing what problems exist and, when we're lucky, getting ideas about solutions, but there's no way we can focus on everything at once, so there has to be a prioritization. At some level this will boil down to "what are contributors willing to work on". But in reality, there's a rather small number of people who currently know the whole stack well enough to do the really big things, or have a good idea of what we might be able to get done in what vague timeline, or can spot the overarching solutions that address a bunch of problems together. For example, I kinda decided that the headline feature of the next major language version will be RakuAST and the things it enables, and that along the way we'd get a compiler frontend refactor to take on (and set the stage for dealing with) various other problems, but I did that largely alone, figuring it'd give enough people what they wanted that there'd be a decent amount of support. I did get to discuss it with various core team members on the sidelines of the GPRW in spring, at which point the thinking was quite well developed, but probably it would have made sense to discuss this strategic-level thing a bit earlier. Again, this is something that happened (and such decision making will need to happen again in the future), but it was unstructured, and ultimately also messy in that the "if we're doing this, then a bunch of other things will have to wait" wasn't every really conveyed or shared and that led to its own tensions too. That's my failing, but as has been pointed out plenty of times, I'm overcommitted.
Hopefully, the steering council will fill in some of the gaps that problem-solving
hasn't, and ultimately, probably cant naturally be made do.
@AlexDaniel I am upset and disheartened that you have once again decided that the only way you can respond to my comment is to ignore it entirely and to accuse me of acting disingenuously (this time, that I'm only here to spew bullshit). I'm struggling to understand what part of my comment is bullshit; the closest match I can come up with is my misunderstanding of problem-solving's process, but you admit to this misunderstanding being at least partially your fault (so... you didn't give me the correct information and now you don't have the energy to correct me? That can't be right.). And in any case, I can't figure out how a genuine misunderstanding could be considered "bullshitting".
For the record, me accusing AlexDaniel of not understanding the repo they themself created was because, in the moment of the IRC discussion, it was the only conclusion I could come to, as strange as it seemed. When I explained my understanding of RSC's effect on problem-solving as "like it always has been, except that who gets the final say on tickets is determined differently", their response was to be confused as to what I meant. I assumed that the "except" part was sensible, so therefore the confusion laid in the "like it always has been" part, which means the confusion lies with how the repo currently works.
I now see that the more likely explanations are that the "except" part really wasn't as clear as I thought it was, and this didn't come through to me, or that there was a specific edge case or conflict in putting the two parts of my statement together that you wanted clarity on but didn't express specifically (leaving me confused as to your source of confusion).
One final note, by ignoring my comment you ignored my question about the gaslighting accusation. I really want to know how to interpret what lizmat said as possibly indicating gaslighting, but if you continue to avoid the question then I'll have to believe it's because you have no reason to make such a claim and just did so in bad faith. And that's a conclusion I'd really rather not walk away with, because I can't fathom why you or anyone would do that.
@AlexDaniel, @ShimmerFairy please, try to keep up with the topic and avoid being too personal. Thank you!
@AlexDaniel with regard to our IRC conversation, I think you now have the answers. The idea has resonated to me mostly because I saw the need to structure the things up. Where you consider problem-solving as the ultimate solution, I see an anarchic place which is really great as a think tank but mostly weak at taking decisions.
I have no idea why @ShimmerFairy 's comment was marked as disruptive. Can the person who did that please undo that?
I have no idea why @ShimmerFairy 's comment was marked as disruptive. Can the person who did that please undo that?
Seems to be undone already? To be clear, I didn't do it.
I've done it as I consider the personalized exchange of "opinions" between @AlexDaniel and @ShimmerFairy off-topic and abusive. Actually, I was hiding Alex's comment too but somehow it's unhidden now. Though my opinion remain the same: Alex link to Brandolini's law was inappropriate and over-emotional as the whole "discussion" is.
Ok, if it's only my point of view, I'm unhiding the comment.
Actually, I wasn't trying to say that @ShimmerFairy is saying bullshit. Just that it's a yet another time when they leave very massive comments that are, in my opinion, wrong in many ways. I just can't write an even larger comment describing why they are wrong, and at least in this case I don't think it'll get us far anyway, so I won't be engaging and that was the short description on why.
If you would know anything about public relations, then you would know that saying:
Actually, I wasn't trying to say that @ShimmerFairy is saying bullshit.
is going to be interpreted as just that: that @ShimmerFairy was saying bullshit.
The rest of the comment appears to imply that you do know how that works.
This may be seen as off-topic for the ticket at hand, but there's no better place to respond at the moment.
To say the least, I'm not happy that my comment trying to push back on accusations of malevolent behavior gets marked as disruptive while those very accusations get to stay up unhidden. And I don't see how my "disruptive" comment counts as off-topic; the bulk of it elaborates on the earlier-referenced IRC discussions about the topic of this ticket.
In particular, I find being accused of behaving abusively incredibly heinous and would like it retracted. I will gladly admit to not keeping my posts entirely emotion-free, but that's because I find it hard to avoid letting any emotion bleed through when I'm being flat-out ignored and brushed aside. If I failed to keep all the vitriol and snideness from appearing in my "disruptive" comment like I thought I did, then I'm sorry and will try harder in the future.
Finally, I'm seriously reconsidering my decision to come back to the Raku community. Not because some people disagree with me, but because some people keep refusing to discuss issues with me when we disagree. If all my attempts to contribute to the language are met with those attempts being completely ignored, why, seriously, should I bother trying? I think I will at least wait until the RSC exists, so that if things don't improve by then I can try and resolve the issue through their channels before choosing to leave. I know it would be a drastic move, but I really don't enjoy the idea of spending my free time in a community that only upsets me.
To say the least, I'm not happy that my comment trying to push back on accusations of malevolent behavior gets marked as disruptive while those very accusations get to stay up unhidden. And I don't see how my "disruptive" comment counts as off-topic; the bulk of it elaborates on the earlier-referenced IRC discussions about the topic of this ticket.
@ShimmerFairy you probably missed my notion of both Alex's and your comments was initially hidden. No idea what went wrong and why the first one ended up unhidden, but from my side there was nothing personal or picky. I did not like where the discussion headed and wanted to cancel it ASAP. No more, no less.
With regard to the comments being mostly about earlier IRC discussion, I'd say that from my point of view both of you went somewhat beyond just discussion.
Hopefully, I made myself clear on this. Being an emotional and even sometimes over-emotional person I know how easy is it to explode. It took me decades of experience to learn that "expressive" language never results in anything good in online disputes. Therefore I'm rather sensitive to any signs of potential escalation.
Also, please, do not make one person equal to the whole community.
Otherwise I hope we won't be getting back to this "sub-topic" again.
The questions raised in this issue have largely been resolved in the last few months: The RSC has been established but is not a replacement for the problem-solving repo. Given that, I'm closing this issue.
🤨
So I'm reading the documents in this repo, and maybe it's just that I'm too much out of the loop, but this repo is just making things more confusing than they already are.
Here's the thing, the problem-solving repo was designed to be self-sufficient. In fact, the process itself was bootstrapped using … well, the same process. It is also designed to be malleable, you can tweak it to serve any purpose, as long as others don't mind.
Now, this repo (which I suggest to be renamed to “raku-steering-council”, because Raku has enough abbreviations already) is adding another layer on top, and moreover seems to do it by hacking around the problem-solving repo. That's fine to me, but what is happening? xD
You don't need two repos. If you want to get rid of the problem-solving repo, then do it. If not, then this repo has no need. I understand that it's easier to just add more things on top (not surprised at all here, btw), but I recommend not to.