[sytse]

Glad to hear you're a very happy user!

We do the same thing as you, create the same milestone in each of the repo's and then use the group milestone view to see an overview.

It would be nice to have a create milestone at the group level that creates the milestone in all projects, would you be willing to contribute that?

Mentioning issues or merge requests in other projects can be done with the cross project reference, found in the right hand side of every issue and merge request, for example gitlab/organization#260

[habith]

I just looked at the pricing page on Gitlab.com and was genuinely interested in trying it out. But the pricing language and structure on the page turned me off instantly.

I thought to myself: "$3.25 per user per month? Sweet! I can throw $6.5 to try it out without the hassle of setting up yet another VM. Charged yearly? Eh, seems to be a bit of a commitment. Oh wait, in multiples of 10? that's $390 upfront with 8 extra licenses for a year!"

Compare that to Digital Ocean's pricing page: https://www.digitalocean.com/pricing/

They list the monthly price first but they actually bill hourly. It seems more honest and upfront to tell me what I'm in for.

I understand that you're competitive compared to Github enterprise, but I think that page needs some work to make it more trustworthy and less salesman-pitch-y. Even Github lists that they start from $2500 upfront, not $3.25 + read the fine print.

Best of luck to you and congratulations on the funding.

Edit: And I just noticed that's actually for the on-site EE and that Gitlab.com is free. Oy vey.

[sytse]

Thanks for your thoughtful comment. We had yearly prices before but most people expect a price per month (our prices are pretty low so many people assumed our yearly price was our monthly one). I agree that now it is hard to make out the minimum order size, you need to do x10x12. Would it be an improvement if we add '$390 per user pack' to the list of items below the price to save you this calculation? BTW If you want to try it out we do have a money back guaranty.

[habith]

Thanks for your reply. Price x12 like you said is standard, it's the x10x12 that caught me off guard.

I think some language and price listing adjustments like you suggested would be a great improvement. Even if it's as simple as $32.5 per user pack per month (charged yearly).

[sytse]

I don't think pricing per user pack is what people expect, per user seems to be the more common question.

[habith]

But you _charge_ per user pack, do you not? Can we purchase 17 licenses? How about 23?

We have around 20 Backblaze licenses that we pay a bit over $1000 per year for. It makes sense for them to advertise the price per user because they charge us that way.

This is akin to Pepsi sticking a huge sign over their 24 pack at the department store saying "NOW ONLY 99 CENTS PER CAN!" minimum 24, in increments of 24.

Anyway, like I said, the way the pricing is advertised turned an interested/potential customer away.

[sytse]

I've put the user pack price at the text below the pricing so it is clear from the start https://gitlab.com/gitlab-com/www-gitlab-com/commit/7e6b6f87...

[merb]

it would be great if you would change it to something like "monthly subscription" "per user pricing". Which means I could start with 2 users, add 10 and pay for them and maybe then I will kick two in the next month and will pay for 10. Paying on demand is something that I think would be really really good. AWS style.

[sytse]

I understand that need but having smaller tiers that 10 people is inefficient on our side and we would need to raise the price.

[toomuchtodo]

Your current pricing model is fine. If someone needs GitLab, they'll pay for it. If they don't pay for it, they don't need it. $30-60/year is cheap, even for a hobbyist project.

[mikekchar]

I think you may have validated what the OP was saying :-) It's $3.25 per user per month, but the minimum order is 10 users. So the minimum price is $390 per year.

[rcthompson]

I think the real angle of this feature should be to abstract the concept of "project" so that it is no longer synonymous with "git repository". And the migration path is pretty straightforward: every repo becomes a project containing a single repo, and then users can merge existing projects to create multi-repo projects (at which point you'd probably have to re-number every issue, pull request, etc. to avoid collisions).

[chetanahuja]

We use gitlab at PacketZoom too and are mostly happy with this. But yes, I second the request for either:

a) Creation of a project independent of git repos.

OR

b) At least a way to attach issues across projects. Issue management is probably the weakest part of gitlab and one of the big reasons is this fragmentation of issues across git repos. It's trivial to see that issues can and will cut across git repos in any reasonably complex product. Another "nice to have" feature would be an ability to create "dependent" issues.

[sytse]

We looked into this but it creates a lot of complexity. The group milestone view solve the problem neatly.

[rcthompson]

That seems pretty reasonable, maybe even preferable. Having issues attached to specific repos but synchronized to cross-repo common milestones sounds like it would work well.

[sytse]

Thanks! To give you an idea of how it looks I've attached a screenshot of our group milestone overview https://www.dropbox.com/s/ectdan1qc22vd3k/Screenshot%202015-... and a specific milestone https://www.dropbox.com/s/rqb6rhaxafrmrtn/Screenshot%202015-...

[BinaryIdiot]

I like this way of organizing. At my last company we had a very, vary large project that had about 70 git repos (and that was after combining quite a few of them). A project view would have made that so much easier to manage.