Defining a Release Target before development cycle starts

While reading the proposal "Branding Terms for Releases" [0] it came
to my mind that it could be easier to think of an Release
Announcement-title when there is a Release Target for each of the
components.  Maybe we should define and communicate (more, if already
done) our target before the development cycle starts.

Advantage 1: It cuts down the options for those who (have to) make up
the titles. e.g.
Advantage 2: Everybody in the same direction, facing the same problems
and focusing on the same category of solutions.
Advantage 3: 'We' don't forget an area to work on

[0] https://promo.notes.kde.jefferai.org/34?

==================
Advantage 1: It cuts down the options for those who (have to) make up
the titles. e.g.

"Let's focus on Usability for KDE Workspaces 4.7" can lead to "KDE's
New Workspace Notifications Put You in Control"
Sure, there can be 20 fixes that makes Workspaces faster and 14 new
fancy plasmoids but the Target was Usability so let's pick one of the
20 huge Usability-improvements. (20 options instead of 54)

"Let's focus on Optimalisation our Platform" can lead to "KDE Platform
Gains 20% More Speed After Optimalisation"
There can be 20 new features, 200 important bugfixes and a dead bunny
but the Target was Optimalisations so let's figure out a title for
that.

==================
Advantage 2: Everybody in the same direction, facing the same problems
and focusing on the same category of solutions.

I quote a planetKDE entry about advantages of having a strategy.[1]

"A good strategy should
1. show your major future challenges and provide an answer to those challenges,
2. point into a direction where the team wants to move and
3. unite the team."

If all people working on Applications would have a 'extra' focus on
Code Optimalisation then the blogpost from Michael Pyne "Speed up!"
would be extra important. For half a year there would be more than
average posts about Optimalisation. Aaron (for example) could focus an
IRC-meeting at the best way to use certain KDE software features in
Plasmoids (without 10 people asking for new features or how to make a
theme) . See [3] first comment as example of such an Optimalisation
thats should be known by all Plasmoid-scripters.

[1] http://ungethym.blogspot.com/2010/09/strategy-is-mighty.html
[2] http://www.purinchu.net/wp/2010/09/13/speed-up/
[3] http://kde-look.org/content/show.php/Facebook+Widget+%28fixed+for+real%29?content=125846

==================
Advantage 3: 'We' don't forget an area to work on

Bluntly: Programmers tend to forget Usability, Programmers with a
brand new idea tend to forget Optimalisation/Rewrite and Usability
experts don't care about any code at all.

Programmers A is all about functionality and never minded about any
polishing of his applications look. Programmer B does have an
application that looks amazing, but there is just not enough
functionality. With a clear target on 'New Features' programmer B
could ask programmer A for help. The next half year the target could
be 'Make it shine' and prog.A could ask prog.B for help. At this
moment they can do so as well, but there is a chance prog.A would
never think about polishing and prog.B would work till death _only_
polishing his application becase he is not such a great programmer.


Regards,
Bart Otten
 
_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription.