-
Notifications
You must be signed in to change notification settings - Fork 0
01 Introduction
This is an introduction for the core team and those interested in platform development.
This GitHub repo has been created solely for the purpose of tracking tasks associated with the platform. It is an Issue Tracker, for both bugs and enhancements, for app and docs.
The resource allows everyone to search for issues that have already been reported, to keep relevant notes in one place for each item, and to understand exactly where each item is in processing, from initial discussion and confirmation, to work in progress, beta status, and finally into production.
Pull requests for code are not processed. There is no code assocated with this repo. This is being used purely as a ticketing system and resource for the community to centralize reports. (A GitHub repo cannot be created without a PR section and some other required features that cannot be removed.)
This does not replace the tracker for docs, which is used for both the documentation processing mechanisms as well as content. The new tracker is a higher level resource for users and the doc repo issues area is still a lower level resource for actual development. There will certainly be cross-over here.
This resource is not another discussion area and does not replace existing discussion media. Rather, it allows us to take a discussion to the next step, and does allow us to focus public discussions more on how to use the platform than on change requests which may be lost in discussion. We need to talk through problems and ideas for changes, as we always do. This helps to attach an offical tag to discussions when we know changes are actually required.
We will still report and discuss issues in forums, but as soon as we know that an issue is real and not just a user error, we should then ask the originator to report the issue in the tracker, or do it for them. Once a ticket is created we should add the ID as a comment into the original discussion. This allows us to link discussions with their issues so that we all later know what happened, if and when the issue is processed.
- Give all of us a single place to go and get a solid ticket ID that represents any issue, whether for app or docs. We can then use this ID as the canonical reference for a concept and for tracking the progress of that from start to finish. This also allows us to refer back from the ticket to discussions about the topic, and helps to eliminate that "whatever happened to that thing we talked about?".
- Help the development team to prioritize, assign tasks, track progress, and ensure work gets properly moved through testing before production.
- Further instill in the user community that issues are not lost into the ether - they are being processed : "and here is your ID to follow progress".
See the 02 Why? wiki page for other notes about why this resource exists, and decisions made about why we are using GitHub rather than a different platform.
"Processing" does not guarantee a change. Labels provide a mechanism that allow us to reject requests, flag duplicates, mark invalid requests, and to note that the product simply will not be changed for a request. These are all valid resolutions from the processing of a ticket.
The team may use another tracker, emails, IM, and other mechanisms behind this public resource to process a ticket, but significant findings of interest to the report author and the community should be noted in the public ticket.
Take a look around. Visit the other Wiki pages.
If you have logged an issue (enhancement request or bug) in Discord or in another forum, please translate that into a new ticket. If you see an issue reported by someone else, create a ticket. If it's been processed into v2.67 or prior, don't worry, it'll get tagged and closed. Comment in Discord, ask questions, make suggestions.
After some initial usage by those interested in platform development, announcements will be made in the platform forums. At that point, questions, recommendations, and other discussion about the tracker repo itself should be in the Discussions area in the repo.