(no title)
rogerluan | 2 years ago
I agree with your points. The point of gathering the API key is to actually be able to provide a lot more information in the future, such as some light data science (analytics) into your releases, and maybe expand to other areas (e.g. taking actions from the Slack messages themselves).
What do you mean with "like a real mail-filter"?
The RSS feature is kinda on the roadmap but I haven't gotten any feedback about users wanting that type of integration. Incoming webhooks is higher up in the list, so users can trigger internal CI actions upon receiving requests to such webhooks.
Any other type of APIs you'd like to see this tool covering? :)
PurpleRamen|2 years ago
I mean receive mails from a mail-server (pop3, IMAP, Gmail, exchange, etc.), filter according to user-specific criteria and output on slack. This might even give some additional value by having maintained filters, if you can get your hand on enough for your customer's relevant mails. And it would give opportunity to shrink the privacy-problem, as people could use dedicated mailboxes for such mails.
And you could even reuse the filters+interface for all other sources too. Like maybe, they only want to see certain releases, or for a specific app.
> Any other type of APIs you'd like to see this tool covering? :)
That's a problematic question. There are too many apps and APIs. You could focus on the common tools, like issue-trackers (Jira, etc.), error-trackers (sentry, etc.), maybe Slack itself? But instead of just adding APIs, the actual value for your customers might be to add unique use cases which pushes your tool above the existing workflows. Adding statistic and appeal to rejections seems worthful on surface. But you should be aware that you are competing with others tools, like Zappier or a simple mail-clients, and you likely have not enough manpower to beat them on their ground. So you may better focus on quality and additional value for your customers, and communicate this very very well.