About the Feature Requests category


#1

Post your Feature Requests here and vote on others’!

Voting is enabled in this Category, so feel free to browse the existing requests and cast your votes on the ones you like!

This is an experimental category right now! If it works out we’ll move the feature requests from https://bitrise.uservoice.com/ here.

If this is a feature request which can be developed by the community, e.g. as a Build Step, you should mark the post with the #contrib-this-feature tag (or we will). If you’d like to contribute to Bitrise (and get a $25 discount from your Bitrise subscription :wink: ) but you need an idea to work on, you can check the #contrib-this-feature tag page and just pick one.

How to vote

To vote on #feature-requests please use the Vote button at the top left corner of the feature request.

Notes about the voting system

Your “trust level” here on discuss.bitrise.io defines how many votes you can cast. If you’re active here you’ll be able to cast more votes. You’re of course free to revoke your votes from feature requests if you’d rather cast it on another feature request, and your votes are also returned once a feature you voted on is finished (closed).

Vote counts:

  • Trust lvl 0: 7 (+0 super vote)
  • Trust lvl 1: 12 (+1 super vote)
  • Trust lvl 2: 15 (+2 super vote)
  • Trust lvl 3: 20 (+3 super vote)
  • Trust lvl 4: 25 (+4 super vote)

For better visibility the default ordering of the #feature-request list is by activity, to highlight new feature requests and the ones which have active discussions.

If you want to see which open feature requests are the highest voted click here.


Parallel Builds: Seperate stacks for seperate workflows + trigger multiple workflows (builds) at the same time
#2

Priority of a feature request:

Priority of a feature request depends mainly on three things:

  • The vote count of the #feature-request here on discuss.bitrise.io
  • An internal multiplier (1x, 2x, …) based on the complexity of the task (smaller tasks are easier to schedule so those get a higher multiplier)
  • And an internal multiplier (1x, 2x, …) based on “product fit” (whether we have a use case for it in our own products, or we think the feature request would be useful for a large amount of users).
    • This also includes the discussion related to the #feature-request - if there are clear use cases which indicates the feature would help a lot of users that’s definitely a significant plus.