4.10 reflection summary

[Aaron J. Seigo]

hi...

i hope i capture all the feedback below, if i missed something, please say so 
in a reply to this email :)

Question: how do you think 4.10 went?

Answers: Consensus seems to be that some good things were done, but few, if 
any of us, were truly satisfied with the 4.10 cycle.

Commentary: This is not the most wonderful news, but it is wonderful we can 
state it openly as a group and use it as motivation to move forward.


Question: What do you feel are the "defining" accomplishments for the desktop 
workspace in 4.10? (e.g. the positive things people will talk about when they 
get 4.10) .. and ... What do you personally like about the results of 4.10?

Answers:
* lots of mentions of QML progress. consensus appears to be that we're on the 
"right" track with this
* artwork
* some cool new features, such as appmenu integration, that probably could use 
some additional exposure in future releases as they mature

Commentary: So we accomplished things we're all happy with. That's great, as 
it definitely reminds us things are in any way completely broken down and are 
still doing great things. :)


Question: What did you not like about the 4.10 development cycle?

Answers: The answer seemed pretty unanimous in that we did not like the lack 
of:
* quality control
* lack of bug triage
* coordination between components
* communication.

Commentary: The agreement on this question shows that we experienced this dev 
cycle in very similar ways. We have lots of common ground, and that's an 
awesome place to start from when trying to make things better.


Question: What would you like to be done the same way in 4.11?

Answers: None. Literally *nobody* answered this question.

Commentary: Perhaps this shows not only how much harder it is to pick out 
positives when doing introspection like this, but how little focus we allow 
ourselves to have on what we are doing well.


Question: What would you like to be done differently in 4.11?

Answers: Various suggestions included
* get more developers using master
* get more users trying out pre-releases (work with distros for this)
* develop a realistic and effective strategy for handling bugs.kde.org
* get maintainers for all, or at least *more*, components. this implies more 
maintainers over all.
* have "super" / "release" maintainers to compliment the efforts of component 
maintainers:
	* ensuring there are active maintainers (e.g. noticing when one is gone)
	* ensuring needed communication happens between component teams (shadows 
being a great example of where that didn't happen)
	* ensuring the "big picture" goals are seeing progress

Commentary: What more needs be said, really? :)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130114/a6f7529b/attachment.sig>