Staff Complaint - Arrow768 (Forum/Git)

[alexpkeaton]

BYOND Key: alexpkeaton 

Staff BYOND Key: Arrow768

Game ID: N/A, this is about Forum/Github activity

Reason for complaint: Creates PR in response to Suggestions thread. In addition to implementing the OP's suggestion, adds a separate and significant gameplay change not addressed by the OP's suggestion in the same PR adding no explanation in the forum thread explaining their reasoning for adding that piece to the PR. 

Evidence/logs/etc:

https://github.com/Aurorastation/Aurora.3/pull/6768

Note that the PR references the change as "as suggested in (forum thread)" and while there is some debate over janitorial access in the thread, the OP did not advocate for a change to janitors in their original suggestion.

Additional remarks:

First, let me say that devs are the real heroes.  This is not to diminish that or the hard work @Arrow768 and the rest of the dev team does.  I do disagree with how this particular situation has been sold, however.

The thread posted by @Nantei was to discuss the merits of adding Paramedic general access to departments, a change I support.

While the bulk of the discussion focused on the Paramedic job, some contrast the merits of the Paramedic getting general access to departments with the janitor's (already having) general access.  I weigh in myself at one point referencing the janitor's access, asking about whether there is any risk in increasing the Paramedic's access in context of any potential antag/powergaming benefit it might afford (one the server would want to avoid if it exists).  I did not ask that because I was against the janitor's having that access.  I simply wanted to know more about the situation.

Arrow posts a link to a PR they wrote after the suggestion was posted, saying simply "PR is here (link)" on the suggestion thread.  And, while the PR does implement the OP's suggestion, it also strips the janitor of general access also, something the OP did not ask for.  In context of the full thread thus far, this wouldn't be considered "coming out of nowhere" but it was certainly buying in to comments in the thread that were within a hair's breadth of derailment of the discussion of the OP's suggestion.

I'm not against one PR doing more than one thing at once but these are two separate and relatively significant gameplay changes and Arrow made no comment about why they added the janitor bit or why they thought it was relevant to the forum suggestion at hand.  If we accept the PR implementing EMT basic access then we are being forced to swallow the poison pill for janitorial access.  Some might be okay with that, perhaps even Nantei.  However that is not the point.  Both changes represent relatively significant gameplay changes for their respective roles, deserving of separate discussions.  Community members browsing the suggestions list who play as Janitor and not Paramedic might never know that the thread titled "Give Paramedics General Access" is actually discussing the fate of janitors also.

I notice some commenters in the suggestions thread noting how the PR and/or forum thread has ballooned beyond Nantei's initial suggestion.  @tzeneth @Kaed

Because of the significance of both changes separately in terms of gameplay and to offer those interested in janitor gameplay the ability to weigh in, what I would think would be more appropriate in this case would be to make two separate PRs, one for increasing Paramedic access and another for removing janitor access.  Then a separate forum thread could be opened to discuss the merits of the latter because both represent significant and separate gameplay changes that are worthy of a clean debate without a discussion of one derailing discussion of the other.  To be honest, Nantei's thread has gotten so derailed by the addition of the janitor piece that perhaps some sort of pinned message could be added asking that further discussion should only focus on the Paramedic access piece and not janitorial.

To reiterate, thank you devs, thank you @Arrow768.  I just think this could be cleaned up a bit.

[Arrow768]

When implementing a pr not only the op is relevant but also the feedback provided in the topic. 

As I agree with the people that mentioned (in response to the op) that access creep is not a good idea I implemented the PR the way it is. 

The PR does not attempt to hide anything that it does and shows clearly what it will do and anyone clicking on the PR (or just looking at the rich link embed that should show the pr title) will see what it is doing. 

As shown by the discussion regarding the janitor access removal in the topic, quite a few people managed to click on that link.

To reiterate:

- I created a PR taking feedback from the suggestion and my personal opinion into account. 

- I linked the PR in the feedback topic so anyone who is interested in the paramedic changes can easily see it without checking github. 

- I linked the feedback topic on github, so feedback can easily be provided (which people are doing. 

So what exactly is staff complaint worthy about that?

[Skull132]

There is no requirement at all for a PR implementing a suggestion to restrain itself to only implementing the suggestion exactly as outlined in the suggestion. Suggestions are regularly unfeasible as presented, have balance issues, or in extreme cases, are pitched in a fashion that renders them all but unworkable. (Or maybe the coder just disagrees with the details and wishes to implement his own spin on the core idea. Doesn't necessarily have to be a practicality.) This is why the contributor or the developer considering a suggestion has total creative freedom to implement said suggestion as he/she wishes to, with whatever caveats he/she wishes to include. Ultimately, consider the suggestions forum to be a pool of ideas that coders can pick from.

For completeness sake, I will outline that posts on the projects forum are meant to represent a PR 1:1. But those threads are to be managed by the PR creator, and are usually created when the PR itself is not sufficient to facilitate feedback.

[Scheveningen]

22 minutes ago, Arrow768 said:

When implementing a pr not only the op is relevant but also the feedback provided in the topic. 

As I agree with the people that mentioned (in response to the op) that access creep is not a good idea I implemented the PR the way it is. 

The PR does not attempt to hide anything that it does and shows clearly what it will do and anyone clicking on the PR (or just looking at the rich link embed that should show the pr title) will see what it is doing. 

As shown by the discussion regarding the janitor access removal in the topic, quite a few people managed to click on that link.

To reiterate:

- I created a PR taking feedback from the suggestion and my personal opinion into account. 

- I linked the PR in the feedback topic so anyone who is interested in the paramedic changes can easily see it without checking github. 

- I linked the feedback topic on github, so feedback can easily be provided (which people are doing. 

So what exactly is staff complaint worthy about that?

I actually recall you asking me to make separate feedback threads for projects that are significantly different from the main OP of a suggestion thread. But that's pretty much the only goof I can think of.

[Nantei]

I want to say while I appreciate people coming to my defense, I do not mind Arrow's PR being discussed there. It was relevant even if it wasn't my desired change, since it was being discussed there.

[Arrow768]

4 minutes ago, Scheveningen said:

I actually recall you asking me to make separate feedback threads for projects that are significantly different from the main OP of a suggestion thread. But that's pretty much the only goof I can think of.

Well yes, but the pr is not significantly different. 

The paramedic changes have been suggested by the op. 

The janitor changes have been suggested by someone in reply to the op. 

[Scheveningen]

For the sake of transparency, should PRs link only to their respective project threads to ensure information is accurate and transparent in regards to what the PR contains, considering what was mentioned by Skull?

Quote

There is no requirement at all for a PR implementing a suggestion to restrain itself to only implementing the suggestion exactly as outlined in the suggestion. Suggestions are regularly unfeasible as presented, have balance issues, or in extreme cases, are pitched in a fashion that renders them all but unworkable. (Or maybe the coder just disagrees with the details and wishes to implement his own spin on the core idea. Doesn't necessarily have to be a practicality.) This is why the contributor or the developer considering a suggestion has total creative freedom to implement said suggestion as he/she wishes to, with whatever caveats he/she wishes to include. Ultimately, consider the suggestions forum to be a pool of ideas that coders can pick from.

Ensuring information stays 1:1 helps discussion stay on track in regards to discussing active attempts to make changes, since there was apparently immense confusion by people who apparently didn't read the commits on github in a thread recently.

[Skull132]

25 minutes ago, Scheveningen said:

For the sake of transparency, should PRs link only to their respective project threads to ensure information is accurate and transparent in regards to what the PR contains, considering what was mentioned by Skull? 

No. Where is the inaccuracy you're attempting to gnaw at? Where is the lack of transparency you're attempting to gnaw at? The PR's description outlines clear as day what it does. The link is there to let the people involved in the initial suggestion that an interpretation of their idea is being considered for merging.

Project threads are not a requirement unless flagged for (generally) major PRs, since they require a retarded amount of work ontop of a decent amount of work already.

There is a very sound solution to this complaint, if what is happening now is too complex for people to understand: Arrow removes the link to the suggestion thread, deletes his comment in the suggestion thread linking the PR, and the PR will now be a novel idea to be interpreted on Github. Can you see the issue here?

[alexpkeaton]

 

2 hours ago, Arrow768 said:

So what exactly is staff complaint worthy about that?

I think "complaint" is too harsh to describe my feelings here.  Consider it a discussion with a request for action.  Unfortunately the "staff complaint" forum appeared to be the most appropriate place for this discussion.  With that in mind, I feel this discussion is valid is because I think there is something that could be done better here.  To be clear, while I think there is a wrong here that can be righted, I do not at all believe it was intentional or malicious.  I just think there could be some added transparency and a more robust discussion.

I started typing this for a forum reply but did not want to derail the discussion with a sentiment irrelevant to the topic at hand.

Some other thoughts I wish to underline:

- Significant and/or controversial gameplay change deserve forum threads to encourage discussion.  No, I don't believe that is happening here for the janitor.  Not transparently.

-There is no way a janitor main player or someone with an interest outside of paramedic play might know that janitor access was being discussed in the topic, based upon its title.

-At the absolute least, perhaps a one sentence description in the forum thread reconciling the OP's suggestion to the PR you propose.  Something like "this PR implements general access for Paramedics while removing access for janitors." 

-As you have made an addition, and because you are a highly respected and experienced player/contributor in the community, I know I personally would have been interested in your thoughts on the matter, why you think janitors should lose their access.  You have made an addition to what the OP asked for, I think it is worthwhile to explain the reasoning behind the addition.

2 hours ago, Arrow768 said:

As shown by the discussion regarding the janitor access removal in the topic, quite a few people managed to click on that link.

-I believe this shows that there is a robust discussion to be had regarding Paramedic as well as Janitor access.  People do come out with strong views on both sides of the janitor access issue within the forum thread.  Still others are confused why janitor access is even being discussed (perhaps not realizing the PR affects the janitor also). 

For transparency, I just think there should be a clearly labeled forum thread which can act as a road sign to those who might be interested in participating in the discussion.

42 minutes ago, Skull132 said:

Where is the lack of transparency you're attempting to gnaw at? The PR's description outlines clear as day what it does. The link is there to let the people involved in the initial suggestion that an interpretation of their idea is being considered for merging.

I hope my response outlines the transparency issue, at least as I see it.  I know what has happened has caused a bit of confusion even within the suggestion thread.  Setting aside the notion of bringing an additional forum thread for janitors into play, some clarity in the suggestion thread by Arrow might have helped the discussion to progress a little more cleanly.

Perhaps here's a resolution to my concern: an admin edit to the suggestion title adding "removing janitor general access" and a sticky posted in the thread saying something like "Hey the OP originally discussed paramedic general access to departments but there were some strong views raised about janitors having general access. A PR is on the table providing Paramedics general access and removing janitors having general access.  See (link).  We're combining the discussion of these gameplay changes in this thread.  Please comment on these changes here and/or on github if you have thoughts relevant to the discussion."

Edited July 24, 2019 by alexpkeaton
Changed one word for clarity.

[Scheveningen]

2 hours ago, Skull132 said:

There is a very sound solution to this complaint, if what is happening now is too complex for people to understand: Arrow removes the link to the suggestion thread, deletes his comment in the suggestion thread linking the PR, and the PR will now be a novel idea to be interpreted on Github. Can you see the issue here?

I'm glad you demonstrated a wrong answer on purpose (and pretend that's what I want as a resolution) so as to push the idea that the flawed status quo is the only alternative. It is not. Your argument is full of straw. There is a way to resolve this without anyone receiving warnings of any kind or anyone being forced into making decisions that make no sense. 

This is an example of a thread, here --:

-- that was created because of some heated discussion that happened earlier in this thread:
 

Unlike anyone else in that suggestions thread (this isn't a slight or attempt at insulting anyone who participated in that discussion, just a statement of fact), I went ahead with my own implementation in my own vision. And then I posted a projects thread linking the PR in its description.

The project thread links to the PR and the PR links to the project thread. The information given is 1:1, there is no inconsistency. It's that simple. Make PR, propose commits, ask for reviews, post projects thread on forum, ensure the PR and the thread link to each other. It's not a complicated process to follow - in fact this process is what I was told by @Arrow768 themselves to do in the past.

--

The situation I outlined above contrasts with what Arrow took action for. The mistake on his part was not posting a project thread of his adaptation of a proposal (it's irrelevant if someone else suggested it in the thread), but rather a mistake in not using the projects subforum for its intended purpose. This isn't intended to be a slight against Arrow as a staffmember or anything. He made a mistake, and mistakes should be corrected for the future.

Edited July 24, 2019 by Scheveningen

[Skull132]

@Scheveningen Congratulations. That's exactly what I proposed when I said he could remove the links between the two items. PRs do not require project threads unless actually mandated for feedback purposes. Your own handling of a similar situation, though perhaps commendable, does not define what are and are not rules. There have been countless cases where PRs implementing a suggestion have deviated from the original suggestion, have not been large enough to require project threads (again, they are costly to maintain to the creator), and have been linked just fine to the original suggestion. The only differentiating factor here roughly being that people do not necessarily enjoy the proposed changes here.

And in general. No policy violation has taken place. "This is not a complaint but a discussion," is grounds to have the complaint closed, which is what I will be doing now. If you want to discuss something, use General Discussion. If you want to propose new policy, use Policy Suggestion. Complaints are for instances of staff violating existent policy. This is due in no small part to the rules surrounding the complaint forum, where opinion-posting by opinionated people is a ban-worthy offense: because opinions are not the point of this forum, "Should have done so to be nice", is not the point of this forum. "Broke policy" is.

To reiterate:

• The current policy is that a PR only requires a Projects thread if dictated by a member of the development staff. No such dictation has yet been made, so no policy has been violated by Arrow.
  • And this decision can only be called into question once a PR has been merged or a Head Developer clearly objects to the idea of requiring a feedback thread for a specific PR. I would lose my mind if we got a staff complaint for every PR which hasn't gotten a feedback thread request after 1 to 3 days of sitting.
• There is no requirement nor policy to implement a suggestion as posted 1:1, as such, no policy has been violated by Arrow.
• Since the PR does relate to the suggestion thread, linking it is courteous to indicate that, "Hey, (an iteration of) this idea is being considered for implementation. Go review here.

Complaint dismissed. All reasonable actions to undertake with respects to this issue have been outlined in the three paragraphs above.

[Skull132]

Double posting but also re: transparency. Yes there are requirements to PR descriptions and reasoning, all of that falls under the purview of the Head Developers, ultimately. Which means that the Head Developers will inquire about a PR when they see issues and/or have decided that a PR's reasoning or description are lacking.