Difference between revisions of "E4/Meeting Minutes/Status 20131031"

From Eclipsepedia

Jump to: navigation, search
(Attendees)
(Minutes)
 
Line 15: Line 15:
 
Thoughts on planning process
 
Thoughts on planning process
 
* Would like to avoid having to repeat the process every year
 
* Would like to avoid having to repeat the process every year
* nice to have a live view that we can update
+
* Nice to have a Dashboard so we can see our progress.  For now, only have [[Platform UI/Plan/4.4/Milestones]].
* setting target milestones triggered many emails
+
* Like the idea of weighting the input.  So instead of simply summing n, we would sum 2^n
 +
* We would always need to include the SR2 work when doing our planning
 +
* We should make the planning take place the first 2 weeks right after we declare SR1
 +
 
 +
Some potential problems with the current approach
 +
* Current approach generated a lot of emails - perhaps use tags to scope the bugs initially so the only emails are for bugs that are accepted.  This reduces churn, but the downside is you can't tell if a bug you are interested in was accepted for consideration, only if it was actually accepted
 +
* Planning was pretty late this year, which can interfere with momentum

Latest revision as of 12:47, 1 November 2013

[edit] Attendees

  • Wojciech
  • Dani
  • Paul^2
  • Eric
  • John

[edit] Minutes

EPP packages still having JRE problems on Mac Looking at problems with rendering on split views Nearly ready to declare M3, last minute smoke testing

Thoughts on planning process

  • Would like to avoid having to repeat the process every year
  • Nice to have a Dashboard so we can see our progress. For now, only have Platform UI/Plan/4.4/Milestones.
  • Like the idea of weighting the input. So instead of simply summing n, we would sum 2^n
  • We would always need to include the SR2 work when doing our planning
  • We should make the planning take place the first 2 weeks right after we declare SR1

Some potential problems with the current approach

  • Current approach generated a lot of emails - perhaps use tags to scope the bugs initially so the only emails are for bugs that are accepted. This reduces churn, but the downside is you can't tell if a bug you are interested in was accepted for consideration, only if it was actually accepted
  • Planning was pretty late this year, which can interfere with momentum