Make all development channels visible on the discord

[Bmon]

I have noticed a massive decrease in communication and transparency on the github ever since PR voting has been split into different design teams. It's to a point where I myself no longer want to contribute to this server as it is a massive morale zap to see your PR closed with little to no communication from the different teams.

I think it'd be productive to see exactly why and how the different teams are voting on PRs the way they are. There's no reason for our PR review process to be private, we are an open-source codebase.

Do note the differences between visible and public. I am calling for all development channels to be made visible meaning that anyone can read them but not talk in them.

Edited March 15, 2023 by Bmon
typo

[henri215]

I am not sure if making the development channels would help that much.

What i am sure of is that PRs being closed with no obvious reasoning (its different than lets say a PR with lots of comments and discussions where it would be clear why that one objection happened) DO inflict a massive morale zap on contributors.

I would KILL for an reasoning about the banana cream pie (zero comments on the PR, zero discussion over discord by people in general), is it because we dont want effects that could be annoying? The sound chosen by the author was not good enough? Is it a worry that it could somehow be abused to annoyance because it would make cream pie launcher have an actual impact? Why should i add sounds to any items if i am not even sure why a similar PR got denied?!

Our human resources are limited and will stay that way if we keep losing people because of avoidable frustrations.

Edited March 15, 2023 by henri215

[Gatchapod]

Making the channels visible sounds like a poor idea. While I do believe our contributors are mature enough to simply accept decisions of the respective teams, I am less confident in non-contributors. I can very easily see random people championing PRs they like in DMs of relevant team members instead of on GitHub. I'd rather avoid sending overly upset people at anyone.

Henri's idea would increase the workload of the teams, but probably not by a whole lot.
We all know and love the anecdote of "yeah, no" being the whole input from maintainers before a PR was veto'd. While the teams alleviated many issues, this kind of pops up as one from time to time.
Ideally, I think, the team that ended up objecting to a PR should leave a brief comment on the PR. Nothing exhaustive, but just enough to not leave people confused. Maybe I'm just stupid and it's somehow obvious, but admittedly sometimes I don't even know which team objected to a specific PR.

[Bmon]

If someone is going out of their way to harass a maintainer for voting a certain way then they should be banned, simple as that. Being able to see why the X design team voted the way they did and their thought process behind that would lead to a greater understanding of what went wrong.

Right now we get nothing but a blank yes or no which in the case of the latter is nothing more than an absolute insult to said contributor as you are talking about potentially hours of someone's free time being flushed down the drain with no explanation. I don't see any downsides to making the channels visible, most counterarguments honestly feel like a strawman of 'somebody' 'potentially' harassing the maintainers when the obvious answer to that is to just ban people who do that.

Also, this adds zero extra strain on the development team, they don't need to come out with a statement every time a PR is closed or merged, you could just look at the respective design channel and figure it out yourself.

Many other servers already have their development channels visible and I think we would clear up a lot of frustrations by following in their footsteps.

[Spacemanspark]

2 hours ago, Bmon said:

If someone is going out of their way to harass a maintainer for voting a certain way then they should be banned, simple as that

Banning someone does not prevent them from being a toxic twat in the first place. You cannot solve every administrative issue by playing whack-a-mole, and burnout is a very really concern when it comes to being a part of any SS13 community staff team. I've always been fully on board with having development team communication with PRs, but I dont think opening their chats to the public solves the issue you've made note of. A simple comment on a closed PR doesn't take terribly long to write up (in most cases) and goes miles in alleviating a lot of anger some might have (in most cases).

[AffectedArc07]

Right before I even go into the actual meat of this post I want to explain how the voting system actually works just to clear up any confusionwith it.

---

Internally, we have a tracking system for each PR which can have approvals or objections, under the category of design or balance. These objections can only be applied by the relevant teams (IE - Someone in balance team cant throw a design objection on a PR). The PR type depends on the votes needed (99% of them need the design team, Balance PRs need the balance team obviously). If you are a member of both teams and a PR needs both votes, you only get one.

It is not compulsory for a PR to get everyone to vote on it, if that was the case we would be here forever, hence why its on a majority system. However, if a PR has no approvals and only a singular objection, we tend to leave it open until expiration date (30 days) and nag people internally for votes just to make sure they havnt missed it.

It is a common occurance for someone's thoughts on a PR to be indifferent, as in they dont have it enough to object, but dont really approve of it, its just "meh" to them, hence no vote. A PR can go without approval but not have objections either.

 

I should point out all of this is outlined on https://paradisestation.org/dev/policy/

---

Now for the post itself.

6 hours ago, Bmon said:

I have noticed a massive decrease in communication and transparency on the github ever since PR voting has been split into different design teams.

This is absolutely incorrect. The split into teams has bought on more people who are actually willing to write objections out onto PRs instead of hitting a button behind the scenes and not caring. If you take a before

And an after

I really dont see the argument here

 

 

6 hours ago, Bmon said:

There's no reason for our PR review process to be private, we are an open-source codebase.

When you wake up to 3 death threats (no this is not hyperbole) and nagging over the most minute of objections, you will see why sometimes we keep quiet about objections, especially if the PR is likely to get you absolutely slated for it. I also want to cite this from the GitHub code of conduct, specifically the first sentence.

It is also worth nothing we do ask people from the teams to try state their issues more

 

 

7 hours ago, Bmon said:

Do note the differences between visible and public. I am calling for all development channels to be made visible meaning that anyone can read them but not talk in them.

The PR tracker could potentially be opened up, but that will be a lot of tape crossing and policy changes. However, the internal development chat will never be opened up, purely because:

• Exploit discussion
• Discussion on disciplinary action on other GitHub contributors
• We really dont need the frothing masses berating us when we even think slightly about a possible rework

 

---

TLDR - The system itself isn't flawed and people did use to state objections, theres just been a dropoff of it with burnout among other things, and we are working on it. 

[Bmon]

1 hour ago, Spacemanspark said:

Banning someone does not prevent them from being a toxic twat in the first place. You cannot solve every administrative issue by playing whack-a-mole, and burnout is a very really concern when it comes to being a part of any SS13 community staff team. I've always been fully on board with having development team communication with PRs, but I dont think opening their chats to the public solves the issue you've made note of. A simple comment on a closed PR doesn't take terribly long to write up (in most cases) and goes miles in alleviating a lot of anger some might have (in most cases).

I agree that something like that constantly happening could lead to burnout but I just don't think many people would go out of their way to harass the maintainer team for voting on PRs. In my own personal experience, it's the PR creator who gets most of the heat for an unpopular PR that gets merged.

I guess what I am getting at here is wanting to understand why maintainers voted the way they did and how that could be useful for understanding what should be changed in the future. An explanation could do this but most of them are rather brief and usually don't give the full picture

 

[S34N]

I massively agree that votes should be public information. I've benefited from seeing who's voted and been able to approach them to see what they'd like changed for a PR to be merged. Rarely it's "no I dont see this working at all", often it leads to changes and a merged PR.

If someone harasses a voter on a subject, it's easy for us to take action against them. We don't want genuine harrassment in our community. Sadly the word "harassed" has been used in the past as a catch-all for people disagreeing with others in DMs, this isn't really harassment it's just creative differences. But we can take action against genuine problem people.

The private dev channel is not some secret cabal of balance discussion. It happens sometimes but most of the time it's people pinging others regarding reviews and neeing to vote, people discussing explots that have been reported (this is very common as we have a lot of currently reported exploits), and charlie shittalking about banning everyone who disagrees with him. I don't think that being open for viewing would achieve anything apart from hinder discussion on genuinely private topics.

[Bmon]

38 minutes ago, AffectedArc07 said:

This is absolutely incorrect. The split into teams has bought on more people who are actually willing to write objections out onto PRs instead of hitting a button behind the scenes and not caring. If you take a before

And an after

I really dont see the argument here

I understand how the Paradise development team works so I am just going to skip over that part.

I don't know why you're cherry-picking examples, I could do the same with more recent PRs to try to prove a point, there will always be outliers. I made this thread because I noticed it was happening more now than it was before.

And I am not even touching on the fact that a lot of the times there are only one or two people are voting. In your own example, only one person voted on that PR out of a team of five. The least the design teams could do is to take five or ten minutes to look at a PR and say yes, no or abstain. Before at least the whole team was getting together to vote on PRs which lead to discussion, this has all but stopped in recent times and has led to an overall decline in communication.

44 minutes ago, AffectedArc07 said:

When you wake up to 3 death threats (no this is not hyperbole) and nagging over the most minute of objections, you will see why sometimes we keep quiet about objections, especially if the PR is likely to get you absolutely slated for it. I also want to cite this from the GitHub code of conduct, specifically the first sentence.

Moving on I really do hope whoever is making death threats over 2d spaceman game gets swiftly banned. I do understand where you're coming from though, especially with that example, I think special circumstances could lead to a PR being voted on privately but I do not believe it should be the norm. Regardless it is not good practice to be closing PRs with no explanation, it pushes contributors away from wanting to contribute to this codebase.

45 minutes ago, AffectedArc07 said:

It is also worth nothing we do ask people from the teams to try state their issues more

And yeah, sometimes we do get explanations but again it is my own opinion that this has been in decline.

45 minutes ago, AffectedArc07 said:

The PR tracker could potentially be opened up, but that will be a lot of tape crossing and policy changes. However, the internal development chat will never be opened up, purely because:

• Exploit discussion
• Discussion on disciplinary action on other GitHub contributors
• We really dont need the frothing masses berating us when we even think slightly about a possible rework

Your bullet points do prove that some things should stay private but I am still of the opinion that the greater development channel should be visible. Most of these things could be moved into separate private channels. I don't think many people will be down your neck for merging X PR. Again, it is my experience that the contributor usually gets most of the flak for an unpopular PR being merged.

[Miraviel]

I'd rather not make any developer more of a target than they are now. The loud minority of the SS13 community is unfathomably toxic. I have been a developer on another server where I constantly got angry as hell PMs for my opinion on major reworks and features that I publicly stated. I was told to kill myself more often as a developer than a moderator.

I know for a fact our maintainers have unsavoury people in their DMs as well.

2 hours ago, Spacemanspark said:

Banning someone does not prevent them from being a toxic twat in the first place. You cannot solve every administrative issue by playing whack-a-mole, and burnout is a very really concern when it comes to being a part of any SS13 community staff team.

This 100%. We can keep banning people, it does not undo the damage of maintainers waking up to literal death threats over a stupid pixel game.

We had Discord servers grouping up and harassing developers/maintainers when things did not go their way.

 

Most PRs that get rejected have a very clear reason stated on it. Some only get a "people voted against it, so closing it". It is not perfect, but the devteam handles 20+ PRs a day. In comparison, the company I work at handles about 10 PRs a day, and we are here 8 hours a day for an actual salary. The unfortunate truth is that you cannot expect them to be perfect and professional with each PR, even if it sucks to be on the receiving end. (I know, I have been on the "silently closing" side).

Best thing you can do is to ping the closing maintainer and ask for help if they forgot to state a reason. I doubt anyone would turn you away if you asked for constructive criticism.

Edited March 15, 2023 by Miraviel

[Spacemanspark]

56 minutes ago, Bmon said:

but I just don't think many people would go out of their way to harass the maintainer team for voting on PRs.

I have seen enough people do exactly this, many times over. There is a reason why the Paradise maintainer team has (or at least at one point had) a reputation for being in a sort of turtle shell, and it's exactly because people constantly went after them. The PR creator also definitely gets flak too, of course--but they aren't the ones with the power to add their proposed feature into the game (or refuse to). 

I am 100% all for communication, but you do need to look both ways before crossing the road here. It's a two way street, and I would take burnout into serious consideration when making these sorts of suggestions. 

[Bmon]

6 minutes ago, Spacemanspark said:

I have seen enough people do exactly this, many times over. There is a reason why the Paradise maintainer team has (or at least at one point had) a reputation for being in a sort of turtle shell, and it's exactly because people constantly went after them. The PR creator also definitely gets flak too, of course--but they aren't the ones with the power to add their proposed feature into the game (or refuse to). 

I am 100% all for communication, but you do need to look both ways before crossing the road here. It's a two way street, and I would take burnout into serious consideration when making these sorts of suggestions. 

I am sure it has happened, I am not at all dismissing that. I just believe that it is more detrimental for us to be closed off than it is to be open with our development decisions.

[Spacemanspark]

I would argue that the mental health of volunteers for a 2D sprite game has more cause for consideration--and detriment for the community at large when poorly addressed--than being completely open about every decision. The current system as Arc has pointed out appears to work well in this regard, if how they explain it is true. Much better than what came before it, at the least. 

Edited March 15, 2023 by Spacemanspark
Me sleepy, me not write good

[Bmon]

3 hours ago, Spacemanspark said:

The current system as Arc has pointed out appears to work well in this regard, if how they explain it is true. Much better than what came before it, at the least. 

It's a perspective thing. If you compared the development cycle from uhh idk around 2017 when I first started playing, of course, things are better now. I am just noticing things slipping back, it's hard to see that happen considering the strides in progress that have been made lately on the development side of things.

I am always going to be a pro-transparency purest, that's just who I am and what I believe in. Some wise old man would probably tell you and me that the solution lies somewhere in the middle.

[DwaneLoki]

I just want to give my two cents on the matter. From the outside, I think this is all a matter of trust, what do we trust more? The integrity of every single member in our large community? or, the scrutiny of our hand-picked developers who, as far as I'm personally concerned haven't let us down to any major capacity in recent memory. I think the solution is already in the works, the attention this Post has generated in the past hours certainly has the attention many significant people of this community. The message is clear, better communication is wanted in one forum or another. I have confidence this will be addressed in a satisfactory way for both parties, allowing for clearer communication and maintaining the privacy and security of the people who work so hard to make our community as unique and healthy as it is.

[Warriorstar]

full disclosure, i am an (extraordinarily inconsequential) member of the dev team. despite this, and being in the private dev channel, i *also* don't see the vote tracker, so publicizing the private dev channel (specifically, distinct from the vote tracker) wouldn't change the result whatsoever, because not every decision is made in a town hall setting complete with peanut gallery, nor should they, nor can they.

for my part--without retreading the existing (salient) dicussion points regarding admin energy/burnout/harassment; that not everyone *should* be a part of every conversation, even as an observer; and that 99.9% of the time the "problem" is just that maintainers have lives and are busy and things fall between the cracks, which won't change if decision-making is publicized--i think:

to say "right now we get nothing but a yes or no", followed by affected and charlie posting PR comments that are *not* just a yes or no, followed by saying "i don't know why you're cherry picking examples", and then "sometimes we do get explanations but" is self-defeating. if your argument is "right now we get nothing but a yes or no", and the response is direct, objective, contradictory evidence, it's hard to take the assertion seriously. if the argument is that this is a slowly aggregating trend, then you need a trend *line*. in other words, specific, objective data showing the difference between how many PRs have been closed with no explanation between the previous dev policy and now.

people's feelings and impressions about the situation aren't going to cut it (especially the kinds of comments that start with "it just seems that"), especially since contributors tend to place disproportionately high emotional value on their PRs, either because of the time spent, the emotional investment in the community, the perceived quality/value of the implementation, the hope for the desired outcome, or the jarring nature of normally having one's PRs accepted only to have one specific one denied. admins are not responsible for anticipating and shaping the emotional reaction of contributors. the dev team already walks on eggshells to try and work against this. the policy shouldn't be tailor-made to optimize against emotional blowback from contributors.

i've lost track of the number of times i've heard that transparency in decisions like this is _ipso facto_ better than opacity but the impetus for this discussion seems to be that the lack of transparency discourages contributors. there are already plenty of venues and opportunities for contributors to get blessing to work on something: in a design doc, in a github discussion, in the discord. putting names to decisions only gives contributors ammunition against individuals, which is precisely why things are the way they are now. never explaining decisions discourages contributors. always publicizing decisions discourages the dev team. that's why we have two phases to the process, the public decision making venues, and the final say the dev team has. i think there's a belief that if this level of transparency is enacted people will suddenly discover their PRs are being denied for nefarious, petty reasons, and not just what it is now, which is things fall through the cracks, the dev team is busy, miscommunication happens.

the vote against on the banana cream pie sound effect PR is an individual instance of a PR denial by a member of the admin team for no stated reason, which was allowed *before the new dev team structure and policies*. is not an indictment of the current dev policy writ large, or a microcosm of the behavior of all of the dev team. the failure to share an explanation here is a *mistake*, not an enforcement of the new policies, and considering we are all fallible humans adapting to a new organizational structure, things like this are bound to happen. in other words (or the same words as above, which apparently require incessant repetition): maintainers have lives, are busy, and things fall through the cracks. if this was allowed under the old dev team structure/policies, then asking for the old dev team structure/policies back will make this happen _more_. like, the thing you want back is the thing that caused the thing you don't want to occur.

and if the PR author *is* discouraged, there are already venues for the PR author to request clarification in cases like this. they can ping the team in discord; they can DM the admin who closed the PR; they can post a thread; they can reply on the PR since closing a PR does not lock the comment thread, that's a separate action; they can even (but i'd save this for the most egregious cases) file an admin complaint on the forums, after all, voting against a PR is an admin action.

ultimately, by being a contributor, you're placing trust in the admin team to maintain the trajectory of the game and community. the admin team already goes above and beyond in terms of organizational transparency: you know the name of every admin member, mentors and admins are selected on an evidentiary basis with an application process and standards team members are expected to uphold; every ban appeal is publicized, every admin complaint is publicized, affected not only provides public profiling and round stat APIs, they also bust their ass every year to put together a state of the server sharing all the salient highlights of codebase and production development; the entire development team policy is public, and i can guarantee that there are no dev team members who don't uphold themselves to those policies.

the dev team channel isn't private because we have something to hide; it's because there needs to be a place where lightweight, informal conversation can occur without input from a peanut gallery or disproportionate hysteria in response to non-binding or casual discussions of the game without firm conclusions before official decisions are made and properly communicated to the community, and there needs to be a way for individual admins to perform their functions without worrying about emotionally overinvested gamers keeping excel spreadsheets of all the times they feel they've been wronged, personally and deeply, by Admin Alice or Headcoder Harry.

[Miraviel]

I took 15 minutes to look at some data just to ensure we are not holding this discussion based on emotions and I-feel-likes, because this topic is leading to nowhere.

 

Since 12 January, 300 PRs were handled of which 40 got closed. At maximum, 11 of those got rejected visibly on GitHub, of which 4 did not get a written reply as to why.

This is a solid 100 PR / month with a little over 1 getting rejected without an explanation on GitHub (not counting the possible discussion between the PR opener and the maintainers on Discord).

 

PR closed/abandoned by their author for personal/technical reasons or they made an alternative PR (28):

    https://github.com/ParadiseSS13/Paradise/pull/20417
    https://github.com/ParadiseSS13/Paradise/pull/20400
    https://github.com/ParadiseSS13/Paradise/pull/20378
    https://github.com/ParadiseSS13/Paradise/pull/20377
    https://github.com/ParadiseSS13/Paradise/pull/20374
    https://github.com/ParadiseSS13/Paradise/pull/20373
    https://github.com/ParadiseSS13/Paradise/pull/20365
    https://github.com/ParadiseSS13/Paradise/pull/20364
    https://github.com/ParadiseSS13/Paradise/pull/20358
    https://github.com/ParadiseSS13/Paradise/pull/20355
    https://github.com/ParadiseSS13/Paradise/pull/20338
    https://github.com/ParadiseSS13/Paradise/pull/20318
    https://github.com/ParadiseSS13/Paradise/pull/20317
    https://github.com/ParadiseSS13/Paradise/pull/20316
    https://github.com/ParadiseSS13/Paradise/pull/20296
    https://github.com/ParadiseSS13/Paradise/pull/20292
    https://github.com/ParadiseSS13/Paradise/pull/20647
    https://github.com/ParadiseSS13/Paradise/pull/20633
    https://github.com/ParadiseSS13/Paradise/pull/20624
    https://github.com/ParadiseSS13/Paradise/pull/20557
    https://github.com/ParadiseSS13/Paradise/pull/20555
    https://github.com/ParadiseSS13/Paradise/pull/20510
    https://github.com/ParadiseSS13/Paradise/pull/20475
    https://github.com/ParadiseSS13/Paradise/pull/20446
   https://github.com/ParadiseSS13/Paradise/pull/20269
   https://github.com/ParadiseSS13/Paradise/pull/20212
   https://github.com/ParadiseSS13/Paradise/pull/20210
   https://github.com/ParadiseSS13/Paradise/pull/20186

PR closed by maintainers stating the reason on the PR (5):

    https://github.com/ParadiseSS13/Paradise/pull/20406
    https://github.com/ParadiseSS13/Paradise/pull/20357
    https://github.com/ParadiseSS13/Paradise/pull/20272
   https://github.com/ParadiseSS13/Paradise/pull/20235
   https://github.com/ParadiseSS13/Paradise/pull/20202

PR closed by maintainers without stating a reason on the PR (4):

    https://github.com/ParadiseSS13/Paradise/pull/20396
    https://github.com/ParadiseSS13/Paradise/pull/20386
    https://github.com/ParadiseSS13/Paradise/pull/20382
   https://github.com/ParadiseSS13/Paradise/pull/20205

Either dev objection on Discord or personal, could not decide (1):

    https://github.com/ParadiseSS13/Paradise/pull/20370

Dev objection on Discord, not stated on the PR (2):

    https://github.com/ParadiseSS13/Paradise/pull/20509
   https://github.com/ParadiseSS13/Paradise/pull/20178

[Generaldonothing]

33 minutes ago, Miraviel said:

Either dev objection on Discord or personal, could not decide (1):

    https://github.com/ParadiseSS13/Paradise/pull/20370

Personal reasons for closing this BTW, I decided I could do better with it

[Bmon]

2 hours ago, Miraviel said:

PR closed by maintainers without stating a reason on the PR (4):

    https://github.com/ParadiseSS13/Paradise/pull/20396
    https://github.com/ParadiseSS13/Paradise/pull/20386
    https://github.com/ParadiseSS13/Paradise/pull/20382
   https://github.com/ParadiseSS13/Paradise/pull/20205

You definitely missed a few there.

[MattTheFicus]

2 hours ago, Bmon said:

You definitely missed a few there.

You are free to put in the time to find them yourself, then.

[Bmon]

6 hours ago, MattTheFicus said:

You are free to put in the time to find them yourself, then.

I can only speak from my own experience so these are my PRs.

https://github.com/ParadiseSS13/Paradise/pull/19836

https://github.com/ParadiseSS13/Paradise/pull/20096

https://github.com/ParadiseSS13/Paradise/pull/20115

All these never got a why.

PRs being closed by the author are irrelevant. Don't know why Miraviel decided to list them.

[S34N]

2 hours ago, Bmon said:

I can only speak from my own experience so these are my PRs.

https://github.com/ParadiseSS13/Paradise/pull/19836

https://github.com/ParadiseSS13/Paradise/pull/20096

https://github.com/ParadiseSS13/Paradise/pull/20115

All these never got a why.

PRs being closed by the author are irrelevant. Don't know why Miraviel decided to list them.

I mean literally the last one you linked has a comment explaining why just before the PR was closed.

Mira's PR dataset is clearly stated as being PRs opened from after January 14th (With one being opened late on the 13th), so the first and second ones in your list do not fall within the timeframe.

[henri215]

I dont think there is a trend, just a few mistakes here and there.

#20205 - That is a case where reasoning on closing isnt necessary since the PR itself had enough discussion and it was easy to see why would a member vote against it.

#20396 - Venuska PR has been open for multiple months because of conflicts and for decisions to decrease the size of it. This is one where reasoning on closing would be necessary specially because its a newer contributor that really needs that feedback, and considering the bad description about the changes the PR had and the lack of votes for/agaisnt, my imagination can only think that it was ignored until the time limit was hit without anyone asking for it to be more clear for a vote to be cast.

#20386 - One could imagine some reasons why would one object to this (i can imagine like..three? no idea which one could be it), even though a reasoning would be necessary for clarity and for future PRs that might be similar. When making something new i always look into the past and if i found this i would be wondering "It was closed because we dont like some spawning with free food?" or "Is it because it would be too much of a meme?", i would be confused, and i am.

#20382 - No idea, could use a reasoning.

Bmon PRs:

#20096 - I have no idea what the objection on this could be and considering its a PR that changes an entire map..is it really something he couldnt change? Reasoning necessary on that one.

#19836 - Considering its 100% a sprite change i dont think a reason has to be stated, if it was closed its because the team considers that the current sprite is better than the alternative. Maybe if we had a sprite team and art guidelines further clarification on why it doesnt fit, in some case, could be given, but we dont have such things.

#20115 - The PR had enough discussion about it and you were told that the preference is over the alternative, i think its clear that the reason it got denied is probably among the arguments given by the multiple comments it had.

Edited March 16, 2023 by henri215

[Bmon]

1 hour ago, S34N said:

I mean literally the last one you linked has a comment explaining why just before the PR was closed.

Saying they prefer another PR but not stating why is not an explanation.

1 hour ago, S34N said:

Mira's PR dataset is clearly stated as being PRs opened from after January 14th (With one being opened late on the 13th), so the first and second ones in your list do not fall within the timeframe.

I don't think a single day really changes my point much. I picked those examples based on the day they got judged by the design teams.

Also, why are we trying to fit these into an arbitrary timeframe?

Edited March 16, 2023 by Bmon
formatting

[henri215]

22 minutes ago, Bmon said:

Saying they prefer another PR but not stating why is not an explanation.

I don't think a single day really changes my point much. I picked those examples based on the day they got judged by the design teams.

Also, why are we trying to fit these into an arbitrary timeframe?

Collect it with a larger timeframe then, Mira did a quick 15 minutes search.