one thing was going through my mind these days… what to do with Feature Requests? Should we keep them on Github amongst all bugs or should we “ban” them here? There are 2 possibilities I think:
Option 1: Have them on Github, label them with “feature-request” and have them have “[FEATURE-RQ] …” in the subject
Option 2: “Ban” them from Github completely (meaning closing them) and refer everybody here in the Feature-Request category?
Having them on Github has the obvious advantage of visibility “in the usual tool that we work in”.
Having them on the forums allows for refining them until it’s clear how that feature is gonna look like. And it would have the benefit of a more clean “github”. After discussing them here one could still add them to Github (with the actual and final requirements) and maybe add a tag like “feature-refined-ready-to-implement” (you get the gist).
If the feature request lifecycle were to begin in Discourse, there would be more opportunity for discussing and socialising the feature request, and presumably more opportunity to identify potential for the new feature to impact existing functionality or other features also under development.
There should then be some process or maybe an official Rocket.chat gatekeeper to give a ‘go ahead’ for a new feature when an actionable spec has been proposed and agreed. Spec should probably include tests and user/admin documentation to go with the feature. When all that is done, then this would be the time to migrate it to GitHub.
Issue trackers like GitHub can very easily be overwhelmed with vast number of items, and this would help limit that outcome, plus a process like this could help mitigate problems where contributors go ahead with developing their desired feature, but then find themselves waiting for a long time for the feature to be reviewed and merged by RC core team.
Of course there is nothing stopping a contributor from working outside this process and submitting PRs whenever they choose. But if they do that, then under this process RC core team would have stronger justification for whatever time it will take them to review and approve pull requests.
Yep, you’re totally right with the gatekeeper, since not every feature will be implemented (may it be due to the general roadmap or due to time constraints) so something like Yes, we like that feature and we plan to include it in RC from somebody official would be important. And I also think there’s gonna be lots of Nope, that doesn’t make sense for the broader userbase - we will not implement it-cases.
Another fact that I find rather important in the current situation is: we could simply close new feature requests on Github and refer them here. As for those hundreds and hundreds of feature-requests already on Github, I think there needs to be a onetime effort and most of all lots of decisions from the RC team.
Thanks also for the link to HAWK’s discourse post. Nice insights there
@erlend_sh: what a great point in case from the atom folks! Thanks, too, for this link. In fact, two paragraphs struck me more than all:
To be clear, the goal of this effort is not to bring Atom down to zero open Issues. There will always be things that we want to work on or bugs we need to fix. The goal here is to be better stewards by being more responsive, to be more transparent by telling you what we need in order to complete things, and to make Atom’s Issues lists easier to navigate by keeping them clean.
… and …
The general rule of thumb is that GitHub Issues is best for things that have a definition of “done”: they can be fixed, added, resolved, have a stake driven through its heart or otherwise laid to rest. For things where there isn’t a clear goal or end state, where you want to debate theory, or ask questions Discuss and the Atom Slack are the way to go.
The whole article is gold and is something that is missing for Rocket.Chat currently. Such kind of determination is needed for Rocket.Chat’s handling of issues/PRs/FRs and so on!
Would love to hear some feedback of the Rocket.Chat team on this! I will be meeting lots of the RC folks in a bit and this is one of the topics I will most definately bring up Maybe we can find a proper solution to this
Cheers & Thanks for the great feedback so far!
Thomas
I think this very much touches on some of your feedback in your other post:
We’ve gone from the hey we need to know what people want. To… ok we have an idea of what people want, and some of these ideas would never make sense for us to develop. They are neat… but just don’t belong.
Triaging is one of those never ending nightmares. Try to categorize and move on. But at that point they just sit there. The good ideas, the bad ideas, the never gonna implement ideas, and good ideas on our roadmap already.
Next week the entire team will be getting together. This flow I think will be a hot topic.
