I really don't think the concept of "Do not repeatedly update an open issue remarking that the issue persists." works with something where issues could easily get buried, and especially if something breaks and doesn't have a fix for several versions (see Quake Champions' issue #225) - it used to work, then a game update broke Proton.
Correct me if I'm wrong here, but I though the whole point of having a issue tracker is to keep track of bugs. So by that definition things shouldn't get buried or forgotten. Things might take a long time to fix however.
If things are correctly labeled regression, I don't think the issue will be buried. But somebody with more insight than me is certainly welcome to correct me on this.
| Situation | Action |
|---|---|
| Newer Proton version breaks something. | New comment, mention: Regression. (Brownie points for also bisecting the bug). Somebody with the proper rights labels the issue: "Regression" |
| Newer Proton version fixes something. | Add new comment: bug fixed. |
| You found new and relevant information regarding a already filed bug. | Add new comment with your information. |
| Newer Proton version doesn't fix a already reported bug. | Wait. |
Quote from code of conduct Valve
As well, should your issue not be resolved immediately, it does not mean that a resolution is not being researched or tested. Patience is always appreciated.
Like I said in my original post for the feature request:
For what it's worth, if an issue has a regression I need confirmation of the known good and bad unmodified proton versions, preferably by the same user or at least enough that it's not a fluke or a system issue including video drivers before I add the regression label.
For what it's worth, last known good version of Proton, according to spcr.netlify.com, was 3.7-5, although there is reported discrepancy that the September game update (that occurred 9/6/2018) is to blame. Probably more worthwhile to continue that conversation over at the original issue, though, so we don't inadvertently spread it about.
@kisak-valve What is the preferred way to handle games that have have big yearly updates, but keep the same appid?
Do you stick to "one issue per unofficially supported game"? Do you make a new report, or edit the existing report?
Like Train Simulator (24010), that game has just updated from 2018 version to 2019 version within the same appid. I chose to edit my existing report for 24010, that seemed cleaner to me. The GitHub edit history for the issue contains the 2018 version anyways...
But I haven't heard a informal or official rule on this yet. :smile:
For the example, that looks like any other game update on steam. That particular dev has decided to adjust the marketing name to go along with the update and it's the same game as far as the Steam platform is concerned. No need to add more fine print.
@kisak-valve Okay, thanks for the clarification. I won't add more fine print to this issue about game-updates then. :+1:
@kisak-valve I've not seen any changes with regard to this feature request.
Is there anything I can do to help?
I could do either, or neither of the following:
Hi @kisak-valve :wave:
I wanted to check if this is still something that the Proton project cares about? There has been no change or movement on this issue since Oct 13, 2018. Maybe that indicates that I'm the only one that cares about this issue.
Will you accept a pull request from me that adds the creating a issue + adding to an issue guidelines to the README or Wiki?
If you don't want a contribution from me on this, and it's also not something that the Proton team is going to address, then I'd rather you just close the issue and mark it wont-fix. That way we're not cluttering up the issue list with issues that are not going to be fixed anyways.
Greetings,
HonkingGoose
Closing this issue, as there has been no movement on this whatsoever in more than 2.5 years. Feel free to re-open if this is something the Proton team does care about. 😉
Nothing extracted yet.
Feature Request
I confirm:
Description
I think that some general guidelines/standards would be helpful to all contributors here. So that the unwritten expectations are made explicit.
Also there are rules which are already enforced, but are not easily found.
Having a central place for these guidelines makes thing clearer for all involved.
To be very, very clear, I'm not talking about changing or adding to the code of conduct otherwise known as "how to be nice to people".
I've made a mock-up down below, so that you can see what kind of guidelines I'm thinking about.
Justification
Many first-time contributors (including me!) have "broken" one or more those guidelines. I see many labels: "opened this issue (their first in @Valve-Software)", or even "Their first issue on GitHub ever" where one or more of these guidelines are broken.
These people are making a good-faith effort to do the right thing, and inadvertently get it wrong.
I feel that being welcoming to contributors also involves making it easy to find the "right thing to do".
Risks
Current situation:
Rules already enforced, but not clearly listed
official name of game from steam store + (appid number)
official name of game from steam store + short description of issue + (appid number)
Rule already enforced, but mentioned elsewhere
This rule is listed in the valve code of conduct.
Suggested situation:
I think it might be helpful to have a section labeled "guidelines" in the README.md on the main Proton landing page. This can of course link to a page detailing those guidelines, as not to clutter up the main README.md
Mock-up:
Possible additional guidelines:
These are open for discussion, as there are not already official or unwritten rules. I just think they might be handy.
References
https://github.com/ValveSoftware/steam-for-linux#conduct
I found the Mozilla Bug Writing guidelines very helpful in figuring out how to write clear bug-reports, something like this could be helpful to reference too.
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines