Establishing a process for feature requests

Community Product Team
1

Pasting from initial post on Trello:

Background

Previously the GitHub issue tracker was also used for tracking features. However this proved problematic, e.g.

  • The large number of ideas for new features mixed up with bugs made it harder to track the bugs. Even if labels were used to distinguish bugs from features, it made the number of open issues artificially high, which presented a negative image of the community to outsiders.
  • Non-technical stakeholders would submit new ideas in a way which didn’t tie up well with development activities.

As a result, it was proposed to move feature tracking to the forums, and feature issues in GitHub were closed. Unfortunately other problems with the forums such as spam attacks surfaced soon after, so the community has effectively been without a place to track features for quite a while.

So the community needs to decide how to address this.

Proposals

One proposal made on the community technical call on Aug 15 2019 was to use the new Discourse forum for more informal brainstorming around new features, but also to create an issues-only repository e.g. https://github.com/mautic/features which is dedicated to feature tracking. This would have all the standard advantages of using a structured issue tracker, but would keep it cleanly separated from the existing issue tracker. Write-access to this could potentially be limited to technical contributors who can help with the relationship between feature ideas and the corresponding concrete technical work required to implement them. Ideas could then start off being formed in Discourse, and then promoted to GitHub when technical discussions commenced.

2

The problem with the old placement was that it was used as a dumpster, no one ever paid attention to it and hence it became useless.

As long as we have a process to identify and surface valuable proposals and only if the leadership agrees to implement some of those ideas, the new platform could be anywhere…

  • Independent github track:
    PROS: Nearest to developers, possible better quality input. Better organized, clearer to understand by devs that would eventually create those new features.
    CONS: Further away from marketers, which should be the main people we listen to if we want to remain competitive against the 5000+ products out there…
  • Discourse:
    PROS: Closer to marketers, simpler to understand for casual users.
    CONS: More clutter, maybe broader and lower quality proposals. Marketers might not be familiar with what’s possible and what’s unreasonable for the dev team and the dev team would probably pay more attention to it if it was on Github.

But I don’t think the location is the problem, if there is no compromise on developing the best / most requested features, it is pointless.

3

I think with clear guidelines on the features & ideas category we could use it effectively. We also have a Github integration (which I have not fully set up yet, it’s only pulling in badges currently) which allows GH issues to get a ping if mentioned in forums, and vice versa.

4

Agree with both of you :slightly_smiling_face:I think a dual tool strategy could be very effective if the right process is put in place for promoting ideas to github and prioritising correctly. Yes, integration would help a lot too.

1 Like
5

Great, so the new topic would be, how do we identify the best proposals and does good/best always match most wanted (usually not) and how important it is to keep people happy even when what they want is not what we believe to be the best feature.

1 Like