Am 03/19/2014 12:21 AM, schrieb Andrea Pescetti:
Rob Weir wrote:
On Mon, Mar 17, 2014 at 3:52 AM, Andrea Pescetti wrote:
Dave Fisher wrote:
No links to snapshots from the website. It is ASF policy.
It is not ASF policy. It is the way we have interpreted it so far.
I'm moving this to an own thread as per Juergen's request (but this IS
release-relevant: I'd like to have more visibility for dev builds in the
weeks leading to 4.1). And I'm leave the snippet above just to say that
"Policy forbids this" is not a killer argument in this case. If the
Apache policy gets in the way, we are probably applying it too
conservatively, and I heave elements to believe this is the case.
The problem is we cannot control what 3rd parties do. They can easily
deep-link to our dev build page directly, bypassing any "warning" page
that they might have.
Of course, they could do that today, to ci.apache.org, if they knew
about it.
Indeed, you already guessed the answer yourself: there's nothing
preventing people to link to ci.apache.org right now. And that link
shows up first in search engines for "openoffice daily builds". So if we
put an intermediate page with a proper disclaimer this will actually
help to get the message straight.
When 3rd parties promote unofficial builds, we can run into the
following problems:
1) Users get a lower-quality product and this hurts our brand reputation
2) The developer builds may not meet all ASF release requirements ...
3) We do not offer upgrade notifications for developer builds.
These can happen, but the whole point is that end users won't get those
builds. Direct links to binaries are impossible since URLs change every
day/week; links to pages on ci.apache.org without explanations will not
result in downloads but in puzzled users (we show a mix of everything
from SDK to console logs...). Let me add, Infra will let us know very
quickly if end users start downloading daily builds.
Was there something that did not work with sharing the ci.apache.org
address on the dev and qa lists?
That is the key question. Here are some more explanations.
What I propose: add a link "Development builds" to the column on the
right hand side of http://www.openoffice.org/download/ ; the link leads
to http://www.openoffice.org/download/devbuilds.html (a page Dave
objected to; I've put a large DRAFT disclaimer on top, and I hope we can
keep the page online during this discussion for convenience); this page
gives all necessary disclaimers, ways to get involved and links to the
dev builds.
Why would it be helpful?
1) Because links shared by e-mail simply have not worked well so far.
Localization volunteers, for example, are confused on how/when/where dev
builds are made available, if they are available for their platform and
in their language and so on. If they know that there is a path from the
download page their life will be easier and our product more tested.
2) Because it allows to enlarge our community. Power users periodically
scan our download pages looking for "something new", especially in this
period. They are likely unaware of our daily builds. But if we manage to
make them aware both that daily builds exist and that they exist as part
of a community QA effort we might get a few new good QA volunteers for
version 4.1.0. If you notice, the proposed intermediate page also gives
information on how to join QA. By the way, this would also help with
perception: even those who will never try those builds can see that
there are constant improvements, happening in an open environment.
Other solutions:
1) ... If the goal is to have only project members
download, then put it on a page that only project members read
Kay's improvements to
http://openoffice.staging.apache.org/developer-faqs.html#where_can_i_download_developer_builds
(to fix: both Raphael's and Ariel's builds are very outdated at the
moment so they shouldn't be mentioned) are complementary to what I propose.
I think the policy problem is not real problem and that a central
webpage can have advantages should be also clear. *For me* only the
location of this page is now open.
Of course it's most comfortable to have all things about download in a
single place. However, in this case I think a split regarding our target
audience is better.
This means, normal users go to:
www.openoffice.org/download/
Power users, dev's, qa's, etc. should be pointed to:
openoffice.apache.org/developer-faqs.html
So, putting text from Andrea's webpage proposal into the webpage Kay has
found (again ;-) ) could be the golden way.
My 2 ct
Marcus
2) Add some authentication on the actual developer build download
page. Ideally, tie it having a BZ account.
This is an unnecessary effort; contributing should be easy.
3) Put a date-based expiration into developer builds, to discourage
long-term use.
I like this. Well, not a literal date-based expiration since it has an
old-fashioned "Trial version expired" effect. But pointing the update
information to a page where we explain to the user that he is running a
dev build meant only for testing could help.
Of course, if we keep the discussion open until April it will become
useless to my intended purpose. But I would see it as a missed
opportunity to enlarge the community. And this project, like all
projects, should never waste opportunities.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
