Moderators: another_commander, winston
Another use for the backlog is that we disuss and agree on changes as a group which allows getting involved and be part of the lot. The last couple of changes were announced after having been applied to the master branch. This does not feel collaborative. It even gives the impression that further contributions are unwanted.
That is actually what we have at the moment. The pdfs are currently being built in readthedocs and are downloaded from there during the Windows build. The pdfs are irrelevant to the MS Store and all Linux builds because they are not traditional installers, hence the readthedocs site. Personally I'd be in favour of the documentation being made available from a menu in the game itself. All the other approaches seem like kludges to avoid having to write Obj-C code to handle it.hiran wrote: ↑Wed Apr 01, 2026 10:23 amI was thinking about removing the dependency to LibreOffice. I'm not stuck with that.
But it is still important in my eyes to know which documentation relates to wich Oolite version. Thus I'd like to see a version stamp on it.
The PDFs we used to have in the repository were updated rarely. Yet when they were devs forgot to update version numbers or other metadata or were simply unable to generate the PDFs using the correct fonts and layout.
So I moved PDF generation into Github, although that introduced the dependency on LibrOffice.
I am wondering now how you would cover a build without LibrOffice and without going back to having the PDF generation on the developer's table.
I think packaging an appimage in an installer defeats the simplicity of appimage.hiran wrote: ↑Wed Apr 01, 2026 9:38 pmSounds like we traded the dependency on LibreOffice for a dependency on readthedocs.
Indeed it sounds steange to download these PDFs back from readthedocs.
But you mention the PDFs are not required for the modern builds. Actually there is no common pattern where to provide documentation for modern software. Should we embed PDF and PDF readers into Oolite? Should we add HTML documentation and a web browser?
What would happen if we packaged the appimage into an installer that creates directories, creates desktop icons and links to the PDF documentation?
Code: Select all
#import <PopplerKit/PopplerKit.h>
// In your Controller
- (void)showManual {
// PDFDocument and PDFView here map very closely to Apple's syntax
PDFDocument *doc = [[PDFDocument alloc] initWithURL: [NSURL fileURLWithPath: @"/app/share/doc/manual.pdf"]];
PDFView *view = [[PDFView alloc] initWithFrame: [myWindow contentRect]];
[view setDocument: doc];
[[myWindow contentView] addSubview: view];
}
That makes it three of us.
Well, I can create a project. There are a bunch of templates (Team Planning, KanBan, Bug Tracker, Feature Release, Iterative Development, Product Launch, Roadmap and Team Retrospective). What ones do you want to experiment with?
Is it either or? As I do not yet know where we are going let's get started on something.
I can see it. Thank you for that.
I can see it. I added a whole load of issues for the backlog items I've described in this thread. I hope that this doesn't become a talking shop but encourages new devs to step forward and implement some of these ideas.hiran wrote: ↑Thu Apr 02, 2026 9:56 pmI can see it. Thank you for that.
So now we can experiment how to organize the issues into the different views. There is Backlog, Quarterly and Monthly already.
@all: Add your ideas as issues. We can then discuss them and once aligned open them for implementation.
edit: I just logged
https://github.com/OoliteProject/oolite/issues/568
https://github.com/OoliteProject/oolite/issues/569
and added them to the project.
Who else can see it?
I don't think it's a good idea to add old issues to the project board. It will just create a lot of noise. I think the original 20 issues are more than enough to occupy the current dev team for years to come so little point in adding things that no one will have any time to look at unless you're putting yourself forward to go through all those old PRs and test them (eg. the FOV one is from 2015 and the code has changed since then). Many projects have rules set up that autoclose issues beyond a certain age.hiran wrote: ↑Fri Apr 03, 2026 8:29 pmThis is great. We already have 20 issues on the backlog. The ideas are there, and more are welcome.
Yes, I also want this to be more than just talking. Now that we collect stuff we can see what to do next.
So I think we should discuss the issues, agree how to implement and then action the single issues.
As far as I can see we are four people. To have a reasonable gate I suggest at least two people to agree on an issue.
Votes could be as simple as the Apache Foundation does by writing a "+1" for approval or a "-1" for disapproval.
Also I found another potential source of community members - or the constructive critics: Our project has a few pull requests pending. If we ignore them to death the author behind will get disappointed. If we approve or at least comment on the PRs the author gets some feedback from us which enforces the bond - to us and the project. Thus I'd like to not just discuss our own ideas but also look at these open PRs.
We'll likely have to change or refine the way we work so the above is not carved in stone. Eventually we can document it in a wiki page so others perceive transparency.
Please comment if you agree or have concerns.
I cannot even tell if a merge is reasonable, yet test if all would still work with the merge.mcarans wrote: ↑Fri Apr 03, 2026 9:46 pmI don't think it's a good idea to add old issues to the project board. It will just create a lot of noise. I think the original 20 issues are more than enough to occupy the current dev team for years to come so little point in adding things that no one will have any time to look at unless you're putting yourself forward to go through all those old PRs and test them (eg. the FOV one is from 2015 and the code has changed since then).
