[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-promo
Subject:    [kde-promo] suggestions for next release process:
From:       Danil Dotsenko <dd () accentsolution ! com>
Date:       2006-05-31 21:21:42
Message-ID: 200605311421.43187.dd () accentsolution ! com
[Download RAW message or body]

These are just practical milestones, stage change triggers for release notes 
production. Having these around would shure help, at least me.

It is designed to accommodate short cycle - up to a week before the release.

I. BRAINSTORMING (finding selling points)
   Medium: PLAIN TEXT, email, through kde-promo
   Completion Time frame: 1-2 days.
1-2 day session when everyone throws out bullet lists of "sell-able" new 
features. Note: try to prioritize your bullets. The top 2-3 winning bullets 
will go into the "Extremely short summary sentence", with the rest going into 
"These changes include:" End of day 2 brings this stage to completion. (May 
be called earlier, by 5-8 votes)
When posting try to sift through the already posted things and COMMENT on 
their note-worthiness. Next commentor, please, include the previous bullet 
comments as well (and  edit them for size plz). This way, hopefully, the last 
email on the subject will have all the bullets with all the comments.
Also, attach "presentable phrasing / sentences" proposals to the bullets you 
like / want to be included.

Example:
- Coverity stuff 
  D.D. Priority High. possible text "significant number of potential code 
quality issues was found and resolved through automated system provided by 
Coverity"
- Start up improvements 
  D.D. Priority High (was it even for 3.5. branch? can we put it here?)
- etc..

II. FORMATION OF "SUBSTANTIVE" TEXT OUT OF BULLETS
  Medium: PLAIN TEXT or ODF (preferred) attachments, email, through kde-promo
   Completion Time frame: 1-2 days max.
Aim SHORTER and LESS questionable things, like mistakenly assigning 4. fixes 
to 3.5. No computerize. Aim is to make it "sound" (as in verbal noise) good 
as well as have some content.
3-4 edits / editors and this thing should be done. Further edits bring 
diminishing return, bickering about wording. 3-4 votes bring this stage to 
completion.
My personal approach to this: Release notes are mostly to tell people that you 
"released" something. If it's easy to add "flavor" to release, do it. If 
finding, documenting and phrasing "cool new features" is hard - release just 
plain, dry "release notes". Try to be creative with change log and spice that 
up separately. No matter how many days you spend on "inventing" cool 
features, the release is still the same release. Ppl will know.

III. MEDIA SPLIT OFF POINT
  Completion Time frame - 1-2 days.
 At this stage, 
 - "text" (ODF?) version is created (and frozen?) for e-mail distribution and 
general presentation. (can be sent to translators)
 - php version is started. It's sole goal - inclusion into kde.org.  No 
significant text changes. The following files are affected:
www/announcement/announcement-#.php
www/info/#.php
www/index.php
PHP should have 3/4 (circular) edits / editors / people looking at it and 
giving written OK. At that stage it's off to Adriaan, who seems to have 
new-found commit powers.

-- 
Danil Dotsenko

 (\ /)
(O.o)
(> <)
 
_______________________________________________
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.


[prev in list] [next in list] [prev in thread] [next in thread]