Added a couple of sentences detailing how we should decide on features CE or EE
Having followed several issues that led to discussions whether a specific functionality needs to be CE or EE I realized our definition on how we decide on features for EE is not specific enough.
The latest issue which was a catalyst in my eyes was https://gitlab.com/gitlab-org/gitlab-ce/issues/4058. I realized that this is exactly the line to follow - if the functionality we're introducing makes using GitLab easier on our core functionality (issues, code review etc.) it should be available to all. I think issue #4058 is a good example of that - making it easier to find other issues and finding duplicates improves on the ease-of-use for Issues.
If we're considering introducing functionality that makes using GitLab more efficient or helps handle complex situations like: handling permissions, merge approvals and reporting that functionality should be considered for EE.
I tried to keep this introduction short and clear but understand it likely needs work on as far as phrasing it properly.
Merge request reports
Activity
/cc @JobV
I don't think we can make such a blanket statement, we'll have to review on a feature by feature basis. For example deploy boards make CD easier, nevertheless they are an EE feature.
The phrasing can be adjusted to reflect it more accurately. I strongly believe this is a suiting approach which will strengthen CE as a product, bolster the community support behind it, as we continuously make the product columns of CE better.
It also serves as boundary markers when we think about different features, giving us a precise tool to decide which feature needs to be CE or EE judging by added value on top of existing criteria.
@JobV WDYT?
I agree with @sytses here. The phrasing you added will make it harder to make things EE-exclusive.
In the end, everything we're doing is making hard things easier for everyone. This would blur the line even further.
