Re: 4.7 release notes early?

On Thu, Feb 10, 2011 at 6:15 PM, Justin Kirby <[email protected]> wrote:

>
>
> On Thu, Jan 27, 2011 at 5:09 AM, Sebastian Kügler <[email protected]> wrote:
>
>> On Thursday, January 27, 2011 01:36:02 Vivek Prakash wrote:
>> > On Wed, Jan 26, 2011 at 5:12 PM, Albert Astals Cid <[email protected]>
>> wrote:
>> > > A Dimecres, 26 de gener de 2011, Markus Slopianka va escriure:
>> > > > Hi.
>> > > > I was thinking we could start the 4.7 release notes early. They
>> could
>> > > then
>> > > > also serve for the betas and RCs.
>>
>> Good call, Markus.
>>
>> > > And translators will have more than -5 seconds to translate.
>>
>> Indeed.
>>
>> > Let's use https://promo.notes-dev.kde.org/14 for it.  I've inserted the
>> 4.6
>> > announcements as a template.. as the 4.7 feature plan [1] is updated,
>> let's
>> > clear out the old information and replace it.
>>
>> Probably best is to start with empty categories: Plasma, Apps, Platform
>> and
>> fill in bullet points there, otherwise it gets too hard to distinguish new
>> from 4.6 items (yes, can really be an issue, not know when exactly
>> something
>> was added). The text for the individual items needs to be written
>> completely
>> anyway, so I think it's better starting with a clean slate.
>>
>
> Just to take this a step further, can we brainstorm a bit about how to
> improve the process of translating the "Feature Plan" page into the "Feature
> Guide" and "Release Announcement" products that we create?  Right now the
> process is tedious and there appears to be low motivation to get it done.  I
> think if we make the tasks of creating these things easier then more people
> will be willing to help.  So how do we do that?
>
> Basically every time a new release comes out I always wonder the same few
> questions:
>
> * What changed from last time?
> * Would an end user care about this change?  If so, why?
>
> Just looking at the existing Feature Plan for 4.7 when I read a lot of
> what's on there I think that maybe that's nice for helping developers keep
> track of tasks, but much of what is there is not something users will care
> about.  Conversely there are things that users *would* care about, but
> they're explained in such a short cryptic manner that I have no idea what
> the change really is without either emailing the developer or searching back
> through posts on Planet KDE to see if they happened to blog about it or
> something.
>
> So how can we change the process so that we can not drive developers crazy
> with extra work, but also make it easier on our team to figure out what is
> really important about this new release so that we can clearly explain this
> to our user community?  I have a couple of suggestions to get the ball
> rolling, but I would really love some feedback from developers who may be
> following this list as well as the rest of the promo group...
>
> 1) In the Feature Plan page we add a column called "Importance" and
> developers can put either "major" or "minor" to signify if the feature is a
> big deal.  Perhaps we don't even bother putting "minor" changes in the
> Feature Guide, and those things are only mentioned in the full release notes
> or tracked on the Feature Plan page? (I don't even know how release notes
> are generated to be honest)
>
> 2) In the Feature Plan page we add a column called "Blog URL" which
> developers could use to post a link to a blog entry that summarizes the
> feature more verbosely, ideally explaining in that blog entry why users
> should care about this feature
>
> 3) I already see in the etherpad doc that was created that there is some
> question over whether Marble should get a spotlight mention in the main
> release text.  Should we add a column to the Feature Plan page that allows
> people to request consideration for such a mention?  That way if there are
> doing some really huge overhaul and feel that special attention is deserved
> for this we can be aware of it?
>
> Ok, so that's just a few thoughts anyways...what do you all think?  And
> what other suggestions do you have for improving this process?
>
>
>
>> We also need to poke developers somewhat regularly to update the Feature
>> Plan.
>> I'll do that just now, in fact.
>>
>
> How do you go about doing that?  I've wondered more than once if there is
> some master mailing list we could use to alert all the developer groups
> about something...or do you have to mail individual lists or specific
> people?
>

Doh...I should read all my email before I start responding.  I just got to
the one where you pinged a bunch of the developers about this :)  Thanks for
putting the plug in about making it human readable...that's a good start
towards some of the issues I described above!

-Justin


>
> -Justin
>
>
>>
>> > [1] http://techbase.kde.org/Schedules/KDE4/4.7_Feature_Plan
>>
>> Cheers,
>> --
>> sebas
>>
>> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>>
>> _______________________________________________
>> 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.
>>
>
>

 
_______________________________________________
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.