ralphmI've contacted Robert Martinez on this, hope he responds before next meeting.
ralphm3. Review of Roadmap Page
ralphmI have looked at this really old page again.
ralphmOddly enough, some of the items are still a bit current.
nycoplease help me on: https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=fr
ralphmE.g. the part on Jabber Identifiers (PRECIS) came up again a few weeks ago
ralphmFrom the few responses on the XMPPWG mailinglist over at IETF, it seems there's not really a solution for this yet.
ralphmMy own topics that I think could be on a roadmap page are:
ralphm1) Work on the things I recently blogged about regarding references, reactions, etc, and how that could be handled with MAM
ralphm2) Calling in the new(ish) reality of multiple devices that aren't always connected, but still would want to receive calls.
GuusRalph, instead of defining a roadmap (that's an XSF roadmap, not a board roadmap), we might want to discuss topic candidates on the member list?
ralphm3) e2ee. I think we need to make clear here what things are covered (plain body, full stanza) and which are not (e.g. meta data).
Ge0rGralphm: that sounds like a Council roadmap actually ;)
ralphmGe0rG: it does, maybe, I am listing what I think could be on it, I'm sure the Council has opinions, and I've also sent a message to Dave on this earlier today.
Ge0rGralphm: XEP-0423 comes with a "Future Development" section that's looking for content, deadline is next Wednesday for an LC request, November 5th for Draft
SeveAre we discussing the content of the roadmap, or if we want to have a roadmap?
ralphmGuus: I'm just following the agenda, the items above haven't really been handled for weeks, and I did some work on it
ralphmGuus: I don't intend to make a full discussion on it today, just share what I have so far
ralphmSeve: probably both
Ge0rGralphm: if you are motivated, please contribute in https://github.com/xsf/xeps/compare/master...ge0rg:cs2020?expand=1 / https://github.com/ge0rg/xeps/tree/cs2020
Ge0rGI think the XSF or Board roadmap should be different from the XMPP protocol roadmap, though
Ge0rGXSF Roadmap should include marketing, org topics, sprint planning etc.
GuusI think it can include anything that we feel significantly benefits the XSF or XMPP.
Guusif an important goal is to have a specific XEP published, I don't mind it being on that roadmap.
Ge0rGalso compliance badges.
ralphmI'm not interested in individual specs per se, but more like: we should have a solution for things like references (e.g.)
nycoand our emoji character
ralphmand then see how we can achieve that
pep.I agree with Ge0rG that xsf roadmap is different from protocol roadmap
Ge0rGGuus: I'm not trying to protect my turf here, but I think that we get less done by mixing up the different bodies of the XSF
nycoyes, protocol != xsf
ralphmpep.: well, so far it hasn't. We could change that, of course, but I'm not sure, really.
nycoso everything related to SCAM, commTeam, iTeam included
GuusGe0rG putting something on a roadmap does not imply that other bodies are suddenly working on something.
Ge0rGI agree that we should have a high-level protocol strategy defined by Board + Council, though
Guuslet's come to some kind of actionable conclusion here
nycoin relation with the IETF, and probably other standards bodies
MattJI definitely believe the Board should be able to set high-level goals that can guide Council
ralphmWe are still primarily a standards organisation, and of course those things mentioned by nyco need to be addressed, and could /also/ be on it.
MattJand that has happened in the past regularly
dwdI'd note in passing that Council has zero power, as defined in our documents, so actuate any of these roadmap initiatives.
ralphmGuus: well, the action I had was reviewing it, and I did
GuusWe've danced around 'priorities' and 'roadmap' often. I'm not against someone simply providing a PR with a suggested roadmap update, and for everyone to provide feedback on that.
MattJBut e.g. the goal would be "End-to-end encryption", it's Council's reponsibility to decide whether that's OMEMO that gets put into the Compliance Suite
ralphmdwd: indeed, so that's another reason it is also a Board topic
nycofor how long have we not done "official" interop testing? that could help OMEMO implementations, btw
ralphmI personally think it would be good to stimulate development in certain areas. Maybe with small scale topic-specific get-to-gathers, or something, to get things moving.
Ge0rGBoard could assign some resources to do official interop testing. Also to making our wiki mobile-ready finally.
ralphm(I meant /protocol/ development, really, but having implementations is good too of course)
nycosprints are awesome so far, we could use more focus and some sort of direction, indeed
Guus5 minutes left.
ralphmGood to see various topics raised here. I'll take that make and see if I can create a comprehensive list from it.
nycothe list can be collected here, though: https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=en
ralphm4. Board & Council elections
ralphmSo we're having them soonish, and we need (more) candidates.
SeveTo have a roadmap, we need to have some sort of commitment for it. I think having a global XSF roadmap is good, I would first think about what do we want to fit in the roadmap and check after if we need to split it into two (XSF/protocol) or not
ralphmI personally think it would be great to have people on Board who are not directly involved with protocol or software development.
GuusSign up here: https://wiki.xmpp.org/web/Board_and_Council_Elections_2019
ralphmI do not yet have anyone in mind.
nycobusinessy people, yes
or marketingy people
nycoI second that opening
ralphmWell, we've always been open in that regard, just recently haven't seen candidates in that regard.
Ge0rGralphm: isn't it better to look for people who are competent at PM, rather than for people who are incompetent at XMPP? ;)
nycocould have been Product Management as well
ralphmGe0rG: oh, I meant 'not necessarily involved'.
ralphmBut having a broader scope is always interesting.
nycopeople who are incompetent at XMPP are very, very, like very valuable to us!
nycowe could use those profiles to greatly simplify our "message"
Ge0rGnyco: but that shouldn't be a requirement for runnung for Board
MattJAt some level I find this quite amusing
ralphmSo, I'd like to ask anyone currently on Board or on the floor, to think about this, and maybe provide suggestion to me.
Ge0rGralphm: suggestion of potential board candidates?
MattJI shall definitely give it some thought
Severalphm, are you thinking about some specific skills?
ralphmGe0rG: we're not limiting applications in any way. There's still an election of course, and we already have candidates that have run before.
nyconew blood is cool as well
ralphmSeve: not really
Ge0rGas I said, "project management" is a good skill to have.
GuusWe need more focus in these meetings
Ge0rGmaybe also "has an hour or two per week for Board matters"
nyconot forcefilly PM
Guusand/or have more than 30 minutes
ralphmGuus: we're already at AOB?
Guuswe're not getting our item list done
nycoor really commit and engage
GuusI'm raising that as an AOB item 🙂
ralphmAnd if we didn't spend valuable time at the 'minute taker' item, then we'd have more time to discuss things.
nycoI'll propose a solution on the "minute taker" problem for next week
Guuswe've had a couple of trello cards on there for weeks, without addressing them.
ralphmGuus: and we addressed them today, yay.
nycoagree, we don't consume cards fast enough
ralphmMany of the other items are awaiting feedback
SeveMaybe we can be more async?
ralphmBut point taken.
ralphmSure, we can still do stuff on the board list. particularly around financials
GuusI think we should strive to discuss less details in meetings - unsure how that works out in practice though.
nycoasync would be added capacity, indeed
but needs more organisation, commitment, engagement
nycodetails arise in meetings, so let's set them free to expand
ralphmOk, so let's all review the topics on the trello board and see how we can cross them off
GuusI disagree. I think we should use meetings to plan for discussion/processing of details, not to handle them.
ralphmI'm sorry, but didn't we do just that?
Guusas a for example: we discussed items to be put on a roadmap, instead of 'how do we update the roadmap'
nycoSeve is right about async work, or out-of-meeting progress
Guusthere's a lot of things that we could do more abstract in these meetings, if we plan the legwork outside of these meetings.
SeveMy phabricator comment was about this exactly. Trying to find a way we improve as a team. I do feel we need more time to discuss (not in meetings but in general at least)
GuusLike nyco said, that takes additional work though
ralphmHow to update the roadmap doesn't need a discussion, what's on it does and I'm glad we discussed it.
nycoonce again I agree with Seve that ideation happens during meetings, in real-time sync
MattJHowever it may make sense to have separate meetings for deeper discussions around various topics
nycoah, good idea
MattJ30 minutes is often not enough to cover one topic in detail
MattJand that happens quite often, it seems
MattJWe spend >90% of the meeting time discussing one thing
ralphmMattJ: ok, we can maybe plan ahead to extend a next meeting for a specific topic
ralphmI usually reserve a 1 hour slot for this meeting
MattJAs mentioned earlier I don't have room in my schedule to expand this meeting in its current timeslot, but sure, I agree in principle
ralphmbut try to keep it within 30min, to cater for the possibility a topic needs more time
MattJI did also, and will endeavour to return to that, but not for at least the next few weeks
ralphmThanks Guus for raising this
ralphm6. Date of Next
GuusI can not make it next week.
Guusbut don't let thta stop you
ralphmOh, right it is vacation for me, too.
ralphmSo I might not make it either
ralphmMaybe skip one?
GuusDepends on the remaining three 🙂
GuusI"ll definately not make it.
nycoplease review before you go: https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=en
SeveI should be available next week if nothing happens, but it all depends on what do we need to discuss, I guess
ralphmLet's try to indeed do some homework before the next meeting.
ralphmAnd review the pad by nyco
SeveGood meeting, thank you and have some nice vacation :)
pep.https://wiki.xmpp.org/web/XEP-Remarks/XEP-0313:_Message_Archive_Management Maybe this could use more context :x
pep."Missing "Give the the last N messages starting from the oldest" query" as a title
Ge0rGflow: you authored it... ⏫
pep.https://wiki.xmpp.org/web/index.php?title=Category:Spec_Remarks hmm. I'm not sure how useful that was though, considering everything is already on the same page.
pep.Also apparently there's a XEP category already.
pep.Which is exactly that, I guess I'll move that over
Ge0rGpep.: we could also move the "XEP and RFC Remarks" page into the category, then people would get redirected to the automatic list, even with it being less nice looking
pep.redirected? What magic do you need for that
Ge0rGpep.: I did it with https://wiki.xmpp.org/web/index.php?title=Easy_XMPP&redirect=no - `#REDIRECT [[:Category:Easy XMPP]]`
Ge0rGpep.: IIRC you must be wiki admin to move pages, though
ZashForbidden dark Mediawiki magic?
Ge0rGIncantations that will make your fingers fall off.
Ge0rGor your ears. or your eyes. depending on which way they go
Steve Killehas left
Ge0rGSo whom do I need to bribe to finally make https://github.com/xsf/mediawiki-docker/issues/2 happen?
Steve Killehas joined
flowGe0rG, not all, we need implementations of experimental XEPs, I am just not sure if a XEP mentioned in the compliance suite should have a certain amount of stability, or if it's just a pointer to the "next thing"
flowif compliance suites are supposed to point to the current state of the art, which experimental XEPs probably count as, then it shouldn't be included. If they are the map of the xep jungle, pointing out which xeps are (probably) ahead on the road, then you could and should include jingle file-transfer.
Ge0rGflow: there is the "Future Development" section for next things. XEPs in the CS should have some stability, and they should provide functionality needed by users
Ge0rGthe CS isn't about XEP status politics
flowCompliance suites could also be both, but then it should be probably marked which xeps are currently considered stable and which ones are the next big thing
Ge0rGJingle-FT has been there for over a decade, and I don't see any alternative to it
flowis there a rendered version of the proposed compliance suites somewhere?
Ge0rGflow: XEP stability is orthogonal to what users expect from a client
flowsure, but I also have the poor developers in mind
Ge0rGpoor developers using the wrong MAM namespace? :D
Daniel> Jingle-FT has been there for over a decade, and I don't see any alternative to it
Yet we are only slowly reaching a point where we have compatible implementations that are somewhat reliable in exchanging files
Dele (Mobile)has left
mathieuipep., poezio certainly does direct invites (if you mean 0249 by that)
lskdjfGe0rG, IMHO User Name Coloring should not be mandated by the compliance suite. If there is a client that does all the cool things but generates avatars similar to github or slack (patterns instead of single colors), that should not keep it from beeing an advanced xmpp client. Or really, if I don't want to color the names/avatars at all. It's a design thing and should be part of client diversity and choice. If you go that way you could as well mandate that clients have to do a conversation list instead of a roster for "consistency".
Ge0rGlskdjf: I'm sure that the Conversation list will become a thing in a year or two, and then will be added to CS
Ge0rGlskdjf: also nothing prevents your smart pattern avatar generator from applying the same color as other clients do
!XSF_MartinI found lskdjf is having a valid point.
Ge0rGIs our goal to appease client developers or to make XMPP finally suitable for normal people?
Ge0rGlskdjf: you are making a valid point indeed, but I disagree with that. Feel free to bring that up on standards@ and get more people behind you
!XSF_MartinI as a partly normal person am happy with my terminal not looking like a rainbow when chatting. 😃
lskdjfGe0rG, where does the "mandate the UI" end? when all clients look the same? there are different users and different use cases. Not everyone is happy with the same thing. many people actually like a roster, and they have a valid point. and if there's a client that provides them with a roster, that's good and not less XMPP-compatible.
Ge0rGI'm not going to get convinced, but sufficient negative feedback could certainly make me remove it again
Ge0rGlskdjf: I'm not saying "get rid of the roster", I'm saying "support an automatic synchronization of your open conversations over all clients"
!XSF_MartinI don't really see nickname colors as a usability but more as theming.
Ge0rGlskdjf: if the user wants to disable it, well, let them
lskdjf> I'm saying "support an automatic synchronization of your open conversations over all clients"
As a client you don't need that if you only offer a roster, though
Ge0rGlskdjf: well, then you aren't an advanced but just a core client. Live with it
lskdjfGe0rG, why? because some people think my preference in UI isn't the "correct" one?
Ge0rGlskdjf: no, because your UI preferences make it harder for users to migrate between xmpp clients
lskdjfmh I don't agree with your view on what the job of the compliance suite is. but you already said you won't be convinced.
lskdjfGe0rG, another point I have is that I'd like to suggest to only mandate vcard-temp for advanced IM clients.
Ge0rGlskdjf: I'm not even sure why it's in core.
lskdjfI also wouldn't mind seeing it removed 🤷️
Ge0rGI'm not an expert on vCard specs
pep.what's the story behind the NS format (changes) btw? jabber:x:foo, https://jabber.org/protocol/foo, urn:xmpp:foo
Zashjabber: is from before people learned how xmlns is supposed to work
Zashurn:xmpp: is after IETF standardization
pep.And the awkward one in the middle?
ZashThat's acceptable behavior
fippoif you don't have a urn for a namespace, you can use a url you control
ZashI'm personally a fan of xmpp: URIs as xmlns 🙂
pep.Yeah I also like that :)
fippozash: but you need to stay in control of prosody.im forever. for urn:xmpp the iana is in control and going to be around for longer :-)
Zashfippo, same applies to http://jabber.org
pep.fippo, as a temporary solution
Zashfippo, aren't we (the XSF) in control of urn:xmpp:* tho?
Zashurn:uuid: is cool too, but somewhat verbose
pep.Ge0rG, I'm kind of duplicating work that was already done on the wiki with that category :/
pep.But I'll take the opportunity to unify all of it
pep.Who do I need to bribe to become a wiki sysops btw
fippozash: the iana delegated the subnamespace to the xsf registrar
Zashfippo, so we're in control. or can they un-delegate it? if so, it's no different than DNS based URIs?
fippozash: hrm, rfc 8141 doesn't say whether the iana can undelegate. lets pester one of the authors? :-)
stpeterThere is no undelegation or redelegation for URN namespaces. URN namespace assignments are permanent because the whole point of URNs is permanence. However, we did not explicitly mention this in RFC 8141.