Oolite Bulletins

Right now I am witnessing some active OXP development/testing/feedback iterations. And I am wondering if that could be eased a bit.

Of course the discussions have to take place. I would not modify that part.

But suggesting code changes as it is looks risky to me. How to ensure the right change was applied when and where needed? How to ensure all these modifications are performed by all testers?

On the way back we need the tester's impression but together with that we need some info on the environment and logfile.

Who would agree the two above steps are repetitive and could be standardized and improved?

hiran wrote: ↑Thu Apr 11, 2024 1:13 pm

But suggesting code changes as it is looks risky to me. How to ensure the right change was applied when and where needed? How to ensure all these modifications are performed by all testers?
...
On the way back we need the tester's impression but together with that we need some info on the environment and logfile.
...
Who would agree the two above steps are repetitive and could be standardized and improved?

As a crash-test-dummy, I'd agree in part. It's very dependant on context.

Why faff about with logfiles etc. when simply pointing out a typo in a specific plist of a first version of a new OXP. Environment has no relevance here.

If the previous message was "I see the bug you're highlighting, try THIS version", and my reply is "that made it work", would my having to present, or worse, repeat all the log and env stuff be helpful?

It's clear that in some cases, like if a dozen testers were active on an OXP, posting a code snippet or one-line diff as a suggested patch might end up with 'fluffy' take-up. But if such scalpel wielding were kept to inter-version close-knit direct conversation, then that wouldn't be a problem. Perhaps PM's could be used more to keep the threads clear of smaller edit-test cycles, limiting smaller issues to one or two focused testers who are able to edit an OXP in a heartbeat. Once an issue is past that, when more eyes are required, a proposed point-version OXP can be posted to the thread for wider testing before going to the manager.

New posters in a thread where such cycles are in use, should indicate at least which version of the OXP they're using, to show that they're in the same place. Mission logic and typos are AFAICT arch and env agnostic. Maybe some locked pages about how to get logs, how to extract lines of relevance, how to format env info, etc., and how to make those things privacy safe, which can be pointed at by devs who want the extra info to avoid repetition, and to help steer the 'paste whole logfile' types.

I'd be cautious of too much 'gate-keeping', particularly the immutable automatic kind. Some projects have such numerous hoops to jump through to post a trivial issue such as a typo that I simply gave up.

Ok, what I was thinking of:
Have a tool that makes it easier to distribute hotfixes. OoliteStarter might already be present to manage OXPs. It could quite rigorously check and update OXPs under development, just to ensure the tester is running at the latest state from the developer.

After a session, or even inbetween OoliteStarter could help generating feedback. This by providing a text box for the tester's words. And two checkboxes the tester can activate so logfile or environment description would automatically get posted. We'd have to decide where this information should end up. I can imagine us setting up an extra forum with a quite short expiry date.

But that's it. Roundtrips to distribute versions and collect the feedback handled. This kind of feedback could not just be generated easier, it could also be understood easier as it comes in always the same structure.