[ckan-dev] Who is in charge of the Colorado instance?

[Friedrich Lindenberg]

Hi Seb,

On Tue, May 10, 2011 at 12:50 PM, Seb Bacon <seb.bacon at okfn.org> wrote:
> I see the former as a subset of the latter.  If we have a master list
> of *all* sites then we have a way of knowing *something* about them
> even if the internal lists aren't up to date.

But thats what the Wiki is? Its just not compulsory for people to
register with and I think thats a feature.

> It would give confidence that there's one place to find out with
> reasonable certainty the maintainer of an instance.

For us, thats the GDocs sheet, but the reality is also that for all of
the community stuff we often have an external contact person but
really, we're supposed to be running them. That means we have someone
who socially "owns" the instance but for technical maintenance, it
comes down to Rufus or me for most of the cases.

> However, right now there's isn't a clear sense of ownership -- at
> least, if there is, it's not clear / known to me.  Therefore, I think
> that a (reasonably simple) technical solution might in fact be better
> than a potentially complicated social solution.  Say you are the
> person keeping the spreadsheet up to date, but end up moving on to
> other projects -- the issue is that we're not the kind of organisation
> to remember that someone else now has to take that responsibility.
> That's why I think a technical solution is appropriate.

We do have support at ckan.org which exists exactly for this purpose and
has a list of people on it who're supposed to take over when
front-line (me, in this case) is unavailable. But I take your point.

>>> I could just do that... or we could have a discussion about it first.
>>> You can always ignore the discussion if you're not interested :)
>>
>> I'm interested its just that I see this pattern evolving that whenever
>> we have any problem in OKF at the moment we all stand up and have a
>> big debate about how this is a consequence of us scaling and how we
>> need to develop more procedure for fixing things. My whole point is:
>> thats often right, but sometimes a cigar is just a cigar and a bad
>> CNAME is just a bad CNAME. (Problem fixed btw.)
>
> Interesting -- perhaps the real core of this debate.  We seem to have
> quite different perceptions of the matter: I've not seen this pattern
> at all!

Ok, let me - just for clarity - sketch out how this looked from my perspective:

1. Someone complains about error messages regarding colorado, coming
from eu3 (i.e. our server).
2. We start a discussion about lists of instances, while there are
already 2 with defined purposes.
3. We want to contact a responsible person. The problem is on either
eu3, eu6 or eu8 or on EveryDNS. Responsible person has access to none
of those (not sure if he knows shell).
3. We start designing a new feature which would require operation of
another web service and all CKANs to be connected to the public web.
It would also have made debugging the actual problem in this case
harder.
4. We begin discussion specifics of the implementation.

Which is all just to say: this one went completely off the rails, I'm sorry.

>> We should have
>> meta-discussions, but we also need to select the right places for them
>> to happen.
>
> Where are the right places for meta-discussions?

I think large (project management) screw-ups are better places than
small technical problems. The fact that eu3 has been down for 2 months
would have been nice example. But this one was just a complete
Rohrschach party where no-one actually looked at the problem.

Sorry to be so trollish this week.

- Friedrich