What would you like to see in a next generation issue trackers, search, or build solution?
- Issue comments that are no longer relevant, should be collapsed by default.
- You should be able to get a "too long; did not read" for issue comments.
- Searches should be context aware. Matches should take into consideration the user, time, branch (is this a release branch, developer branch, shared development branch, etc.) and so on.
- Build logs should include a "too long; did not read"
- Builds should be context aware to prevent wasting of resources.
I'm not sure what GitLab's sales engagement looks like, but if you are not, you should be asking to speak with a company's internal, tools dev team, if you can. Large companies spend an insane amount of money and time, creating/maintaining bespoked dev tools for internal use. Companies like Google, Facebook, Twitter, etc. spend millions in labour cost annually, to build and maintain their internal solutions.
GitLab's goal, should be to see if they can create comparable solutions, that can be managed by small startups and mid size companies. Having worked in tools dev for Enterprise, I knew being able to search and analzye anything, is a time saver, but I also knew, it would be cost prohibitive for many smaller companies to provide such a solution internally.
This was why I set out to develop a solution that could be maintained by companies of all sizes and this should be the thought process for GitLab, in my opinion. If GitLab wants to work on solving the harder problems, it should understand what companies are spending internal resources on creating/maintaining and see if they can't make it available for the masses.
What you learn could lead to more intelligent code review solutions among other things. In a lot of ways, you are trying to capture somebodies skill set/knowledge, which isn't all that trivial.
Unfortunately, because gitlab is so awesome, all the technical users in the company (100+ people) use it as a really basic scm for the tools they write. Some of them use issues, others just use it as a place to keep and share their code that isn't their home drive.
Paying for 100+ user licenses is out of the question, especially if under 10 of them would use the features.
We looked at increasing the granularity of the licensed userbase (have some CE users, some EES users, and some EEP users on the same installation). This is something established players like Salesforce and Zendesk don't do, probably for a good reason. We now have to make this granularity for GitLab.com (which is running GitLab EE). But we're very afraid of selling this since it will likely greatly complicate the sales process.
We also looked at increasing the granularity of the licenses. You used to be able to pay per feature instead of having to make a bigger jump. This didn't work since it increased the complexity too much.
For larger customers we can spend time to figure out what the value is and discount if that is appropriate. Your team is on the smaller side but feel free to reach out to sales@gitlab.com to see what we can do (please consider including a link to this comment).
Obviously a great thing would be to have the other users in the company also benefit from Enterprise Edition features so the value is higher than the cost. But your comment indicates that chance is low.
I'm sorry that I don't have a solution.
If gitlab could figure out a way to be more granular without customers having to go through hoops of talking to sales team, gitlab would probably benefit greatly by converting more sale opportunities.
I can see many teams, rather than grabbing a hand-full of EE licenses would just stick with CE or maybe even just slap/integrate something on top to get what they want.