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

[Seb Bacon]

On 9 May 2011 10:32, Friedrich Lindenberg <friedrich.lindenberg at okfn.org> wrote:
> Hi,
>
> On Mon, May 9, 2011 at 11:12 AM, Seb Bacon <seb.bacon at okfn.org> wrote:
>> On 9 May 2011 10:00, Friedrich Lindenberg <friedrich.lindenberg at okfn.org> wrote:
>>> I get that we need to work out better processes but I think we're
>>> getting a bit eager here: I moved this instance to a new server last
>>> week, did some sanity checks but apparently I fucked up somehow. There
>>> is nothing in all of this that concerns the Colorado instance owner
>>> (Sean Hudson <sean.hudson at opencolorado.org>). I will inform once I've
>>> fixed the issue, or if fixing it takes longer than the expected 4
>>> minutes.
>>>
>>> Do we really need to embed API calls and write CREPs here?
>>
>> Too late ;)  CC'ing this to ckan-dev.
>>
>> But yes, I think so.  Since I've started at OKF this conversation has
>> come up several times, either in "who is the maintainer of site X"
>> (sysadmin-type questions) or "how many instances do we have of CKAN"
>> (marketing-type questions).
>
> Its true these two questions exist and they both have answers in
> different places (internal GDoc vs. Wiki page). I think that the first
> question (who is the maintainer?) is more complicated and includes the
> following points:
>
> * Is the instance under our control or who is managing it?
> * Is it still alive in our opinion?
> * Are we looking for new maintainers or do we need to get in touch
> with existing ones to motivate them?
> * What level of support do we want to provide, what is of strategic importance?
>
> None of these questions are things that I'd like to discuss in a
> public wiki. Thats why I started the internal sheet and I'd like to
> defend it for these purposes.
>
>> There are at least two different manually-maintained lists of
>> instances, possibly more, and no agreement on which one is the
>> "master".
>
> None is, they serve different purposes: the internal one is for
> structuring our work, the second one is, as you say, marketing.

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.

>> It seems in this case you can fix it, but if you were on holiday that
>> would still not be apparent, and we'd be waiting around a bit until
>> someone decided to step forward in the absence of a clear answer.  If
>> it's possible to look it up, see it's you, know that you're on holiday
>> so it's OK for someone else to do it... that's more efficient.
>
> I don't fully follow you? I sent around an email on friday (?) saying
> I'd migrated these three instances. The same moment one of them begins
> malfunctioning - I know its bad style to screw up things and then
> leave for the weekend but I just didn't see it (filtering my mail,
> tbh). I'm not sure how this would be prevented by call-home features?

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

Emails about things don't really help because they can't be guaranteed
to be seen.

I agree that *if* there's a single owner of the google spreadsheet;
someone who takes responsibility for ensuring it is completely up to
date, emailing people who get in touch with ckan-discuss about
installing things to see if they had any success, etc; then that would
be a perfectly reasonable solution to the problem.

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.

>> As a side effect, having a way of contacting administrators about
>> security-related updates is potentially useful.
>
> We do.

Only the ones that have the nous to sign up to the relevant lists --
increasingly I think we are likely to get less experienced installers.
 But I think this isn't very important right now.

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

I've heard and entertained a few concerns about how we're growing and
not really dealing with it well, but no concrete proposals for fixing
anything.

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

Thanks,

Seb