Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "COSMOS PostMortem 1.0"

(Architecture or development)
(Architecture or development)
Line 16: Line 16:
 
==Architecture or development==
 
==Architecture or development==
  
# One thing we did with the SDD tooling team was hold a code review for their initial COSMOS contribution.  I would suggest we consider doing that at least once for other areas of the project in the 1.1 timeframe, time permitting.  Code reviews are an excellent way to level set everyone on our coding practices, and many defects are proactively discovered during those types of sessions.  They can be tedious, and are typically not the most fun for the person whose code is being reviewed, but the improvements to the code base and the developers themselves make them worthwhile.
+
# One thing we did with the SDD tooling team was hold a code review for their initial COSMOS contribution.  I would suggest we consider doing that at least once for other areas of the project in the 1.1 timeframe, time permitting.  Code reviews are an excellent way to level set everyone on our coding practices, and many defects are proactively discovered during those types of sessions.  They can be tedious, and are typically not the most fun for the person whose code is being reviewed, but the improvements to the code base and the developers themselves make them worthwhile.  One way to contain code reviews to a tolerable timeframe would be to review pre-selected snippets instead of tackling the full codebase.
  
 
==Testing==
 
==Testing==

Revision as of 11:49, 3 December 2008

This page captures the thoughts of the community on what went well in COSMOS 1.0 and what needs to be improved on going forward. Note that we don't need an entry in all of the categories below, and please create a new category if that makes sense.

Meetings

  1. Meeting chair also takes the meeting minutes
    1. It slows down the meeting when the chair says, "Hang on a second, let me note that down." Proposed from David Whiteman: rotating meeting minute taker. Everyone has a turn.

Development process

  1. Review and discuss the blog post discussing the Eclipse process and whether it is truly Agile. Most of it is really dealing with whether the process is enforced. Let's look at our project and see if we follow all of the 10 guidelines listed, and whether we need to change anything to help with that.

Documentation

  1. Consider whether, in the absence of a doc writer, we want to look at the wiki-to-eclipse-help converter described here. Of course that would mean we would need to get our docs moved from the current HTML location back to the wiki, but going forward that might make it easier for all of us to maintain the docs. If nothing else, it's something for SDD to consider since they don't have their user doc written yet.

Legal

  1. Do we want to segregate code that has pending legal approval in a separate zip file and add it into the main zip file once it's cleared Legal? Proposed from David Whiteman: attach 3rd-party dependent code to bugzilla until legally cleared.

Architecture or development

  1. One thing we did with the SDD tooling team was hold a code review for their initial COSMOS contribution. I would suggest we consider doing that at least once for other areas of the project in the 1.1 timeframe, time permitting. Code reviews are an excellent way to level set everyone on our coding practices, and many defects are proactively discovered during those types of sessions. They can be tedious, and are typically not the most fun for the person whose code is being reviewed, but the improvements to the code base and the developers themselves make them worthwhile. One way to contain code reviews to a tolerable timeframe would be to review pre-selected snippets instead of tackling the full codebase.

Testing

  1. Do we want to change the COSMOS dev process so that a person is forced to update a test case, or add a new test case, when a new feature is added? (Excluding doc features.)
    1. If yes, how can we automate a check for this? Build? Extend CVS check-in wizard?
    2. If not, what alternative to ensure test coverage of all COSMOS code?

Back to the top