On 05/27/09 00:52, John Plocher wrote:
Is there a formal procedure for end-of-lifeing, archiving and
otherwise shutting down completed/abandoned projects and mailing
lists?
We tried that as part of the new constitution, but it was not
successful. So, because of that, I think I will just update the project
process from an implementation perspective on my end to include some of
the items you mention below. Very good ideas. Also, keep in mind that
Derek, Bonnie, and I wrote the site guidelines policy back before the
OGB existed, and we have been following that:
http://opensolaris.org/os/site_guidelines/
The list seciton states:
-----
Mail Lists
Each community is responsible for the proper management of their mailing
lists. Lists are subject to review based on the TOU and may be suspended
or removed due to insufficient traffic or poor management of non-member
message postings.
Insufficient traffic is defined as
* No posts in the last month;
* Or less than 3 posts in the last 3 months.
-----
So, we do actually have a policy and we are very flexible in applying
it. I was being somewhat flip in my note early because I think we should
be much more strict -- "use it or lose it." That would be my policy
basically. Infrastructure costs money and it should be respected by
being well maintained. But a softer approach is the site guidelines
policy that we can update and point to a new group lifecycle policy
(from a project-setup implemention perspective, not an OGB perspective).
We can also make reference to end-of-life issues in the group reference
pages:
http://opensolaris.org/os/communities/lead_reference/
http://opensolaris.org/os/projects/posting_instr/
It would be good to have some set of written expectations in
place before y'all start the migration; it would also allow the rest
of us to be a bit more proactive in cleaning up our old messes :-)
Some context here:
spring cleanup and temporary moratorium:
http://mail.opensolaris.org/pipermail/opensolaris-announce/2009-May/002182.html
http://mail.opensolaris.org/pipermail/opensolaris-announce/2009-May/002183.html
So, yes, please do help clean up stuff that shouldn't be moved over to
the new site. That would be helpful. Most of that will be decisions on
the part of individual project/community/osug owners to clean up their
own spaces. And, honestly, most groups are fine. I am cleaning up the
unopened spaces (opening and deleting) on the site and iterating with
those owners now. And some project leads are offering to have me delete
old projects that have been integrated and/or never made it off the
ground (and they have archived the content off line).
Things that would be nice to address (kindof the opposite of project-setup):
How to shut down jive gateway(s)
A bullet would be the preferred method. First, we are not creating any
more Jive forums. Second, we are deleting them when requested and/or
when they become abandoned (I took down 3 just yesterday and have
deleted 15 additional lists/forums recently working with various
community leads). Third, we put on the schedule a line item to replace
Jive. So, we will begin that requirements and implementation process
after the Phase 2 content migration to XWiki in August. See the roadmap
for the current schedule http://opensolaris.org/os/about/roadmap/.
List owners can't manage their Jive forums as they can with their
Mailman lists. The app is welded to the site app. But nevertheless, this
is a good item to articulate in an expanded group lifecycle policy.
How to shut down mailing list(s)?
Moderate everyone, set the postings to reject, etc. It's easy. That's
how core-contrib-discus was turned off.
What to do with existing jive/mailinglist archives?
Well, the live lists are obviously accessed and archived here:
http://mail.opensolaris.org/mailman/listinfo
But when a list is turned off and the archives are kept, that's done on
a case-by-case process. It's pretty rare, too. This is how I handled the
Advocacy creation from the merger of UGs, Marketing, and Immigrants:
http://opensolaris.org/os/community/advocacy/discussions/merger-archive/
And cab-discuss is turned off and archived as well (but I'm not sure
it's linked to from anywhere):
http://mail.opensolaris.org/pipermail/cab-discuss/
I think we should just create an archives page that points to various
projects/lists that are not active but archived.
What to do with associated repositories?
These are tied to projects. Not sure about access to repos when they are
not active, but when a project is archived it's really just a case of
changing the content on the front page to reflect the change in status.
No need to hide it, really. People can spam the page like they can with
lists. But some projects have requested hidden status in the past, so I
am working my way through those now because we are not going to migrate
unopened projects (currently 40 in this list).
What to do with website content?
Not sure what you mean on this one. The common content or the group
content? Michelle seems to have a good handle on the common content
processes.
I believe that, in many cases, we don't want to lose the historical
content of the mailing lists, repos and website, but instead would
like them to become read-only-ish and labeled as "archives"... How do
we avoid "losing history" as part of this transition?
We'll not lose any critical history and here's why: active groups
maintain their content and infrastructure very well, and their stuff
will be moved over to the new site. Once there, XWiki will provide a
convenient content management system for page histories, etc. However,
there is no need to move over empty groups or piles of abandoned
content. If we can delete that stuff, that would be helpful.
Jim
--
opensolaris.org transition: http://opensolaris.org/os/community/web/
_______________________________________________
website-discuss mailing list
[email protected]
