Were our bug reports and suggestions even useful?

Discussions about UT99
User avatar
PrinceOfFunky
Godlike
Posts: 1154
Joined: Mon Aug 31, 2015 10:31 pm

Were our bug reports and suggestions even useful?

Post by PrinceOfFunky » Tue Sep 22, 2020 10:54 pm

Well, pretty disappointed to be honest. I just read the GitHub page for the UT v469 patch and noticed that the ut99.org community hasn't been mentioned at all in the credits or special thanks, so my questions are - Were our bug reports and feature suggestions even useful? You were the ones starting multiple topics to ask us support, so I strongly doubt you forgot about it.
"Your stuff is known to be buggy and unfinished/not properly tested"

ShaiHulud
Adept
Posts: 381
Joined: Sat Dec 22, 2012 6:37 am

Re: Were our bug reports and suggestions even useful?

Post by ShaiHulud » Wed Sep 23, 2020 1:50 am

I'm sure that they have been, AnthraX and Higor both interacted with the feedback thread, so I've no doubt they took onboard what contributors had to say, and I think it was valuable to have had a place for people to get involved in the discussion about it (props to everyone who reported issues). The thread will certainly stand as a testament to all of those who felt impassioned about making the new release as good as it could be.

I've still overawed that this project happened at all, it's really uplifting to see people come together for a common purpose when there's no grand reward at the end, other than the satisfaction of a job well done.

User avatar
sektor2111
Godlike
Posts: 4892
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Were our bug reports and suggestions even useful?

Post by sektor2111 » Wed Sep 23, 2020 6:56 am

I think some of them were in account except those making a mess a la UTPG and causing a total incompatibility for old players coming back due to some dumb new ideas which majority don't need only those unable to write their codes properly or having butterflies in their brain.

User avatar
anth
Skilled
Posts: 235
Joined: Thu May 13, 2010 2:23 am

Re: Were our bug reports and suggestions even useful?

Post by anth » Wed Sep 23, 2020 5:17 pm

I'm not sure if my answer will help, but here goes: the bug reports we got from this forum were helpful, but not as helpful as we had hoped for. Contrary to other forums where 469 was discussed at length, the thread here quickly got flooded with extremely toxic reactions. That said, we did fix several of the bugs you reported, and we still have open tickets for another 10 or so of your bug reports. The total number of unresolved issues is at around 200-250 right now.

The people we thanked in the README all put a *substantial* amount of time into actively and constructively contributing to our project. If there is anyone here who fits that description, and who is not already mentioned in the README, then I sincerely apologize. Please send me a PM, and I'll be glad to amend the README.

User avatar
esnesi
Masterful
Posts: 708
Joined: Mon Aug 31, 2015 12:58 pm
Personal rank: Dialed in.

Re: Were our bug reports and suggestions even useful?

Post by esnesi » Wed Sep 23, 2020 8:42 pm

i would say Buggie because of making those 888 threads.
Image
- --Discord

User avatar
PrinceOfFunky
Godlike
Posts: 1154
Joined: Mon Aug 31, 2015 10:31 pm

Re: Were our bug reports and suggestions even useful?

Post by PrinceOfFunky » Wed Sep 23, 2020 8:57 pm

anth wrote:
Wed Sep 23, 2020 5:17 pm
I'm not sure if my answer will help, but here goes: the bug reports we got from this forum were helpful, but not as helpful as we had hoped for. Contrary to other forums where 469 was discussed at length, the thread here quickly got flooded with extremely toxic reactions. That said, we did fix several of the bugs you reported, and we still have open tickets for another 10 or so of your bug reports. The total number of unresolved issues is at around 200-250 right now.

The people we thanked in the README all put a *substantial* amount of time into actively and constructively contributing to our project. If there is anyone here who fits that description, and who is not already mentioned in the README, then I sincerely apologize. Please send me a PM, and I'll be glad to amend the README.
Do you mean that since the topics posted here were too toxic you stopped reading them? I would think that's understandable, but then, why did you let us continue to post on those topics? Why didn't you tell us that the topics were becoming too toxic to read? And if you weren't reading them anymore, why was Chamberly still answering to the replies?

Nobody told us to put a "substantial" amount of time into actively and constructively contributing to our project. You were the dev team for a reason, you had your bug reporters.
How comes that some of the features suggested in those topics were implemented and some bugs fixed if you didn't read them? Were those topics toxic enough to avoid thanking us but not toxic enough to implement the features we suggested and bugs we reported?
"Your stuff is known to be buggy and unfinished/not properly tested"

User avatar
Barbie
Godlike
Posts: 1969
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: Were our bug reports and suggestions even useful?

Post by Barbie » Wed Sep 23, 2020 9:50 pm

PrinceOfFunky wrote:
Wed Sep 23, 2020 8:57 pm
why did you let us continue to post on those topics?
Consider that they are not paid for their effort and are doing that in their spare time. They are not obligated to anything.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett

User avatar
PrinceOfFunky
Godlike
Posts: 1154
Joined: Mon Aug 31, 2015 10:31 pm

Re: Were our bug reports and suggestions even useful?

Post by PrinceOfFunky » Wed Sep 23, 2020 10:59 pm

Barbie wrote:
Wed Sep 23, 2020 9:50 pm
PrinceOfFunky wrote:
Wed Sep 23, 2020 8:57 pm
why did you let us continue to post on those topics?
Consider that they are not paid for their effort and are doing that in their spare time. They are not obligated to anything.
Nobody ever said they had the duty to. We didn't have the duty to give them suggestions or bug reports either but yet we did.
"Your stuff is known to be buggy and unfinished/not properly tested"

User avatar
Feralidragon
Godlike
Posts: 5250
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Were our bug reports and suggestions even useful?

Post by Feralidragon » Wed Sep 23, 2020 11:49 pm

Well, I did say a while ago in that very topic that they weren't actively looking anymore at that topic, and why, and that after release I was going to post a link to an actual bug tracker (Github).

Having that said however, Anth did look times to times like he said, and this wasn't the only community he checked times to times, there were countless others since many people actually come from different communities, and aren't really active or have even an account here, and for all intents and purposes the dev team HQ was OldUnreal, not ut99.org.

Keeping track of all of that, especially that thread, proved to be impossible, so he started to rely more on other people to report to him directly in Discord or OldUnreal, or even write up issues in Github directly (for those who had access to do so).

That topic was a huge mess, and a lot of the "reports" were just unreasonable feature requests disguised as such, most which weren't motivated by what the community wanted as a whole, but rather what the person actually wanted for him/herself, and were often written with such a level of laziness that (pretty much one-liners per request/report, no detail whatsoever), that they were pretty much useless.

Chamberly also mentioned several times, here and in Discord that for more specific bug reports, to go to OldUnreal and report them there in more detail, and even to become a tester, therefore people actually interested in putting in the work into testing and reporting had ample opportunity to do so at any given time, and testers were being added all the time into the closed beta.

And please do not put the development of a patch and bug reporting at the same level of effort, because they're not, they're worlds apart on the effort-metter.

Mostly Anth and Higor were the ones doing all the heavy lifting by actually developing the patch in their free time, which translated to lots and lots of hours every week of constant coding, figuring problems out, battling the frustration that it is working with legacy code in legacy systems and trying to make it work with newer ones, having to deal with new problems which weren't there before, etc, etc.

So if you're trying to imply that you're as much part of the team or the project because you reported a few things: you're wrong.
Bug reports and such are undoubtedly very important for a project to become better and more polished over time, but they are extremely easy to do and contribute with, there's almost no effort attached to suggesting or reporting things, in comparison with the actual development.

I have spent some time over all these months in writing some detailed bug reports, even developing some code to easily reproduce some specific test cases, discussing a few things in discord with them (sometimes at length), and I even managed to put together a potential detailed technical specification on how to deal with new UnrealScript features in future patches without breaking compatibility with 436 at all (as a mere suggestion)... and yet, that's absolutely nothing at all compared with the effort these guys are putting in it, working on it almost every day.

Almost every day they are discussing about something concerning a problem to be fixed somewhere, it's quite amazing to watch.

So do a bit of introspection, and ask yourself if what you're asking and doing with this thread is actually fair.

That is to say that rather than looking at credits, maybe you should be a bit more appreciative that a patch did in fact come out as promised and that they're still working on it on their free time to fix the remaining issues, when they could just drop it and do something else.

User avatar
PrinceOfFunky
Godlike
Posts: 1154
Joined: Mon Aug 31, 2015 10:31 pm

Re: Were our bug reports and suggestions even useful?

Post by PrinceOfFunky » Thu Sep 24, 2020 3:11 am

Feralidragon wrote:
Wed Sep 23, 2020 11:49 pm
That topic was a huge mess, and a lot of the "reports" were just unreasonable feature requests disguised as such, most which weren't motivated by what the community wanted as a whole, but rather what the person actually wanted for him/herself, and were often written with such a level of laziness that (pretty much one-liners per request/report, no detail whatsoever), that they were pretty much useless.
I don't think any of us knew that you wanted detailed information. What detailed information does a bug report or feature suggestion need?
For example, what detailed information does "Give write access to dynamic arrays" need? Or "The progress messages disappear when the voice menu is open".
Feralidragon wrote:
Wed Sep 23, 2020 11:49 pm
And please do not put the development of a patch and bug reporting at the same level of effort, because they're not, they're worlds apart on the effort-metter.

Mostly Anth and Higor were the ones doing all the heavy lifting by actually developing the patch in their free time, which translated to lots and lots of hours every week of constant coding, figuring problems out, battling the frustration that it is working with legacy code in legacy systems and trying to make it work with newer ones, having to deal with new problems which weren't there before, etc, etc.

So if you're trying to imply that you're as much part of the team or the project because you reported a few things: you're wrong.
Bug reports and such are undoubtedly very important for a project to become better and more polished over time, but they are extremely easy to do and contribute with, there's almost no effort attached to suggesting or reporting things, in comparison with the actual development.

I have spent some time over all these months in writing some detailed bug reports, even developing some code to easily reproduce some specific test cases, discussing a few things in discord with them (sometimes at length), and I even managed to put together a potential detailed technical specification on how to deal with new UnrealScript features in future patches without breaking compatibility with 436 at all (as a mere suggestion)... and yet, that's absolutely nothing at all compared with the effort these guys are putting in it, working on it almost every day.

Almost every day they are discussing about something concerning a problem to be fixed somewhere, it's quite amazing to watch.

So do a bit of introspection, and ask yourself if what you're asking and doing with this thread is actually fair.

That is to say that rather than looking at credits, maybe you should be a bit more appreciative that a patch did in fact come out as promised and that they're still working on it on their free time to fix the remaining issues, when they could just drop it and do something else.
I never said that reporting bugs requires the same effort of fixing those bugs, why would I even say it?
I'm not asking for anything, not sure what you were supposing, But you know, now I see you didn't mention oldunreal community either who I heard helped "more" (for whatever it means) than this community, so I guess you just wanted to thanks the ones who actively debugged or developed.
Anyway not everyone wants to register to new forums, we've had some users here who didn't want to do that, so that's why some from here couldn't help debugging I guess.

I never said I'm not thankful for the new patch, reward or not I suppose you did a good job.
"Your stuff is known to be buggy and unfinished/not properly tested"

User avatar
Feralidragon
Godlike
Posts: 5250
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Were our bug reports and suggestions even useful?

Post by Feralidragon » Thu Sep 24, 2020 12:12 pm

PrinceOfFunky wrote:
Thu Sep 24, 2020 3:11 am
I never said that reporting bugs requires the same effort of fixing those bugs, why would I even say it?
You didn't say it directly, but you heavily implied it with this:
PrinceOfFunky wrote:
Wed Sep 23, 2020 10:59 pm
Barbie wrote:
Wed Sep 23, 2020 9:50 pm
PrinceOfFunky wrote:
Wed Sep 23, 2020 8:57 pm
why did you let us continue to post on those topics?
Consider that they are not paid for their effort and are doing that in their spare time. They are not obligated to anything.
Nobody ever said they had the duty to. We didn't have the duty to give them suggestions or bug reports either but yet we did.
... so let's not play games with each other here.

------------
PrinceOfFunky wrote:
Thu Sep 24, 2020 3:11 am
I don't think any of us knew that you wanted detailed information. What detailed information does a bug report or feature suggestion need?
For example, what detailed information does "Give write access to dynamic arrays" need? Or "The progress messages disappear when the voice menu is open".
If you're really asking that using those specific examples, then you really have no right to complain about anything at all, that doesn't even qualify as a report or any type of meaningful contribution.
If you know just enough about programming to ask something like "Give write access to dynamic arrays", but then fail to provide more detail about this request, then you really have no excuse here.

Having that said, allow me then to clarify what "detailed information" means in these cases, mostly so that others in the same boat as you understand what we mean, so that if you and others do choose to contribute in a meaningful manner, do so the right way.

Bug reports:
Whenever you're reporting any bug or problem, you should provide as much info as possible to reproduce it, and also describe what should really happen.
You should use as much material as you can to convey the problem as clearly as possible, the most useful way possible in order for the developer to be able to reproduce it himself, and be able to confirm a potential fix or be able to properly explain why it can't be fixed (in cases where it's not doable to do so).

By material, I mean everything from a good detailed description of the problem (steps to reproduce it), to logs (in the case of crashes), to images and videos (in cases where the problem is seen visually), to even download links for the packages and configurations involved if applicable.

Ideally, if at all possible, a person should also provide the minimum reproducible test case for the developer to reproduce it and fully confirm the fix.
In the case of a mapping problem, this would translate to a small map clearly showing the problem.
In the case of a scripting problem, this would translate to a small piece of code, or even working mutator that the developer can execute to see exactly what happens.

To give you a few examples of mine:
  • movers had bugs concerning both static and dynamic lighting (and still do to some extent, hasn't been fixed completely), so I created a simple test map with movers, the simplest thing you can imagine, to show the problem;
  • one of the renderers had a bug in rendering something, so I opened a bug report with a description on how to reproduce it, which packages were involved and 2 screenshots, one showing the problem, and another showing how it should actually look;
  • the new audio drivers also had (and still have) a few bugs of their own, so I created very simple mutators where the developers could simply load them up, write "mutate <whatever>" to trigger the issue to check (and hear in this case) the issue by themselves.
As you can probably tell by now, this means doing much of the required homework first on the problem as possible, and only then report it with the full info you gathered.
The more info is included in a bug report, the less time a developer has to spend in figuring it out and fixing it, which is good for the community to get fixes quicker, and it's also good for them so they're able to solve issues quicker and get some more free time to themselves to just relax without stressing out on the size of their backlog of a project they have committed to.

Picking your example of "The progress messages disappear when the voice menu is open", you would need to describe the exact steps to reproduce this, ideally with screenshots or a video to show off the problem, maybe even trying different renderers from the start to check if the problem only happens with a specific renderer or is engine-wide, and so on, otherwise the developers may wonder what exactly you even mean with this, may try to reproduce it and being unable to, since it will not be as obvious to them as it may be obvious to you in your local environment, because the scope of what they have to worry about and the used terminology about the game, is not the same as the players, mappers and modders actually playing and developing for the game, so you need to be as clear as possible to make their life simpler.

Very often they're so worried about the lower level stuff, that they become unaware of the higher level stuff people generally deal with, so reports need to be clear so they can easily map the higher level problems to the lower level technical details surrounding them.


Feature requests:
These work very similarly as bug reports, except that they should require proportionally more effort to create as what the feature itself entails.

Namely, if you want a very minor feature, it probably only requires a smaller description and materials to illustrate it.
But if you want a big feature, then you need to put proportionally more effort in fully describing, in your own opinion, how it should work.

Unlike a bug report, this may actually mean writing almost a full essay about a feature if its scope is wide enough.

Furthermore, the bigger the feature is, the more properly justified and defended it has to be.
By this I mean that you should always provide a reason why the new feature is important, by providing an explanation, practical use cases, maybe even using examples from other engines and platforms that implemented said features and their impact.

It should also provide some additional details on how compatible with previous versions the new feature is, what it may break, and so on, although it will depend on the kind of feature requested, whether such concerns are even applicable.

To give you an example of mine (I didn't ask for almost anything really, they had enough work as it was with bug reports alone):
  • I wrote a full technical specification proposing the addition of a new modifier to UnrealScript (for variables, functions, enumerations, structs and a few other things), to make it possible for new UnrealScript features to be included in newer versions of the game, without breaking or crashing previous versions of the game (where you could even have many of the Unreal 227 functions ported over, and still be able for a 436 client to join and download a 469+ package using the new functions without crashing, or being even required to support them in some cases), and even described how it should work concerning the compiled byte code.
I wrote this, not expecting to be immediately implemented, or even being implemented as described ever, as it was written with the full understanding that it might not be feasible due to technical limitations or even the work it could imply, or even because it may not be such a great idea for any given reason from the developers standpoint, but being such a big engine-wide feature, I put in the work nonetheless in describing it and justifying it to the best of my ability to do so, so that the developers may understand as clearly as possible what is being proposed and how I envision it to work, to at least trigger some productive discussion around it.

Picking your "Give write access to dynamic arrays" example, you should provide details on what exactly do you mean with this, and given that dynamic arrays are not exactly supported nowadays by 436, you should have took the time to study and describe the feature as a whole, as "dynamic arrays".
And from there, you should describe what already works, what doesn't, what needs to be added, and justify why they need to be added.

Because there's a whole lot to define when we talk about "write access to dynamic arrays", like "writing how?".
There are tons of writing operations that could be implemented, such appending a new element, modifying it, removing it, maybe even prepending an element if that makes sense, and these have to be defined on how you envision the syntax to be.

Then how about reading? Can you read it perfectly? Do you already have the necessary syntax to work with them even as read-only? Do dynamic arrays have other problems that need to be addressed before?
These are questions you have to ask and answer yourself in your feature request, to the best of your ability.

If you're unable to do so, then the feature is likely not worth the trouble considering, if the party proposing it is not putting much work in defining it either and justifying its existence.
Therefore, you cannot just throw this one-liner and expect the developers to figure the rest out, and then expect credit for your "contribution" when it actually contributed nothing.


Hopefully it's more clear to everyone how these things are supposed to work, and what "contributions" should actually look like when it comes to bug reports and feature requests.

Buggie
Adept
Posts: 316
Joined: Sat Mar 21, 2020 5:32 am

Re: Were our bug reports and suggestions even useful?

Post by Buggie » Thu Sep 24, 2020 1:02 pm

I just want add to previous post template for bug report which I commonly used. Maybe not perfect, but good enough.

1. If need Some description bigger from title of bugreport itself - describe in very short form.
2. Word "Reproduce:" after that numbered list with simple steps and actions for fully reproduce issue in clean environment.
3. Words "Expected result:" and description what you expected to happen.
4. Words "Actual result:" and description what happen.

5. State of issue on different conditions in free format like "Main change: result of test". It can be different render, map, subsystem, previous build and so on.
6. If you think this issue in someway connected with your environment or it part - specify this info here. It can be part of config, description of hardware and so on.
7. If you have logs with relevant info attach it here. If here some description or thoughts - list here.

Usually bold part (2-4) required. All others optional. 5 - is too very important, so better always add it.

Example:

Code: Select all

Title: [win][26Aug2020]UT: CloudZone can destroy flag in CTF

Reproduce:
1. Open .unr from attach in UEd.
2. Start play.
3. Take enemy flag and go to side (cloud zone).

Expected result: Flag return to base when you die in CloudZone.
Actual result: Flag destroyed, map not playable anymore.

v436: bugged.
v469: bugged.

Strictly speaking Flag must not able Destroy at all. Or spawn copy at base if called Destroy. Maybe base check if flag exists and spawn another copy if not, IDK.
But definitely, primary map objectives must exists all their desired timeline and nothing can prevent to this.
Another:

Code: Select all

Title: [win][26Aug2020]UnrealEd: Text copy of brush do not contain Package for textures

Reproduce:
1. New map.
2. Substract brush.
3. Select all surfaces.
4. Apply any texture.
5. Copy substracted brush.
6. Paste text in text editor.

Expected result: All textures specified with packages.
Actual result: All textures specified without packages.

v436: bugged.
v469: bugged.

According to: http://www.clintons3d.com/vr/T3D%20File%20Format%20Specification.htm
Quote:
<Texture>
    The texture of the polygon. Must be specified in Package.Texture format.
Another one with images:

Code: Select all

Title: [win][26Aug2020][Regression]UT: FPS v436 better from v469 on D3D9

Reproduce:
1. Open MH-Battle4NaZaliBeta2.unr from
https://ut99.org/viewtopic.php?p=121766#p121766
2. Fly to same spot on both UT versions, look at same direction.
3. Type "timedemo 1" in console.

Expected result: v469 FPS better from v436.
Actual result: v436 FPS better from v469.
v436:
vVrqnof.png
v469:
GSfSrUe.png

Map rebuilt with v469:
v436:
ioUB6aA.png
v469:
mZIAiiw.png

Render: D3D9.
Setting same for both:
CodeSelect All
[D3D9Drv.D3D9RenderDevice]
ZRangeHack=True
NoAATiles=False
NumAASamples=0
UseAA=True
RequestHighResolutionZ=True
UseSoftwareVertexProcessing=True
UsePureDevice=True
UseTripleBuffering=True
MaskedTextureHack=True
SmoothMaskedTextures=True
SceneNodeHack=True
FrameRateLimit=60
SwapInterval=-1
UseFragmentProgram=True
UseVertexProgram=True
TexDXT1ToDXT3=True
DynamicTexIdRecycleLevel=100
CacheStaticMaps=True
UseTexPool=True
UseTexIdPool=True
UseSSE2=True
UseSSE=True
BufferTileQuads=True
BufferClippedActorTris=True
SinglePassDetail=True
SinglePassFog=True
ColorizeDetailTextures=False
DetailClipping=True
UseDetailAlpha=True
DetailMax=0
RefreshRate=60
MaxTMUnits=0
NoFiltering=False
MaxAnisotropy=0
Use565Textures=True
Use16BitTextures=True
UseS3TC=False
UseAlphaPalette=True
UseTrilinear=True
UsePrecache=True
UsePalette=True
UseMultiTexture=True
MaxLogTextureSize=8
MinLogTextureSize=0
MaxLogVOverU=8
MaxLogUOverV=8
OneXBlending=False
GammaCorrectScreenshots=False
GammaOffsetBlue=0.000000
GammaOffsetGreen=0.000000
GammaOffsetRed=0.000000
GammaOffset=0.000000
LODBias=0.000000
DetailTextures=True
DescFlags=0
Description=
HighDetailActors=True
Coronas=False
ShinySurfaces=True
VolumetricLighting=True
 
Another test with original map from ut99.org and with
STAT FPS
STAT GLOBAL
v436:
nv49reL.png
v469:
mCAQ714.png
Of course this format not applicable to all issues, but in most cases it fits.

And last thing. If developer tell you about fix issue you need go to check yourself fixed this issue or not.
Maybe issue environment dependent and devs fix issue, but not your or not in your case.

So when new build come out with list of issues fixed or devs directly report in issue about fix, you need recheck all of them which touched by new changes and tell results "Fixed. Confirmed." or "Issue not fixed in build bla-bla-bla.".

User avatar
PrinceOfFunky
Godlike
Posts: 1154
Joined: Mon Aug 31, 2015 10:31 pm

Re: Were our bug reports and suggestions even useful?

Post by PrinceOfFunky » Thu Sep 24, 2020 3:14 pm

Feralidragon wrote:
Thu Sep 24, 2020 12:12 pm
that doesn't even qualify as a report or any type of meaningful contribution.
So you're saying that you wanted us to make up a format (which would've been different for each person since there was no template given) to compile with details just like a professional bug report or feature suggestion? Then let's not run around, I'm sure you know If anyone here knew that's what you wanted they would've done it. And no, a format wasn't implied, the first post of the 469 topic here proves so: viewtopic.php?p=115004#p115004 , this is especially true for the first post of the Unreal Editor topic: viewtopic.php?p=96420#p96420 where it shows the format needed which looks like this: "-Preset brushes.", that's the only feature suggestion.

What you're saying is basically that a hundred of people, of which some veterans in the community were lazy and didn't want to help, including some from the 469 patch dev team itself.
"Your stuff is known to be buggy and unfinished/not properly tested"

User avatar
OjitroC
Godlike
Posts: 1884
Joined: Sat Sep 12, 2015 8:46 pm

Re: Were our bug reports and suggestions even useful?

Post by OjitroC » Thu Sep 24, 2020 3:56 pm

Feralidragon wrote:
Thu Sep 24, 2020 12:12 pm
Hopefully it's more clear to everyone how these things are supposed to work, and what "contributions" should actually look like when it comes to bug reports and feature requests.
I don't think anyone could reasonably disagree with anything you have said here. The only problem is that you (and presumably the other devs working on this project) are a professional working in this field - you know that this is the way bug reports and feature requests should be done. Your excellent outline of the correct process (coupled with buggie's very useful template) has really come too late in the development process for some people who may have no background in software development or, indeed, in project development.

I'm not criticising anyone but merely pointing to lessons which can be learnt for any future, similar project, particularly as regards communication with the wider community. Essentially this project started out with a consultation exercise ('make suggestions for improvements/enhancements, reports bugs to UT99 and its components') and later, as builds were released for testing, focused more on bug testing. The thing is though that consultation is a two-way process - those making contributions (however well or poorly presented) need feedback on their contributions to feel part of the process and to feel that they have been heard. I realise, of course, how difficult it would have been for the development team to do this. I would suggest, though, that if it is not done it can lead to feelings of frustration and alienation (which may account for the OP's reaction).

In hindsight, it might have been better to limit the submission of suggestions/bug reports to only one location (the oldunreal forum); to provide a format or template for people to make such contributions; and to have some form of feedback mechanism for responses to those suggestions/reports.

In conclusion, I can only marvel at the amount of work put into this project by the development team and hope that the new patch will ensure that UT99 continues to have a long and fruitful life.

User avatar
Feralidragon
Godlike
Posts: 5250
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Were our bug reports and suggestions even useful?

Post by Feralidragon » Thu Sep 24, 2020 4:42 pm

Perhaps I didn't express myself in the best manner, so to be perfectly clear, I don't mean that you need to create a professional-level bug report or feature request, that would be pushing it to the other extreme, which is unreasonable.

Even in a professional setting this is not followed through a lot of the time (unfortunately, and I have often to remind people in RL that they need to create more insightful reports and requests, and I also do personally what I preach by putting in the work in every issue I create everywhere, and it works).

That's why I used words like "should" and "ideally" and such, and not "must" for example, as a way to tell, incrementally, what each person could potentially do, and make a point that the more work, research and care you put into either a bug report or a feature request, the more seriously you will be taken, and the easier and more likely it becomes to be fixed or implemented, and thus the more significant your contribution will actually be.
This is pretty much the takeaway I wanted to convey, although perhaps not expressed in the best way in my previous post.

You're free to submit bug reports and be able to explain everything in 1 or 2 full sentences without following a specific format.
That's absolutely fine as long as the problem or feature request is simple enough and crystal clear to both sides, and it's actually better to keep it as simple as possible since developers do not like to read much either or go through a lot of stuff to get to the core of the problem, so you don't need to go the other extreme, as that wouldn't help anyone either.

All you have to do is to "care", care enough to put in just a bit more work to actively help the developers, than just to give them chores to do.
And one-liners like simply "X is broken" or "add support for X" , without any more detail, context, anything really, and without even a justification in the latter example, are indeed extremely lazy and do not really contribute towards anything at all.

And if you're a new person to this kind of world, and do not know how to do it properly, and so you happen to start your first reports and requests like this hoping that developers are these all powerful wizards who will figure it out for you, that's actually fine too, we can help you do better reports and such, and even potentially create a standard template if that proves to be more helpful.

But in that case, you don't get to do it, defend how you do it despite being explained why it doesn't work, and then ask credit for it like it was such a significant contribution, which is the reason why this thread was created in the first place, and what in the end I was trying to tackle from the start, and why I clarified in such a long post what putting in significant effort here actually means. :)