Re: Defining a Release Target before development cycle starts
Stuart Jarvis <[email protected]>
| Newsgroups | gmane.comp.kde.events |
|---|---|
| Message-ID | <201009151220.52095.stuart.jarvis__5953.88273145563$1284549706$gmane$org@gmail.com> |
On Wednesday 15 September 2010 12:05:31 Bart Otten wrote: > 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. Good idea. When looking for 'the story' for release announcements at the moment we tend to be scrabbling around in the feature plans on techbase (which tend to be incomplete) and looking through blog posts to try and find things to talk about. KDE churns out a load of stuff and we try and make up a story based on that. > 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 Advantage 4: We can check afterwards how well we met our targets and work out how to do it better next time. > [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. Yep. We can't implement a top down approach of "do this" (and I'm not sure that would be desirable) but having a theme could guide people in particular directions. Cheers, Stu _______________________________________________ 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.