XMPP Council - 2010-07-05

Wow, two members of Council here already.

</sarcasm>

I got here before 19:00 ;)

Yes, me three.

Give them until ten past, I guess.

*nod*

*phew*

Haha

Well done, with 30 seconds to spare.

Or, 60, rather.

Ok, ten past.

1) Roll call.

Kev, Ralph, Matt present. Remko and Fritzy still AWOL.

2) Agenda bashing.

None

I only really wanted a meeting to get everyone back in reviewing specs after Remko and Fritzy dropped off the Council radar.

3) Pubsub

What's to discuss?

The only thing holding this up now is Ralph approving Peter's rollbacks, I think.

Besides, I've changed my mind, I like pubsub now

So Ralph - can you check them and let Peter know, please?

4) Voting.

And, the people this applies to aren't here.

I wanted to remind people that the reviewing and voting is the reason we've got a Council, and failing to do that isn't helping.

yeah

Dave stepped down because he wasn't managing to hit the meetings, and was having to vote on-list.

It's entirely inappropriate for the other of Council to not attend meetings *and* not vote on list.

But hi Choir.

5) Date of next meeting.

Next Monday as usual?

Kev_: did stpeter announce the changes yet, or are they just in vcs?

+1

There's a small chance I'll be unavailable, will update if so.

ok

ralphm: I do not know - could you coordinate with him, please?

I suspect that once you're generally ok with the changes there'll need to be another vote.

ah: "FYI. Ralph, this is for you. :)"

in the pubsub list

missed that :-)

But it seems pointless to go through another vote for everyone if the changes weren't what you wanted.

So, AOB?

Kev_: seeing the summary, I'm ok with it then

I was going to mention that I'm working on a replacement/successor series of XEPs to 136

Ok, I'll speak to Peter and arrange a new vote.

MattJ: excellent.

But that's all for now

we can quibble about details, but the document is never static

But we've discussed that offlist anyway :)

I think we're all done then.

Thanks to those who turned up.

np, thanks for chairing as usual :)

MattJ: oh, that sounds painful. The amount of discussion on XEP-0136 is uncountable, it seems

I'll write minutes and send around - possibly tomorrow.

ralphm, the problem precisely :)

Although it'll probably never beat XEP-0060

:-P

ralphm, but it turns out the only active client implementation is using one feature of the XEP, and that's about it :)

I would like to use the successor in Swift.

As long as it's modular and sane.

I'll try not to let you down :)

I don't object to all the 136 options existing - only to having them all in one place, and some of them being such a silly way of doing them.

Anyway, I'm off out, bibi.

See you

MattJ: that is sad

ralphm, indeed

This only came to light to me because of the student implementing it in Prosody for GSoC

Some of the design decisions I still can't fathom

I'm going to try keep 'features' out of any spec if there isn't a high probability of it being implemented

i.e. let implementations drive specifications more

Yes, agreed

Put out a basic spec, see what direction it gets pushed in (if any)

implementations == experiments, really

Indeed

and to be fair this is usually what the XSF does very well

It just happens that there are some specs that really take everyone's fancy, and end up a dog's dinner

haha

ralphm: I think it's more thn "If it's not needed, don't put it in"

I think it's "If it's possible to implement without it, don't put it in", and then put it in another spec.

No-one dislikes small specs.

Kev: right