GitLab 9.1 Released with Service Desk, Canary Deployments, and Burndown Charts
about.gitlab.com
about.gitlab.com
Creating next generation issue trackers, search, build solutions, etc. requires significant R&D and I really don't think GitLab is focused on this type of skunk work. I personally think Microsoft has the best chance to disrupt the software development lifecycle in the future, due to their R&D budget and talent pool.
GitLab in a lot of ways, is sitting in a perfect business position. All they have to do is look at what Atlassian, Microsoft, GitHub, etc. are doing and copy what can be copied. There really is no shame in this, as this only makes business sense.
Git has created an opening into the software development market that has never existed before. In the past, you had to spend a lot of time and money to create a version control system, which you could use as a beachhead for Enterprise sales. However with Git, you no longer require significant time and money to compete.
With Git, the really hard stuff is being worked on for free, by some of the smartest people around the world. And because of that, you can focus on solving the not so difficult problems, but still problems people would pay for.
Git has created a massive opening for who can compete in Enterprise, but as the easier problems get solved and turn into commodity features; focus should shift again, to the not so easy problems. If GitLab invests properly, they should be able to compete in the long run with Microsoft and others. The challenge I guess, is knowing when to start focusing on the harder problems.
- 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.
A recruiter just toss out my application to my dream job since other applicants had "more stars on their git".
And the company is not your average IT sweatshop (big very sucessful company, names starts with an A).
They might be glad to know she's filtering candidates based on that, because they can talk to her about it. It could lead to you getting an interview.
What's the worst that could happen?
We need them, because creating and maintaining hiring pipelines is a full-time job, but we know (and the recruiters should also know!) that they're working on a best-understanding of the job they're recruiting for, and that best-understanding is not a complete understanding, since they don't do that job. It might have been a miss on their understanding of an explanation, it might have been a miss on whoever communicated the job requirements to them. But if you have a contact outside of the recruiter, you should 100% reach out.
As a side note, recruiters are not on your side, they're on their own side. Don't rely on them for anything, least of all securing your dream job.
"I've never seen this thing, except in this obvious and common case where it happens all the time, but other than that, literally never".
Mate :/
In general, my first step in deciding whether projects are good is to google "<project name> review", and see what other developers and sysadmins have experienced with it.
I have often found that a 5 stars system contains inadequate information density to provide me with guidance on the suitability of one project over another with respect to integrating it into my companies tech stack, although I appreciate that's a personal standpoint and that you may disagree.
A project with lots of stars and rare commits is almost never better than one with a less stars but low-grade continuous activity.
"Date of last commit" is probably FAR higher than any "social" bullshit in terms of quality.
That's the first thing I look at when I arrive on a github page, always.
Buying into and supporting this behavior is just digging an increasingly deep hole. If you don't want github commits (and an agreement to the github terms of use) to be a mandatory part of all developers lives and CVs, then simply continue being an excellent developer without making github commits that you don't want to make.
We're in an important stage of github adoption at the moment. Some recruiters think it's a critical signaling mechanism. If we buy into that, they will seem to be correct, and the companies they recruit for will allow them to continue with their methodology. Soon, they will become correct because all career-oriented developers will feel compelled to work on github based open source projects to the exclusion of other open source projects, even if they don't actually give a shit about the projects they are working on.
However, if the companies they recruit for see high quality developers going to the competition because their recruiters are dismissing people out of hand for not being on github, those companies will eventually tell their recruiters to pull their fingers out and do some proper legwork.
The correct approach is to starve out this behavior while the cost of doing so is relatively low, not buy into it.
The cost is pretty high to bobsam, who didn't have a chance to interview for his dream job.
Not "playing the game" only works if all good developers stop using GitHub, no?
As I said to him in my directly reply to his post, acquiring an interview for ones dream job is a task best not left to others.
In relation to our specific discussion, ultimately one developers loss of their dream job is not a huge cost. We are looking down the barrel of a future where github can pick and choose who is employable and who is not, and therefore who makes key technical decisions at major vendors and who does not, by banning github accounts for political reasons. That has knock on effects for things like key standards decisions, and that's when the costs of refusing to conform start mounting. I basically don't trust companies with that kind of power.
I'm not a fan of recruiters incentivizing "required" side-work. That's the time you dedicate to all other important things in your life (which could be a side project, but it is not in most cases)
I can only assume recruiters very much consider this when they don't know anything else about you.
*Edit: Thanks for the downvote, but seriously - have you? If you haven't - It's more constructive to do that so civilised production direction and development discussion may take place in the official centralised forum rather than having outbursts on HN.
They could whip something together just from their server-side analytics so it was more honest rather than a popularity contest.
Maybe some of these are already implemented and we mostly need to get the devs to use them more frequently?
For free...