[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]