Reported bugs and requested features docs synchronization

[ipaleka]

https://github.com/asastats/docs/blob/main/reported-bugs.md
https://github.com/asastats/docs/blob/main/requested-features.md

Right now we are in the transition period and there are issues recorded both in Trello and Channel issues section, it is expected that in the near future all the issues are moved to Channel.

We had planned a Trello-GitHub synchronization scheduled task scripts, @dragmz even started working on them, so we need to discuss should we continue in that direction and switch to GitHub source instead of Trello?

Also,m we should discuss the need for those documents as everything is going to be publicly exposed (we had implemented them as our Issue Tracker in Trello wasn't publicly exposed) by filtering issues. It would be nice to have them tho in a nice sorted listing of clickable items tho.

[wxivd]

I think there is no added value of recording/moving any fulfilled tasks from Trello to Github. Those bugs got fixed and features implemented (or are already registered in Dependent feature requests). Moving forward, all new issues/tasks are created directly in designated ASA Stats channel.

Any open tasks in Trello shall be moved to channel to avoid duplicate requests/bug reports.

[ipaleka]

I haven't explained it well.

No redundancy has occurred, tasks/requests/reports that are resolved before Channel is introduced are rewarded and archived in Trello.

Tasks/requests/reports that are created before Channel is introduced are being moved one by one to "Moved to Github" list in Trello after a related issue is created in Channel (example1, example2), and they are afterward rewarded just like those that first time appeared in Channel.

That is clear and demands no discussion.

What we need to discuss is whether we still need a separate docs document like Requested features (which is introduced at the time when our Issue Tracker wasn't publicly available) now when people are able to filter Channel issues section for the ongoing and resolved feature requests?

[wxivd]

Thanks for clarifying this. I really think docs documents (and the whole docs repo) are not needed anymore.

• Any important docs shall be added to Wiki.
• Tracking issues (ongoing/resolved) is easier thank docs and more accessible. Hence docs are out of date and require constant updates which takes time and does not add value.

[ipaleka]

Thank you for taking a straightforward stance on this.

We'll wait for others to join with their reasoning. :)

[dragmz]

Wiki, reported-bugs.md and requested-features.md seem redundant to GitHub Issues:

1. reported_bugs.md maps to bug, high priority, medium priority and low priority labels
2. requested-features maps to feature and the priotity labels too. New labels could be added for dependent features, e.g. user settings, user widgets etc. so features like "Show values in a currency user selects" would be created as issues with feature and user settings labels.

Then both .md files could be removed and wiki could just link to the filtered issues, e.g. https://github.com/asastats/channel/wiki/FeaturesDependentOnUserSettings content or "User settings" in https://github.com/asastats/channel/wiki/DependentFeatures might be replaced with:
https://github.com/asastats/channel/issues?q=label%3A%22user+settings%22 that lists issues with user settings label.

This would reduce the time required for maintenance.

[wxivd]

wiki could just link to the filtered issues, e.g. https://github.com/asastats/channel/wiki/FeaturesDependentOnUserSettings content or "User settings" in https://github.com/asastats/channel/wiki/DependentFeatures might be replaced with:
https://github.com/asastats/channel/issues?q=label%3A%22user+settings%22 that lists issues with user settings label.

This actually looks ideal, we will need to open new issue for all included requests in Dependent feature requests. Is there a possibility to add third status for issues (Open/closed/pending future developments)?

[ipaleka]

Is there a possibility to add third status for issues (Open/closed/pending future developments)?

Please think of an open issue as an open wound in a human body. The system itself should be designed in a way that prevents open issues.

When somebody creates a request that is a dependable feature request then somebody else has to do the following ASAP:

1. create an entry in a related subpage of the https://github.com/asastats/channel/wiki/DependentFeatures

A link to the issue inside that entry is mandatory (rewards-wise), while our good practice so far has been to either copy/paste the description or formulate the issue by your own words (clicking and reverting back to just getting to know what this is about should be avoided).

2. add a comment with a link to that entry

The simplest form is always the best, so just this in that comment:

https://github.com/asastats/channel/wiki/FeaturesDependentOnHistoricData#average-apy-for-staking

3. label the issue with "wontfix"
4. close the issue

We can maybe discuss should we add another label that in this regard means the same as "wontfix", but that label is GitHub's default and so probably our best choice.

[ipaleka]

And so, once we implement the dependable platform/functionality, then we simply open new issues from the related page entries one by one based on our resources to make that wound bleeding as little time as possible.

[wxivd]

When somebody creates a request that is a dependable feature request then somebody else has to do the following ASAP

We need more access permission to edit/create pages in wiki https://github.com/asastats/channel/wiki/DependentFeatures

[ipaleka]

We need more access permission to edit/create pages in wiki https://github.com/asastats/channel/wiki/DependentFeatures

Please try now.