incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <>
Subject Re: Refactoring the brand: Apache ooo + (was branding)
Date Mon, 01 Aug 2011 22:08:36 GMT
I'm sure other responses will follow but I just wanted to address a few 
of these comments vis a vis past history....

On 08/01/2011 08:35 AM, Rob Weir wrote:

> As for admin resources, there is not a large admin staff employed by
> Apache.  It is almost entirely volunteers.  So for those resources,
> this is certainly an issue.

Conceptually, many of the OO.o resources had what I will called 
decentralized administration, for specific projects and other services. 
I don't see that Apache has this and well, I am again not certain how 
the omission of this will affect "moving forward".

> I'm not assuming that everything gets moved over by default.

There's already been discussion on this both pro and con. From my 
perspective, NOT moving everything somewhere en masse, and then editing 
afterward will severely slow down the migration process. Yes, there's a 
LOT out there that's old and useless, but I don't see that we have the 
time or resources to deal with this BEFORE migration. It would be better 
from and end user standpoint as well.

> certainly the easiest thing for project members to think about, that
> we'll just continue everything as it was before, but do it at Apache.
> But was everything working well before?  I'm looking now at dozens of
> Kenai projects that have seen zero activity in a long, long time, or
> only have spam in them.

OK, some reasons here. OO.o moved to kenai in Feb of this year. I too 
looked at some of the cvs logs on some projects. The problem is I don't 
even think some of the existing, well formerly existing, 
contributors/project managers have even had time to figure out the new 
environment if you want to know the truth. jsut my .02 observation on this.

   Personally I'm not interested in creating an
> museum.  I want a living, growing project, with no dead
> wood.
> There is a natural tendency to segregate the project into dozens of
> little boxes and to give every box and every person a title and create
> a multi-tiered bureaucracy of steering committees and leads and
> deputies to manage these dozens of boxes.  That is a very easy thing
> to do.  Too easy.  But Apache is not like that.  Within a project
> anyone can do anything.  Projects are flat.  There are no boxes.  If a
> committer wants to patch code one day, then modify the doc another
> day, translate it into French and then after dinner update the
> website, they can.

hmmmm...OK. Yet another rather critical clarification I would say.

> I sensed that several project members, including myself, where
> skeptical when this Apache project first started, and we had just a
> single ooo-dev list.  How could this possibly work, without a separate
> marketing list, a QA list, a Doc list, a Support list, an
> infrastructure list, and 145 different national language lists?  We
> must hurry and recreate the boxes from OpenOffice ASAP lest we
> actually talk to each other as one project!
> But it has worked out pretty well, I think, having a single list.
> We've all learned more about how the parts of the project work, and
> what our collected concerns and priorities are.  I think this is a
> good thing.  I realize that at some point we'll need to create some
> additional lists and additional wikis.  But I'd urge a minimalist
> approach.  Create only what is needed when it is needed.  Let's not
> rush to recreate the 200 boxes of  I think we can do
> better than that.
> Obviously, this complicates the migration effort.  We need to discuss
> and decide which services are preserved and according to your 1-5
> methods above.  Luckily I think there is consensus that we must
> preserve the phpBB user support forums, so maybe we start with that?
>> As we've discussed elsewhere, the OOo forums and OOo wiki can easily fall
>> into (4), though whether the wiki moves into sustain support is still an
>> issue.  In this case Apache will provide a hosting service which is directly
>> supported by the infra team, but they will undoubtedly expect the project to
>> provide in VM/Jail/Zone day-to-day administration, albiet compliant with
>> wider operations and security standards.
> The obvious question we'll get is whether our wiki content could be
> migrated to confluence or moin moin, to run on existing
> infrastructure.  Has anyone investigated this?  Saying that
> translation is impossible due to X, Y and Z would be a great answer.
> But saying we haven't really looked but it appears to be hard, is not
> a great answer.  Remember, getting MediaWiki supported at Apache will
> be hard as well.
> -Rob


"If you can keep your head when all others around you
  are losing theirs - maybe you don't fully understand
  the situation!"
                             -- Unknown

View raw message