SamWhitedjcbrand: Thanks! It's nice having an editor that can take minutes on occasion again :)
jcbrandI'm happy to help, just keep on pinging me please :)
Tobias3) Vote on "XEP-0060: Add pubsub#multi-items in Publish-Subscribe features #500" https://github.com/xsf/xeps/pull/500
TobiasI'll vote on list
Tobias4) Advancing "XEP-0286: Mobile Considerations for LTE Networks"
Tobiasdo we want to have the editors issue a last call?
dwdOoops, sorry I'm late.
Tobiasi'd be in favour
dwdI'd be in favour of advancing XEP-0286.
SamWhitedI am obviously biased, but I think we should issue a LC and at worst I'll get feedback from it even if it doesn't advance :)
dwdSamWhited, I'm biased too.
Tobiasdaniel, any opinion on this?
danielNo. I don't. Let's issue a last call and see what comes up
Tobias5) Discuss renaming "Draft" to "Stable" and make a recommendation to the board
dwdThe recommendation can be a PR to XEP-0001, incidentally. I'd note it'll mean regenerating all the XEPs, too.
SamWhitedAll XEPs are regenerated twice a day or something now, so regenerating XEPs shouldn't be a problem.
TobiasStable/Stablish sounds quite similar to Final
SamWhited(Just in case it wasn't clear, I was joking about "Stablish")
dwdTobias, In fairness, Draft *is* quite similar to Final.
SamWhitedFor me anyways that's the idea. When I mention that I work on XMPP to people, the first thing I always get at meetups and the like is "Oh, we tried that, but every feature we wanted to use was just a draft"
SamWhitedSo making them sound similar might help.
dwdMy problem with us discussing it is by the time we've got to Council we (should) understand what these things mean, and are no longer in the mindset of those who would benefit from a change in name.
danielI'm not sure what this change will actually accomplish. I have never personally had the experience SamWhited describes where someone didn't implement it because it was just a draft
danielBut if that's a real thing than I don't have any issues with this change
Tobiasyeah...i'm not going to block this change, but other things might help more with this
dwdI think Board might have a better chance of having a valid opinion than we do.
danielIt's just a cosmetic thing anyway. It doesn't change any real problems we might have like not advancing xeps quickly enough and so on
SamWhitedAgreed; it is no substitute for fixing our process.
KevI think before doing something disruptive like this, there should be some real investigation into who it'll help, and who it'll hurt.
Tobiasmaybe add a standardized table to each XEP of known implementations or such, if people see it's implemented X times, it might be more attractive even though it's calle Draft/Experimental
SamWhitedThat sounds like a lot of work to keep up. Have we ever been known to keep client lists, wiki pages, etc. up to date?
TobiasSamWhited, IIRC there were community fplk asking on how they could help, not?
dwd(I still think the best marketing idea I've had for XMPP is to say it has a React-like wire format instead of saying XML)
SamWhitedTobias: Yes, but communities ask how they can help and then dissapear after two weeks and it becomes neglected again.
Tobiasalso there are different issues at play here: a) having XEPs early accepted so they can be easily referenced and discussed, b) having quite stable XEPs (MUC) idle around in draft state for 10 years, c) name doesn't sound attractive
KevTo me "Oh, we didn't use XMPP because the specs are Draft" doesn't sound particularly convincing. It might actually be true that someone read just one word in a XEP, and none of the others, but it seems a stretch.
jonaswI’d like to throw in that Link Mauve has proposed an XML format to describe XMPP software, including XEP support
jonaswwe also already have the requirement for software we list on the website to renew yearly
ZashReactive Messaging and Presence Protocol?
jonaswwe can step by step increase the requirements
jonaswand require them to list XEPs they implement
jonaswthat’d give us the nice table Tobias wants (and which I think would be amazing to have)
Tobiasjonasw, yeah but that's a different issue iI think?✎
Tobiasjonasw, yeah but that's a different issue i think? ✏
KevI'm opposed to opening up XEPs for marketing purposes, FWIW.
SamWhitedYah, let's discuss one at a time unless someone has a reason these issues are related and need to be discussed together?
danielanyway let's not drift away from the topic. so regarding the recommendation on changing draft to stable I suggest "we don't have one. let the list discussion play out for a little while longer. and/or let board investige real world benefits of changing the name"
jonaswindeed, it’s not related to the name change. but Tobias brought that table up, so I wanted to bring the thing back into mind. nevermind me.
Tobiasdaniel, +1 for continuing the list discussion
SamWhitedThat sounds sensible to me; let's let the board discuss and see if they can think of a way to investigate further
Tobiasjonasw, yeah...could be integrated dynamically on XEPs, like you open a XEP and can expand a table that'll show existing implementations, but yeah...something for another time
KevThis is a marketing question, and so Council probably isn't the right place anyway (although their opinion should certainly be noted).
Tobiasnaming XEP states is a marketing question?
Tobias6) Date of next
dwdTobias, XEP-0001 is a Board XEP, so it's not Council.
KevThe reason for the rename is based on the premise that XMPP is hard to market because of the name of one state, yes.
Tobiaswell..same time next week?
KevI don't think anyone is going to claim that a XEP would be easier to implement with the name of the state changed.
jonaswI’d like to throw in that there are still pending list votes from last week :-)
SamWhitedWe have two outstanding things on our Trello board, ODR/OMEMO and XEP-0280. I don't know the status of either, but should we discuss them?
jonasw(regarding the LC proposals and the two ProtoXEPs)
danielodr/omemo can be removed
danielthat's a list thing
danielnot a council thing
TobiasThere are a bunch of old probosed agenda items in Trello, which I think are all stale or at least in an unknown state. It would be great to have them updated.
dwdjonasw, I'm no objection on colors and jet, FWIW. I'll do the rest on list (and these two if you don't get to them)
Tobiasbangs the gavel
jonaswthen I’ll see that colors and jet get accepted soon-ish.
jonaswthanks, dwd & all
Ge0rGI think 0280 was in LC and got delayed/deferred because of the rule complexity
Ge0rGAnd because of issues with <no-copy/> vs. <private/> that never quite got sorted out.
danielGe0rG: the <transient/> annotation did have consensus thought, didn't it?
danielOne marker to rule them all
Ge0rGdaniel: I don't think so.
danielMhh. it's hard to keep up when the discussion happens in three different channels
Ge0rGMy agenda was to create a set of rules that work for IM, but underway I realized that I'm not competent enough to enumerate all affected user stories and XEPs.
Tobiasin the past it was just ML + chat room, now it's ML + chat room + PR
Ge0rGI'm in the process of refining the problem statement, as discussed in xsf@ MUC today, in the hope to provide food for a Summit discussion.
Ge0rGMy preferred venue would be my private blog, making #4 on the list of things to follow.
jonaswTobias, I’m working on avoiding PR
jonaswi.e. directing technical discussions to the mailing list
danielthe muc still doesn't have history, does it?
Ge0rGBecause if I write long posts to standards@, they are either ignored or individual points are picked out and get discussed at length :>
Tobiasdaniel, not yet
Ge0rGI'm not sure how often I've brought up Carbons on the ML so far.
danieland there is stuff on the wiki
Tobiasiteam wants dockerization but not keys in prosody docker...maybe dwd's Metre can help there
danielfinding the right place to discuss how to route messages is even more complicated than to acutally route messages
Ge0rGdaniel: sad but true
SamWhitedTobias: Isn't that what environment variables are for?
Ge0rGI'm open for proposals, though.
TobiasSamWhited, passing keys through envvars?
SamWhitedTobias: For not putting secrets directly in a config file (a Dockerfile in this case)
TobiasIIUC other iteams didn't want the prosody docker to have access to the LE private key at all, might have misunderstood them though
KevYes, they can have access to the key.
KevNot sure how Prosody's going to work over TLS without it.
danieli wonder if discourse has support for patch files. if so we could run on discourse only and get rid of github and mailman
dwdTobias, No. Well, sort of but we shouldn't, we should be using something like an SHCM.
KevJust that the key should live outside the container, and be linked in via a mounted volume.
Ge0rGdaniel: and of XMPP.
SamWhiteddaniel: I've never been able to convince discourse to work well as a mailing list. I'm sure it's nicer to maintain or nicer if you use it as forums via the web UI, but unless you know a secret I don't it's terrible for mailing lists as far as I can tell.
SamWhitedEvery few months I try to sign up for the Rust lists again (they're on discourse) and it's always a rough experience.
danielSamWhited, oh i don't have personal experience with it. all i can say is that mailman doesn't work at all
SamWhitedyah, mailman is pretty terrible.
danielbecause it splits threads into month and doesn't provide a search