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

[Seb Bacon]

Ahhhh, I think we may have been talking slightly cross purposes here.

>>> 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.

For me, the small technical problem is irrelevant, but reminded me of
a different problem: we don't have a reliable list of as many
instances as possible.

If it was just a matter of maintaining a list of community instances
which we help admin, that would be one thing.  But in fact, we would
like as large a list as possible of instances being run all over the
world.

> But this one was just a complete
> Rohrschach party where no-one actually looked at the problem.

My interest in starting the discussion wasn't about getting this
particular problem fixed, but about fixing the issue of knowing what
instances exist, where, and with which sysadmin.

With this in mind...

On 10 May 2011 12:23, Friedrich Lindenberg
<friedrich.lindenberg at okfn.org> wrote:
> 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.

Most people have no idea how to use a wiki, though.  In the world out
there of people installing CKAN to run their local council site, and
who have never contributed to a wiki, the last thing they're going to
bother doing is edit a wiki page with information about themselves.

And even people who do know how to use a wiki don't know what pages
exist on it that need updating...  I bet most of the team have hardly
ever looked at more than one or two pages in the wiki.

>> 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.

Sure, but as per above I'm talking about the wider ecosystem of CKAN instances.

>> 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.

Again, cross purposes (I think?)

>>>> 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.

That really helps.  Here's from my perspective:

1. I see a message to the mailing list about who "owns" which
instance.  I am reminded of many similar conversations, and the fact
that this is not restricted to community instances: DataGM (for
example) only appeared on the wiki very recently (I added it when I
found the wiki page).

2. I reflect on the fact that there seems to be no confidence that the
wiki page is up to date, and also on the fact probably quite a few
people don't know of its existence, or of the Google spreadsheet.

3. I think, not for the first time, that given the nature of OKF, this
is perhaps amenable to a machine-based solution.

4. I think about one concrete way of addressing this and post an idea
to the mailing list

What I've been puzzled about is that the suitability of even
discussing the idea is in question :)  Now I realise that (I think) we
are trying to solve different problems.

>>> 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.

I think small technical problems are just as good a reason to have a
discussion about process and procedure as anywhere else.  I made a
mistake in not making it clear that I actually *don't much care about
the problem with colorado*, I think :)

> Sorry to be so trollish this week.

Not at all.  It's interesting (to me, at least ;) to understand how
different perspectives can be on something apparently so simple.  And
a lesson in communication: I'm quite sure we'd find we agreed with
each other 100% if only we could find out what we were all talking
about.

Ah well, no doubt it's only you, me and Will still reading this thread
at this point...

Seb