Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added numbers to make references easier

...

Discussion Topics/Issues (draft)

Issue 1: When do we know that a project is "done"? What are the end-of-life criteria?

Proposed/Draft Resolution 1:

When a project has not had any new releases for over 6 months, it should be moved out of Active status into "End of Life" status, pending TSC approval.

Issue 2: What are the criteria for a "First Major Release"? How does Dave's proposed Project Readiness fit in?

Proposed/Draft Resolution 2:

<insert here any criteria from Dave's Project Readiness proposal that do not pertain to what would be considered for graduating to "Active" status, which is handled separately.>

Issue 3: What criteria/steps/policies must other releases adhere to?

Proposed/Draft Resolution 3:

TBD

Issue 4: Under what circumstances can (or what are the criteria for) a project (to) be moved back to Incubation? to a lab?

Proposed/Draft Resolution 4:

When a project has not managed to graduate to Active status 2 years after having entered Incubation it should be moved to a lab, pending TSC approval.

Issue 5: Should all projects be required to start as a lab prior to being proposed for Incubation?

Proposed/Draft Resolution 5:

The normal path for projects is for all of them to first start as a lab prior to being proposed as a project. Requests for derogation can be made to the TSC.

Issue 6: Should we have subprojects (and fewer toplevel projects)?

Proposed/Draft Resolution 6.1:

No. Existing projects already have various forms of subprojects which are left under the governance of each project. There is no need for the TSC to get into that micromanagement of the projects and subprojects. Of course, if any conflict were to rise between a project and one or more of its subprojects the issue can be brought up to the TSC for arbitration.

Proposed/Draft Related Resolution 6.2:

Existing projects that in practice are not being managed as "top level projects" should be officially rescinded from the top level nomination for house keeping purposes.

Proposed/Draft Related Resolution 6.3:

Projects that are dependent of one of the other projects should be folded under that project. This means Composer becomes Fabric Composer, Explorer becomes Fabric Explorer etc.

Issue 7: How/when does a project get officially names? (Early → easier to set up repository, Later → marketing committee can be involved, see mailing list for discussion)

Proposed/Draft Resolution 7:

Option 1: Ask the marketing committee to pre-approve a list of names that are catchy and not descriptive.

Option 2: Two phases for naming, the proposal comes with a temporary "code name" (e.g. a geographical location) that can be used for the repository with low risk of trademark violation. On approval, the marketing committee works with the proposers to create a long term name and does all checks. The repository name can be edited.

Issue 8: How do we deal with a new project coming in that is already a shipping product for a company?

  • Assuming it would need to pass Dave's proposed Project Readiness
  • It could be a bad look for a company to donate shipping code and then have it wallow in incubation
  • does it come in at the current shipping version ?

Proposed/Draft Resolution 8:

TBD

Comments

Hart:

I'd like our project lifecycle to satisfy three basic requirements:

...