efsp/content/faq.html

<div id="preamble">
<div class="sectionbody">
<div class="qlist qanda">
<ol>
<li>
<p><em>How does the role of the Specification Committee differ from the role of the PMC? </em></p>
<p>The Project Management Committee (PMC) manages the technical governance process, and provides oversight. It ensures that the open source rules of engagement are observed and the Eclipse Development Process (EDP) as a whole is followed. It participates in the Intellectual Property Due Diligence Process to ensure that requests for review are technically sound (for example, to ensure that the use of third-party content makes technical sense). The PMC provides best practices. It tends to work more at the development and technical level.</p>
<div class="paragraph">
<p>The Specification Committee is responsible for ensuring that the rules and processes outlined by the EFSP are implemented by Specification Projects, that the integrity of the Scope is maintained (e.g. that release plans define changes that are in-scope), that community has been properly consulted, implementation is technical feasible, and that the Specification otherwise remains consistent with the goals of the Working Group.</p>
</div>
<div class="paragraph">
<p>The PMC is in the Project Leadership Chain; the Specification Committee is not. Approvals from both parties are required for Progress and Release Reviews.</p>
</div>
</li>
<li>
<p><em>If a Specification Project is archived, do the Final Specifications that it previously produced remain valid? </em></p>
<p>Yes. All previously created Final Specifications remain valid.</p>
</li>
<li>
<p><em>What does it mean for a Specification Project to be “under the supervision” of a Specification Committee? </em></p>
<p>A Specification Project effectively belongs to one Working Group. By aligning itself with a particular Working Group, a Specification Project agrees to take direction from the corresponding Specification Committee.</p>
</li>
<li>
<p><em>How does the Specification Committee manage the overall roadmap for the Specification Projects under their supervision? </em></p>
<p>How a Specification Committee manages a roadmap varies based on the nature of the parties involved. The Specification Committee may choose to defer this responsibility to one of the Specification Projects (e.g. a <em>Platform</em> Specification Project). The roadmap itself may take the form of a set of published guidelines or best practices, the implementation of a simultaneous release, or required themes and other elements in Release Plans. Ultimately, the Specification Committee should work with the PMC and the Project Teams to build consensus rather than impose rules.</p>
</li>
<li>
<p><em>What happens if a Review fails? </em></p>
<p>The party that fails (i.e. denies approval) the review is expected to provide feedback in the event of failure. The Specification Team will engage with the party to determine the correct course of action. That course of action may be to re-engage in the Review at a later date or take some other corrective action. In any case, the Reviews required by the process must be completed successfully to proceed to the next step.</p>
</li>
<li>
<p><em>What do I do if I feel that my Review was failed unfairly? </em></p>
<p>Follow the Grievance Handling process defined in the EDP.</p>
</li>
<li>
<p><em>How is the association of the artifacts of a particular Specification Version represented? </em></p>
<p>The Specification Committee should provide best practices to Specification Projects, for example, a standard metadata format.</p>
</li>
<li>
<p><em>What is the difference between a Specification Version and a Final Specification? </em></p>
<p>A Specification Version is produced by a release cycle, then becomes a Final Specification when it is Ratified (under the Eclipse Foundation Specification License (EFSL)).</p>
<div class="paragraph">
<p>The intellectual property rights required to build a compatible implementation flow from the Final Specification. That is, in order to be considered a Compatible Implementation and benefit from the intellectual property protections provided by the Eclipse Foundation Specification Agreement, an implementation must be based on a final specification. No claims regarding compatibility may be made for an implementation milestone build or unratified Specification Version.</p>
</div>
</li>
<li>
<p><em>What types of changes are not appropriate for a Service Release? </em></p>
<p>Changes to method signatures or additions of new methods or behavior (for example) are generally not considered appropriate in a Service Release. A Specification Team should consult with their PMC and Specification Committee to determine precisely what sort of review is required for a particular change.</p>
</li>
<li>
<p><em>Are Specification Projects required to implement the Eclipse IP Policy and engage in the Eclipse IP Due Diligence Process? </em></p>
<p>Yes.</p>
</li>
</ol>
</div>
</div>
</div>