5 ms·

Thank you for the explanation. I've created an issue. Feel free to continue the discussion there. https://gitlab.com/gitlab-org/gitlab-ce/issues/44553 https://

Thank you for the explanation. I've created an issue. Feel free to continue the discussion there. https://gitlab.com/gitlab-org/gitlab-ce/issues/44553 https://gitlab.com/gitlab-org/gitlab-ce/issues/44553

tmuir 8y ago
Does this mean that gitlab doesn't generally employ people to simply learn their competitors products, to keep informed of their offerings?
- yashap 8y ago
  This is a highly unfair criticism, you’re never going to have total feature parity with your competitors, nor is that even a good thing to strive for.
  - deleted 8y ago
    [deleted]
  - tmuir 8y ago
    Mine is a perfectly valid criticism. You do nobody any favors by conflating the goal of total feature parity with the general concept of business intelligence, and understanding your direct competitor's key features. The strawman you float is the complete opposite of what I asked. It simply occurred to me as strange that there are features that meet all of the following requirements: 1. Available on github for quite sometime 2. Long enough in fact to get a dedicated article in their knowledgebase 3. A popular enough feature to possibly gate the entire calculus for users to switch services. 4. Obviously useful feature, as evidenced by the gitlab triage engineer being convinced to add an issue with a single paragraph plea. 5. Gitlab is seemingly unaware of this publicly available information, to the trivially rectified detriment of their own bottom line.
    - parent5446 8y ago
      You seem pretty worked up about this one feature. > 3. A popular enough feature to possibly gate the entire calculus for users to switch services. I'd say GitLab's CI/CD system is a lot more useful of a feature. At the very least you can use the actual git blame or another git UI as a workaround. Good luck setting up a replacement CI/CD system. > 4. Obviously useful feature, as evidenced by the gitlab triage engineer being convinced to add an issue with a single paragraph plea. That's not how triage works. Just because a bug is filed doesn't mean it's "obviously useful". If the employee had immediately given it a high importance, a release date, and assigned it to somebody, that'd be a different story. > 5. Gitlab is seemingly unaware of this publicly available information, to the trivially rectified detriment of their own bottom line. Well, since there is another bug already filed for this feature more than six months ago, [0] I'd say they are quite aware, they just don't consider it as important as you do. The particular person that replied to you just didn't know about it (not surprising when they have more than 10k bugs open). [0] https://gitlab.com/gitlab-org/gitlab-ce/issues/37135 https://gitlab.com/gitlab-org/gitlab-ce/issues/37135
      - tmuir 8y ago
        You seem to baselessly project negative emotions and motivations on to your interlocutors in lieu of coherent points that actually refute their arguments. chinhodado, the GP, framed his feature request as one of the major reasons he is forced to continue using github. Gitlab's motivation for the very feature this thread is regarding, is to poach github customers, or at the very least, increase their customer base by giving people a smoother onramp to transition from github. More power to them. The feature he describes does, in fact, have obvious utility, which is why it was so strange to me, someone who only uses gitlab for its most basic features, to see the exchange with the gitlab engineer. Surely a company with the venture capital that gitlab has raised would perform the basic ongoing market research that any company in nearly any competitive market performs. It honestly made me wonder if gitlab on one hand, realizes that they need to inform themselves of useful features, but for whatever reason, doesn't avail themselves of github's features.

tmuir 8y ago

Does this mean that gitlab doesn't generally employ people to simply learn their competitors products, to keep informed of their offerings?

yashap 8y ago
This is a highly unfair criticism, you’re never going to have total feature parity with your competitors, nor is that even a good thing to strive for.
- deleted 8y ago
  [deleted]
- tmuir 8y ago
  Mine is a perfectly valid criticism. You do nobody any favors by conflating the goal of total feature parity with the general concept of business intelligence, and understanding your direct competitor's key features. The strawman you float is the complete opposite of what I asked. It simply occurred to me as strange that there are features that meet all of the following requirements: 1. Available on github for quite sometime 2. Long enough in fact to get a dedicated article in their knowledgebase 3. A popular enough feature to possibly gate the entire calculus for users to switch services. 4. Obviously useful feature, as evidenced by the gitlab triage engineer being convinced to add an issue with a single paragraph plea. 5. Gitlab is seemingly unaware of this publicly available information, to the trivially rectified detriment of their own bottom line.
  - parent5446 8y ago
    You seem pretty worked up about this one feature. > 3. A popular enough feature to possibly gate the entire calculus for users to switch services. I'd say GitLab's CI/CD system is a lot more useful of a feature. At the very least you can use the actual git blame or another git UI as a workaround. Good luck setting up a replacement CI/CD system. > 4. Obviously useful feature, as evidenced by the gitlab triage engineer being convinced to add an issue with a single paragraph plea. That's not how triage works. Just because a bug is filed doesn't mean it's "obviously useful". If the employee had immediately given it a high importance, a release date, and assigned it to somebody, that'd be a different story. > 5. Gitlab is seemingly unaware of this publicly available information, to the trivially rectified detriment of their own bottom line. Well, since there is another bug already filed for this feature more than six months ago, [0] I'd say they are quite aware, they just don't consider it as important as you do. The particular person that replied to you just didn't know about it (not surprising when they have more than 10k bugs open). [0] https://gitlab.com/gitlab-org/gitlab-ce/issues/37135 https://gitlab.com/gitlab-org/gitlab-ce/issues/37135
    - tmuir 8y ago
      You seem to baselessly project negative emotions and motivations on to your interlocutors in lieu of coherent points that actually refute their arguments. chinhodado, the GP, framed his feature request as one of the major reasons he is forced to continue using github. Gitlab's motivation for the very feature this thread is regarding, is to poach github customers, or at the very least, increase their customer base by giving people a smoother onramp to transition from github. More power to them. The feature he describes does, in fact, have obvious utility, which is why it was so strange to me, someone who only uses gitlab for its most basic features, to see the exchange with the gitlab engineer. Surely a company with the venture capital that gitlab has raised would perform the basic ongoing market research that any company in nearly any competitive market performs. It honestly made me wonder if gitlab on one hand, realizes that they need to inform themselves of useful features, but for whatever reason, doesn't avail themselves of github's features.