On Mar 6, 2006, at 12:54 PM, Pieter Hartsook wrote:
Comments in-line.
Pieter
==================
Proposal:
+ The chandler.osafoundation.org would continue to be used as the
project
page for Chandler and updated per alpha release (detailed below).
+1
+ We will update the Chandler splash screen to say "alpha1",
alpha2" etc.
I assume that would be 0.7 alpha1, etc. not just the alpha1 part.
Yes that's right.
+1
+ The main release number and the download link (big button) on
the main
page would NOT change. It would only change if there was another
0.6.x.
Instead there would be a secondary link below the "big button"
that points
to a download of the 0.7alphax.
Since we are in between the official 0.6 and 0.7 releases I can see
leaving the 0.6.x on the timeline header, but maybe at this point we
should have the download links (the green arrow and the OS names) no
longer be one-click downloads, but instead take the user to a
secondary page explaining and offering the choice of the stable 0.6.x
version, or the 0.7 alpha release. My guess is, most downloads at this
point will be the alpha versions -- so you get to see and try out new
features. This secondary page explaining the difference between the
0.6 branch and the alpha release might also have a few screenshots
available to highlight new UI features like list grouping. I agree
that we don't need to do major work on updating the documentation at
each alpha release, but at the same time if there is some significant
new information that we have, we should make that easily available and
not hold it for the next dot release.
Rationale: There has been some debate about whether we want to
replace the
main download link with the alpha release and whether it's
practical or
necessary to have a 0.6.x if we are wanting dogfooders to get the
latest
alpha. First of all, the alpha is not an official release.
Although we want
to have the bar really high on these alphas, there are some
fundamental
differences in the completeness of the packaging. I think it makes
sense, to
keep a link to whatever the last official release is. If we change
the
numbering on the main page and the "big button" download, this
implies we
need to update the main page text, the readme, developer docs etc.
This then
turns into a major non-code release project and this is not
practical to do
every 2 months. We would give the user a choice to get the last
official
version or something more experimental and up to date.
+ A news section or news link (design TBD) would be added to the main
project page to highlight the alpha release and associated
documentation.
+1
See my comment above, I think this same news information should also
be repeated or linked to from an intermediate download page where the
user would have the option to choose the .6 branch or the 0.7 alpha
trunk.
Sure, that sounds reasonable.
+ Every alpha will have a self-contained readme page with
information. The
level of content is similar to the milestone report cards we had
for 0.6
milestones.
-> There is a link to any relevant documentation.
-> There is a list of features that work, don't work or are
experimental.
-> There is no detailed step-by-step instructions on how to use
certain
features.
-> Major bugs and regressions are listed.
+1
this should replace the ReadMe text file that gets launched after an
installation.
This text currently just points to the landing page. Do you mean we
should change that.
+ There are no special demos, screen shots etc. for an alpha
release. The
existing demos/screens shots for 0.6 would remain on the project
page.
-1
see my comment above. I think there should be "some" screen shots
showing new UI available for the 1st time in this alpha release, e.g.
list grouping.
Where would you put this? On the readme. Keep in mind that some of
the UI will be "test UI". For instance, we will likely not have the
search box in the toolbar until alpha 3 but have a popup search
dialog in the interim for alpha 2. It doesn't make sense to show some
temp UI that probably won't look great anyhow. Perhaps the right
approach will be to evaluate this per release. For example, it may
not be appropriate to have screen shots in alpha 2 but maybe for
alpha 3.
+ The alpha release will be announced on the lists and the blog
+1
We would also announce on the www.osafoundation.org home page.
+ Developer documentation (if appropriate) will be scheduled for
the alpha
release like any other feature.
Please send replies to the list by end of day Monday (Mar 6th).
Sheila
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
