Brainstorming: Ideas to improve mod quality by helping users to more easily identify and report issues

[Lurker]

- disclaimers begin here -

Thoughts  regarding release philosophy, as usually intended as constructive suggestions with only the best of intentions.

Also, I'm neither a native English speaker nor am I 100% acquainted with GitHub terminology, and have only very limited experience with using version control software or how to properly manage software development and release cycles, so please consider this if I may slip by improper use of terminology or language.

Also, I'm reasonably(?) aware of the issues that are implied by mixing up the following terms (<-- fucking need for disclaimers these days   ) : game modding - hobby - spare time - scratching own itches(*) - quality assurance/maintenance - additional effort/time constraints - players - wishful thinking.(**)

In the end, if someone is passionate enough to spent so much of their time over a so long amount of, well, err, time, improving one's methods can be unpleasant at first, but beneficial in the long run. Perhaps it even helps to save time.

- disclaimers end here -

 

My personal premise: I prefer using "official" releases (in GitHub terms), because they imply a certain amount of quality (which might be my own personal problem for believing so), and I usually don't setup a game intended for beta testing, but for "consuming".

Bugs reported against a release sometimes get fixed very quickly, but then stay "hidden" in master. Which can be fine, because let's face it, constantly reinstalling and breaking game saves isn't fun in the long run, but could also end up in reporting bugs that are already fixed, but elsewhere. Users currently committed to a new setup could profit from fixes much sooner. But master also usually(?) gets new, and therefore untested features, and with some mods, using master is more or less actively discouraged, while others might only live in master and never push out a release at all.

So, while expecting a community wide established best practice from hobbyists isn't very reasonable, I really believe in an absolute minimum of of responsibility, that everyone should have when providing more or less anything publically, regardless of commercially/"professionally" (<-- often not the best examples to follow, really) or hobbyist. I'd say in this case, it would be a tiny, but explicit disclaimer (again, sorry) in how the project is organized and what to expect from it. Random list of things, like:

• use only master
• use only tagged releases
• where and how to provide feedback
• a notice like "take it or leave it, but don't bother me, and don't complain if it breaks your car"
  • yes, I really think even this is perfectly valid, as long as it's clearly communicated
• calling out for testing a specific branch, with explicit mentioning of either
  • please test in a dedicated installation
  • please test compatibility with mod xyz
• leaving out fluffy text like "This is properly coded, so will work together with everything else thanks to WeiDU magic."
  • slightly exaggerated statement above, but I more than once was led to believe that, really, then reality hit like a truck

Having different branches might also be helpful, if one is good with merging patches and the likes. For (larger) projects that release only infrequently, and especially those that have fixing issues as part of their primary scope, providing smaller, "stable" bugfix-only releases would be a great deal. Mixing up quality improvements and new features in master can end up in a lot of mental pressure, I believe. And if one really is interested in user adoption, this should really help, if only by reducing the number of cases like "Eh, I tried this once, caused problems, will never touch again.".

Also, I guess a thing that often happens in software development, especially the more creative minded people to me often are like "I want to do cool and new stuff, my old stuff is now boring to me." Okay, but again, please communicate that attitude. For some users, it would be a great loss to not experience what comes out of such creative minds. But people that perhaps think a bit more like myself, while willingly committing to help improving quality of freely provided and therefore used pieces of software, might have "that one, personally customized, feature complete and never again changing anymore" setup in mind, achievable ideally before hell froze over.

This can be translated to: "I don't care about your cool new feature, I want things just to work." Or: "I'm not interested in testing new stuff, because I'm committed to get my setup stable." Or: "I'm finally accustomed to the shortcomings of my setup and know to work around them. Don't want to introduce new breakages."

So, what I wrote above to catch the "slow releasers", the same really applies to the people with a lot of "steam", that are pushing out new releases very quickly. Please don't wonder why other people won't jump train and always try to catch up with you; some of us just don't have that energy.

Eh, I guess this rant with the usual mix of mixed intentions shall be enough for now.

Thanks for reading.

 

(*) I do this myself, and don't even provide a GitHub repo, so feel free to think about me as a hypocrite, if that helps
(**) perhaps I should put this disclaimers somewhere and link to it by default where applicable...
(***) how realistic is it these days to hope for people reading longer texts?
(****) constructive feedback about how to better "abuse" this forum as a blog or issue tracker is welcome

Edited November 3, 2023 by Lurker

[DavidW]

1 hour ago, Lurker said:

For (larger) projects that release only infrequently, and especially those that have fixing issues as part of their primary scope, providing smaller, "stable" bugfix-only releases would be a great deal. Mixing up quality improvements and new features in master can end up in a lot of mental pressure, I believe.

Just on this: in principle I think it would be a good idea but it's difficult to manage in terms of workflow on hobbyist projects. My own workflow is

1) release version N

2) relatively rapidly release new bugfix only N.1, N.2,... fixing any serious bugs that are quickly identified by users

3) develop features for version N+1

4) work through bug reports that have come up while I was developing N+1

5) release version N+1

Of course in principle one could manage these processes separately but I think it requires a lot more version control, code modularity, QA, etc, than tends to be realistic in modding.

[Lurker]

Something that anybody (hint: users help users) can do who's willing to help to improve the general quality of this site: Cross linking! Comment updating!

There's so much useful information buried in this forum (being optimistic here for a change - but have no proof, because cannot find it ), but it can be hard to dig up. Otoh, outdated information hurts people that aren't in a situation to validate what's still valid and good advice, and what's more like "broscience" or simply outdated.