long e-mail, with analysis of pros and cons, and some policy draft on some issues Berin didn't address yet last time I checked.
Disclaimers ----------- a question at hand: how do we make clear to everyone that a project and all its related assets are "under incubation" (along with what that means)?
Lets split that out a bit according to "involved peeps":
board -- I have the distinct feeling that, normally, the board will know what is under incubation by virtue of reports from PMC chairs. No problem here.
infrastructure team -- for these peeps, it mostly doesn't matter; all they need to know is that all infrastructure requests and setup are governed by a PMC, and a CC of those requests to [EMAIL PROTECTED] suffices. No problem here.
sponsors -- these people had better know! No issue.
podling developers -- sponsors had better make sure these people know as well! No issue.
potential podling developers -- if these people come from within apache, most of them will at least be somewhat familiar with incubator, and a simple and clear "disclaimer text" on a project front page will allow them to find out whatever they need.
If these come from external projects, they may have a few more questions, but that is something probably best solved by good docs on the incubator website and some people around on the podling mailing lists to direct people to it.
The trick, of course, is making sure these people actually read the disclaimer text. To make that happen, it needs to appear on their screen before any "get involved" or "subscribe" link...
If you can get at downloads or mailing list information without going through the project website, that will be a problem. This is what Tetsuya (can you pick a nickname please? I keep copy-pasting that 'cause its impossible to remember the right spelling :D:D) outlines went wrong with the mail2.html page @ jakarta.
users -- most users are dumb. They will read right past any disclaimer, will not even think about what "incubator" means and will just click on "download". I very much doubt that many users will respond *that* differently to a project whether its url is jakarta.apache.org/geronimo, incubator.apache.org/geronimo or geronimo.apache.org. Its "the apache J2EE server", no matter what internal procedure applies. Marking something as "alpha" or "beta" might work, but "incubation" is probably not in the active vocabulary for a rather large part of the user community.
Infrastructural burden ---------------------- (responding partially on behalf of the infrastructure team I guess, but all IMVHO...I'm not on the infrastructure team)
The infrastructure peeps are pretty busy. Something like the renaming of a cvs repository is probably usually done in a minute or three (including reading the request, verifying it, doing the 'mv' and 'ln' on the server, and sending another e-mail to confirm its done), but it does all add up.
In my experience, configuration changes for bugzilla, eyebrowse and ezmlm are more of an issue than changes to cvs, webserver or basic unix (ie permissions); probably because the latter are naturally easier to manage and there's more people around to do it.
However, the combined energy invested by all people who work on use a project is a lot bigger still. Bookmarks and address books to be updated (along with memory), referring websites to be changed, uncommitted code changes to manually merge, cvs modules to checkout anew, etc. The bigger the project, the more annoying the change.
Thus, until it becomes clear there's an actual problem with putting podling materials in their intended final locations, I'd recommend doing so.
Finally, I would assert changes to cvs and e-mail configuration are more annoying to deal with than movement of websites, especially since the web allows for easily setting up sophisticated redirections (without infrastructure team intervention) whereas for other stuff its more involved.
So...the compromise...
------------------------------------------------------------ Draft policy ------------ It is desireable that all (potential) developers and users of a podling project understand that it is under incubation and what that entails. Having said that, we otherwise wish to minimize burden on the infrastructure team and in all other ways make the "Podling Experience" as pleasant as possible. To that end, a few guidelines.
Resource allocation
-------------------
- new podlings get a website @
incubator.apache.org/projects/$podling
- all podling developers get access to incubator-site cvs to be able
to update their project and list it on the main incubator website
- new podlings get their own unix group if they're destined for
top level, otherwise the 'incubator' unix group is used until they
graduate, at which point the unix group is changed to that of their
new new tlp
- cvs, e-mail, task management and any other resources
are set up as if the project were at its proposed destination
already, ie:
- new podlings get a cvs module named $tlp-$podling, or
$podling if they're destined for top level
- if a mailing list is set up for the project, it is named
[EMAIL PROTECTED] if the project is destined for top
level, or whatever else is appropriate if its not
destined for top level.
If there is not podling-specific mailing list, the podling
needs to opt to either use the destination projects' mailing
list or [EMAIL PROTECTED], but the choice should
be clear on the podling websiteBranding -------- The podling website should have a notice (<insert here>) on its front page pointing out that its under incubation, a notice in the root of its cvs (in README.txt or WARNING.txt or ...), a notice inside and alongside any downloadables it produces in a prominent location, and ideally, a notice wherever a sponsoring project directly links to one of the podlings' resources (other than its website).
Finally, the podling needs to display the incubator logo on its website. ---------------------------------------------------------------
back to my corner!
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
