I’ll give this a shot.
There are issue trackers in several places. I referenced the Purism developer wiki for the following info:
Popular issue trackers
- phosh Wayland shell for GNOME
- libhandy GTK library
- chatty messaging application
- calls phone application
- https://source.puri.sm has many more (as described in @FamousJameous’ post)
There is also https://tracker.pureos.net/ for PureOS-related issues.
Go to the issue page in the corresponding software repository and click New issue in the top right corner of the page. This will take you to a form you can fill out and submit. You enter a subject and a description, and may also be able to tag the issue with certain flags like Bug, UI, etc.
Sometimes Purism developers say outright within these forums what they are actively working on. If you want a more direct view of what contributions are being made at a low-level, you can view the commits that are being performed within each repository. Here are the most recent commits for the calls app, for example.
For a higher-level view that is still within GitLab, view the project milestone page. This project management tool takes extra resources to prepare and isn’t populated within most projects I’ve seen, so please don’t assume one exists. Here are the milestones of the calls app as a basic example.
One common way to suggest a new feature is found in the issue page of each corresponding software repository. First, search to check if anyone else has already made the suggestion, including the closed issues, in case the change was previously rejected. If nothing is found, create a new issue. It is common to find feature request issues with a title such as “Feature Request: feature summary” and/or tagging the issue with e.g. a Feature Request tag, if one exists.
My answer here will be more generic than just a “previous os update” as I feel that topic has been covered by others in this thread.
Release notes are extremely handy to publish, but they are often arduous and time-intensive to create. For these reasons, they are only occasionally found in the wild and typically only on larger, higher-visibility projects or projects for which there are external stakeholders that want to see value-add reports at a glance.
Release notes are often sent to stakeholders directly but, on many open-source projects, they may be listed along with project releases or in the form of a blog post. See the release notes for the calls app for an example of how release notes may be published in conjunction with a formal software release.
This depends greatly on the many unknowns of humans in the loop of the software development cycle. If a project has an exceptionally mature and transparent product release structure and detailed/curated issue tracking, you may find a group of issues staged with a particular issue tag that would indicate that the issue is triaged or undergoing active development. Progression of milestones may also provide an indicator but, again, the mileage will vary between projects, products, developers, and companies.
My personal experience has shown that most teams/developers do not spend the extra time necessary to organize a project so thoroughly, and you’d have to ask them directly through GitLab, forums, IRC, etc, to know what is coming up next. Here is the Mastodon public roadmap as an example of what it looks like for a project to be very forthcoming about upcoming features and product considerations.