[phoenix-dev] Meeting minutes - March 31 2006 14h00 Eastern

[Denis Roy <denis.roy@xxxxxxxxxxx>]

Started the call with a "How do you feel about being a Phoenix 
Committer" management ploy to encourage us to put more time in our 
website - we don't want it to get stale.

1. Release cycle
- Phoenix does not need to follow a strict release cycle
- We are to drop release numbers
- eclipse.org-common should be published to www.eclipse.org as needed.  
To get common code published to www.eclipse.org, committers should
a) send an e-mail to the phoenix-dev list asking for this
b) include bug numbers corresponding to all changes so code can be reviewed
- Each time eclipse.org-common is published to the live site, I will tag 
the CVS repository with the date
- We need more peer review for our code, as defined:
 a) large change: anything inside eclipse.org-common must have an 
appropriate bug report, requires approval from majority of Committers 
(changes to CSS, nav bars, look & feel, etc)
 b) medium change: Look & feel change to the home page and all 6 main 
landing pages (Community, Downloads, Projects, etc.) requires 
appropriate bug report and at least one +1
 c) small change: any content on any page not covered by the above - 
doesn't require a bug and doesn't require peer review.

2. WYSIWYG
- The core team does not *need* WYSIWYG, although it would be nice to have
- [Denis] Ask projects what is blocking them from moving to Phoenix to 
see if we have new requirements

3. Performance considerations for your pages
- Reiterated the need to write clean code, and avoid using the web service.

4. Bugs and new features
- Reminded committers that there are open bugs in Community/Website and 
Technology/Phoenix.
- Had a discussion about "When does a bug turn into a Mandate?"  ie. one 
user opens a bug claiming we should do X.  We agreed that:
a) the higher the impact/risk, the more committer and community support 
we need
b) a request/subjective bug that goes 6 months without any 
comment/vote/additional support can be closed WONTFIX.
c) bugs for which we do not have the resources can be labeled 
"helpwanted" to sollicit patches/code from the community.

5. Documentation strategy
- We agreed to move all our documentation to wiki.eclipse.org to allow 
everyone to easily update it.

Action items:
[Denis]: Ask projects what's preventing them from switching to Phoenix
[Denis]: Move all Phoenix docs to Wiki

Susan, because you weren't at this call, please feel free to add your 
comments/insight, or give me a call so we can talk.

Thanks,

Denis

--
Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc.
Office: 613.224.9461 x224
Cell: 819.210.6481
denis.roy@xxxxxxxxxxx