[Strategic] Putting the horse before the cart

[Richard Weait]

On Tue, Jun 8, 2010 at 7:25 AM, Steven Feldman <shfeldman at gmail.com> wrote:
> Agree what is needed is to distil a vision from current contributors and
> their aspirations not a management invented one. How can we do that?

I expect that listening to the community and picking off items to fix
is the easy part.  Here is a "little thing" from the community.

For example:

The community notices when the Export tab is disabled.  Export is
disabled automatically when load is above 40% (iirc) on server
"Yevaud".  So Export is disabled during peak times on some days. Looks
like this happened about half of the days in the last month. [1]

How do "we" "fix" Export?

Probably just by listening to the server admin team.  They've got
upgrade and growth plans.  They've got the knowledge and experience to
"fix" Export in the best way.  Perhaps the best "fix" is connected to
a larger upgrade plan like the new tile cache at Imperial, or my pet
project of a new tile cache in North America.

As I understand it, adding a remote tile cache machine (or several),
reduces the processor load on yevaud.  That would "fix" Exports.

The tile cache would also reduce bandwidth used for tiles at UCL. That
relieves pressure on our bandwidth cap at UCL and perhaps makes
edit-commits and other bandwidth-related functions better.  As I
understand it, reducing bandwidth use at UCL would allow longer growth
without running into the bandwidth cap at UCL.

So "fix" Exports might be supported in the community.  The server /
admin team probably has plans to fix it that range from stopgap, to
quick and dirty to fair, to good, to ideal.  But, now I've stuck my
nose into it and I hope to see my pet project (Hey! North American
tile cache!) funded as a part of this solution.  Great.  Everybody has
an opinion, or a pet project.

I expect bigger changes than increasing the availability of Exports,
or changes that don't address a technical "bug" will be more
contentious.

Let's look at a need that has already been identified by the admin /
server team[2]

High Priority

    * Additional Web Frontend Capacity

Okay, that sounds good to me.  Sounds like it would affect all OSM
visitors and users.  And I would expect that having more capacity is
good.  What's the best way to fix it?  Again, the server / admin team
will know.  Does this need bandwidth, processor, disk, or all three?
Is there enough rack space at UCL for this, or should it include a
solution at Imperial or (dare I say it again?) in North America?  I
don't know the details.  But I know that server / admin team will have
ideas.

So how do we help the server / admin team do all of these great things?

It better not be by asking them to submit a funding proposal, or fill
out a report.  That's the job of the Strategic Working Group.  SWG is
supposed to make problems go away, not cause problems like additional
paperwork and arbitrary hoops to jump through.  And the server / admin
team are exactly the folks for whom we want to make life better.

So as a strawman, how about if we:

1) Additional Web Frontend Capacity
- find out what sever / admin team wants for the additional web
frontend capacity.
-- without demanding forms in triplicate or a TPS report.  I nominate
MattA and RichardF to duscuss this with others on the sever / admin
team.
- find out their ideal plan for implementation schedule
- fill that shopping list as a good SWG should do.



[1] http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap-load.html
[2] http://wiki.openstreetmap.org/wiki/Servers/Upgrades