Plug-in Check list

Contributing new function in a plug-in often occurs when features built in other products tend to reveal solid generic capabilities that all UI developers might want to use. In this case the process followed generally involves the following steps:

1. Existing plug-in is seen as a useful feature at the level of the Platform UI
   1. Ideally the plug-in proves itself by being shipped in 1 or more releases of prefereably multiple products
   2. Ideally requests from the community are being sent to Platform UI asking for this feature
   3. Always good to have at least two (2) scenarios ready that will be clients of this feature in to help solidify the robustness of the new API
2. Contact is made with Platform UI requesting the feature be moved down
3. Discussion over the feature ensues.
   1. If agreed upon, then committment is discussed.
      1. contributing team needs to provide 2 or more names of developers who will maintain the code
         1. NOTE: this means the exisiting Platform UI team generally will not absorb code in this case, you must continue to maintain it
      2. without this committment the code does not go in
4. Code reviews occur
5. JUnit Tests must be provided that verify the new feature
6. Once the tests and code are ready the projects are requested to be created along with user privilidges
7. Then the code is committed and made part of the builds

• Follow the Eclipse Platform's Standards, Conventions and Guidelines
• UI will need you to use project-specific settings for compiler warnings/errors, code formatting etc. that are copied from the other UI plug-ins' settings
• use "organize imports" (Ctrl-Shift-O) to clean up the imports (we do not use org.eclipse.* type notation)
• don't put CVS headers in the files (with revision information etc.)
• the copyright header goes before the package declaration, starting in the very first line.
  • It may be necessary to agree on a copyright depending on who is contributing the code
• commit comments are required for all code commits, bugs should be logged to track work and the bug number and a description is then used in the commit comment to describe the chagne. For example when fixing a bug, use "Fixed bug xxx: <title of bug>". Otherwise, describe what you did with a short sentence, this will help us track the changes
• before committing changes, catch up to all changes made by others, and then run the tests
• don't commit your changes if this will cause compile errors for others
• it is considered good practice to write code that does not have warnings. If possible, fix warnings existing whenever you see them, they can crop up due to compiler changes occassionally
• non-externalized strings are considered errors, do not ship non-externalized strings
• write/update Javadoc for all API you introduce/change. See Evolving Java-based APIs by Jim des Rivières to understand what it means to maintain an API

Bugs

New bugs related to this feature will be sent to you as owner. Please try and review all new bugs and respond as quickly as possible. We realize that you might have some other full time job to worry about, but we do expect some level of responsiveness.

Build Check List

1. Doug can you put something here?
   

Once you are a contributor/committer to Platform UI, you should be tracking the platform UI mailing list to watch for issues related to what you've been doing, and feel free to be part of other development discussions that affect your component. See the UI Development page for our mailing list information.

In addition you should follow the platform-releng-dev to track build and test failures in your component, upon seeing them in a build they should be immediately resolved.

• patches should be provided by way of bug reports with email to a committer if you need them applied