Releases in 3 months

[Nuno Pinheiro]

A Quarta, 10 de Julho de 2013 13:18:57 Aaron J. Seigo escreveu:
> == On branding and visual presentation
> 
> some have noted that faster release cycles would make it hard to  implement 
> branding updates and artwork refreshes such as wallpapers. the answer to
> that is simple: these efforts must not be tied to the development cycle.
> 
> the development cycle has for too long dictated the pace of everything
> else,  even though “everything else” does not follow the same natural pace
> of development!
> 
> in the case of artwork, my proposal would be to aim for exactly one refresh 
> per year. do it in the new year, perhaps? the first release of every year
> could come with a visual refresh and a branding refinement.
> 
> this would give us a full year to draft and implement these changes.
> 
> my experience with the branding and visual side of our efforts is that the 
> areas that get touched  by these changes are very, very rarely touched by
> the  development of features or bug fixes. so these efforts could have a
> release cycle of 1  year while the source code development could have a
> release cycle of 3 months (or whatever)
> 
> i think this would actually make the changes more impactful on our users
> and  ease the burdon on our art and branding teams
> 
> == On marketing
> 
> marketing needs to be separated from development cycles.
> 
> there is  no  reason that marketing could not do a twice-yearly big splash 
> announcement about releases that highlights the current status and major 
> progress points of KDE software. note that i did not write ‘KDE SC’. these  
> pushes should try to include a broader picture that includes the
> frameworks, the workspaces and applications across the KDE community. why
> shouldn’tAmarok or K3B or Digikam or Calligra pumped in those
> announcements?
> 
> there could be a january and a july PR push that woudl pull together all
> the  changes, all the important bits, etc. releases of the SC between those
> could be released with simplified annnouncements with less fanfare much as
> we currently do the monthly maintenance updates.
> 
> it could be even be more dramatic of a change of course: there could be just
> a  single annual Big PR Splash with the rest of the year being filled with
> smaller and more regular PR announcements.
> 
> or maybe all releases are done with a simple announcement and instead of
> tying  announcements to releases, a “KDE Magazine” is put out much as KDE
> e.V. does with quarterly reports that covers the last N months of activity
> in KDE.
> 
> in any case, the idea that development cycles dictate when we speak to the 
> public is an anachronism. it really does not have the major impact many of
> us  may think it does because we are no longer a young exciting project
> (which means we are most repeating ourselves, which is boring) and our
> bi-annual announcements not only skip over non-SC software but it is does
> not create much attention-grabbing engagement with people, something a
> magazine would do much better at.
> 
> imho, marketing should should be thinking outside the box and release 
> schedules should not be tethered to those efforts.


I realy like this ideas :) 
In fact this would be beter than what we have now, IMO.
If we can coordinate the big splash ones, wille providing users with a flux of 
new features more often, I can only see a win win situation here. brading we 
still get the "big new and improved" versions that the media take notice, 
combined with visual difrences that they actualy can see.