KDE goals IRC office hour

[Lydia Pintscher]

Hey folks :)

We had a nice office hour to talk about the goals. If you couldn't
make it to the office hour you can read up on what we talked about in
the attached log.


Cheers
Lydia

-- 
Lydia Pintscher - http://about.me/lydia.pintscher
KDE e.V. Board of Directors
http://kde.org - http://open-advice.org
-------------- next part --------------
[16:59:28] <sebas> Hi there!
[17:00:07] <Nightrose> hey everyone :)
[17:00:25] <Nightrose> We're doing an office hour for the KDE goals in the next hour here.
[17:00:31] <Nightrose> Who is here for the office hour?
[17:00:39] <ngraham> I am!
[17:00:41] <Fuchs> hello :)
[17:00:57] <kaktus> o/
[17:01:07] <Nightrose> Nice!
[17:01:22] <Nightrose> So to give those of you new to it some intro:
[17:01:29] <sebas> I'm there, answering questions about the privacy goal
[17:01:50] <Nightrose> Last year we decided that it is time to clarify what the KDE community as a whole is working towards.
[17:02:09] <Nightrose> We had a process where goals for the next 3 to 4 years could be proposed.
[17:02:25] <Nightrose> Then there was a vote among the KDE community members and we selected the top 3.
[17:02:57] <Nightrose> This means we are spending time on improving KDE in 3 ways: productivity and usability of basic software, privacy and onboarding of new contributors.
[17:03:11] <Nightrose> And we're here today to answer questions related to that.
[17:03:24] <Nightrose> I suggest we start with a short intro of each of the goals.
[17:03:29] <Nightrose> sebas: want to start?
[17:04:10] <sebas> sure :)
[17:04:54] <sebas> so we had defined the vision for KDE ... which is:
[17:04:58] <sebas> "A world in which everyone has control over their digital life and enjoys freedom and privacy. "
[17:05:30] <sebas> so privacy is one of the cornerstones of this, the idea being that Free software is already the norm world-wide, and that these values are closely connected to these of privacy
[17:06:01] <sebas> and, being a community project, we have the credibility to really deliver software respecting privacy, because we're not driven by
[17:06:26] <sebas> collecting data, we're not bound by the U.S. government (for example), and we offer fully transparant software
[17:07:03] <sebas> also, privacy is increasingly important in the post-Snowden world, and getting more important every day, while most people don't understand it, so we have a mission right there
[17:07:22] <sebas> it's also a value overarching many of KDE's subprojects, though in some it plays a bigger role than in others
[17:07:53] <sebas> I could go on for another 53 minutes and we'd be done, so if you want more background, I've blogged about it at https://vizzzion.org/blog/2017/11/kdes-goal-privacy/ :)
[17:08:04] <Nightrose> Thanks, sebas :)
[17:08:09] <Nightrose> ngraham: You next?
[17:08:10] <sebas> The fully goal description is at https://phabricator.kde.org/T7050 btw
[17:08:19] <ngraham> sure!
[17:08:29] <ngraham> Hi, I'm Nate Graham, and I spearhead the Usability & Productivity initiative (https://phabricator.kde.org/T6831)
[17:08:53] <ngraham> This iniatitive is all about focusing on our basic software like Plasma, Discover, Dolphin, Kate, Gwenview, Okular, and Konsole; and the frameworks that underpin them like KIO, Baloo, and Kirigami
[17:09:06] <ngraham> The goal is to improve their usability and polish, and add productivity-related features that make them even more suitable for work and professional use
[17:09:52] <ngraham> We want to make sure that our software is not only competitive but superior to alternatives, so that people will want to use our platform in the first place, and fall in love with it for its polish, usability, and productivity
[17:10:28] <jankusanagi_> I have to say, this initiative has produced great results already; thanks for that =)
[17:10:34] <ngraham> I blog about our progress on a weekly basis (new posts every Sunday), which you can see at https://pointieststick.wordpress.com/category/usability-productivity/
[17:10:47] <Nightrose> jankusanagi_: \o/
[17:10:57] <ngraham> Thanks ‎jankusanagi_‎!
[17:10:58] <sebas> agree with jankusanagi_, great results so far!
[17:11:33] <jankusanagi_> also, the blogging-about-it part is excellent!
[17:12:02] <Nightrose> ngraham: anything else or should we move on to neofytosk?
[17:12:20] <ngraham> I'm done!
[17:12:28] <tetris4[m]> I love how this goal keeps people excited and this is evident through Nate's posts.
[17:12:48] <Nightrose> Indeed!
[17:12:49] <tetris4[m]> so hello from me as well =)
[17:13:00] <ronnoc> o/
[17:13:09] <tetris4[m]> I'm Neofytos Kolokotronis and I proposed the Streamlined onboarding of new contributors goal.
[17:14:02] <tetris4[m]> For the KDE community and its projects to stay healthy and continue to grow, it is very important that the flow of new contributors is continuous and why not increasing as we move forward.
[17:14:21] <tetris4[m]> In short, the streamlined onboarding goal is about making the most of our community and the individuals that show interest in getting involved.
[17:14:56] <tetris4[m]> My vision is to do this by working together to lower the entry barrier for new people to step up and also support those that are in their first steps as new contributors.
[17:15:16] <cmacq2> interested in the views of a sort of 'drive-by' contributor on this?
[17:15:28] <tetris4[m]> A more detailed blog post can be found here: http://neofytosk.com/post/kde-community-goal-streamlined-onboarding-of-new-contributors---introduction/
[17:15:49] <ngraham> ‎cmacq2‎: we are definitely interested in your perspective!
[17:16:15] <at1a5> Why are drvie-by contributers needed?
[17:16:28] <tetris4[m]> and here is the initial task of the proposal: https://phabricator.kde.org/T7116
[17:16:39] <tetris4[m]> cmacq2: actually this is part of the goal, to gather feedback from new or even episodic contributors!
[17:16:57] <cmacq2> @at1a5 I meant as in 'drive-by patches'
[17:17:11] <at1a5> what are drive-by patches?
[17:17:15] <cmacq2> you don't spend all your free time on the project, but you are sufficiently interested to help fix the occasional bug
[17:17:16] <Nightrose> Ok thanks for the intros to the goals :)
[17:17:26] <at1a5> ahhh got it!
[17:17:28] <Nightrose> Then let's go into the discussion part.
[17:17:38] <cmacq2> as for my perspective on the onboarding
[17:17:58] <cmacq2> if you *know* about IRC it is a lot easier, because the community is sufficiently active
[17:18:07] <cmacq2> that you get near-realtime support on things
[17:18:49] <cmacq2> the forums ... not so much.
[17:19:00] <cmacq2> kdesrc-build is awesome
[17:19:01] <ngraham> FWIW we mention IRC right on our Get Involved page: https://community.kde.org/Get_Involved#Getting_in_touch_and_working_together
[17:19:46] <Nightrose> cmacq2: because it takes to long to get a reply?
[17:20:12] <cmacq2> that, and you get the feeling the place is mostly abandoned if you look for the technical stuff
[17:20:30] <Nightrose> Ok that's useful input. Thanks.
[17:21:30] <ngraham> My sense is that the KDE subreddit is sort of becoming the de facto replacement
[17:21:36] <Fuchs> a lot of technical discussion is happening on phabricator these days, which is also linked on that page (the forum is not)
[17:21:38] <ngraham> (for good or for ill)
[17:21:44] <sebas> I as a developer only occasionally check the forums
[17:21:48] <cmacq2> what I feel remains quite difficult is actually setting up a sane test/dev environment
[17:21:54] <sebas> I somehow prefer reddit etc. for this kind of thing
[17:22:00] <cmacq2> I mean kdesrc-build does help you a lot with actually getting everything built
[17:22:14] <cmacq2> but it can do only so much to help you install dev packages from your distro, for example
[17:22:19] <ngraham> ‎cmacq2‎: we have a page for that: https://community.kde.org/Get_Involved/development
[17:22:38] <sebas> cmacq2: agree, it's actually a lot harder if you want to do arm builds (for plasma mobile for example)
[17:22:43] <ngraham> which includes information about installing dev packages, in fact
[17:23:10] <sebas> we had work going on doing this in a chroot or vm, but that usually makes access to the graphics card a lot harder, among other things such as sharing the host filesystem
[17:23:19] <cmacq2> ngraham: it does, but it doesn't tell you that if cmake errors out with cryptic find_package() message foo
[17:23:32] <[ade]> IRC vs forums is a bit of a balancing act. Some communities I hang out in, IRC is the useful source of information and the forums are not; other communities it's the other way around. It depends on who-is-awake-when.
[17:23:41] <sebas> it also vastly depends on what you want to do, if it's just hacking on an application, not much of a problem
[17:24:00] <ngraham> ‎cmacq2: it's a wiki, so go ahead and add pertinent information if you encounter and fix problems!
[17:24:02] <sebas> if you want to work on a framework and test your solution in Plasma ... it's pretty hard
[17:24:10] <cmacq2> pretty much that
[17:24:13] <sebas> and if multiple processes are involved, you need to be really patient
[17:24:35] <sebas> and then again, if it's hacking a plasmoid, that's quite easy again
[17:24:47] <cmacq2> what would be really nice, is if you could have a way to do dev work in a 'clean' room environment
[17:24:51] <cmacq2> at least for testing
[17:24:56] <Nightrose> cmacq2: is there anything else you struggled with?
[17:24:57] <tetris4[m]> so are we talking about lack of documentation here?
[17:25:01] <sebas> in fact, I see people hacking qml files quite often, even casual users (which is an achievement on its own)
[17:26:18] <sebas> fwiw, I as a Plasma hacker have a system which has everything from Qt up built from source, this allows me to hack on everything
[17:26:24] <sebas> and it's a proper nightmare to install
[17:26:32] <cmacq2> tetris4[m]: not really documentation, I get the sense there is a step between kdesrc-build and testing your custom application that we could help with
[17:26:35] <Nightrose> heh
[17:27:00] <cmacq2> ideally something to automate it
[17:27:34] <cmacq2> so you can run your custom version of the app without impacting your main system, which makes developing KDE on KDE a lot safer
[17:27:58] <Fuchs> well, one could provide a full OS (which would be needed due to HW access) that you can dual-boot into, but that would require you to reboot, which is also a bit of a pain
[17:28:06] <argonel> i'm using direnv to manage the environment variables to build and run locally built stuff, haven't had to install any locally built packages yet
[17:28:15] <Fuchs> other solutions are unfortunately either distribution specific or in shape of a virtual machine, which has limited access
[17:28:37] <ngraham> personally, I do as much of my development as possible in a KDE Neon VM
[17:28:48] <Fuchs> so all solutions have advantages and disadvantages. I wonder if one could use a sandboxing like flatpak to provide an environment, though
[17:29:00] <ngraham> I find that it works great for me, and provides that hard separation of personal system/dev environment that I need
[17:29:06] <ronnoc> Maybe this is naive, but couldn't we produce a "everything built from src VM image" and make it available for download? Might not cover every case (kio comes to mind) but wouldn't it cover most?
[17:29:20] <ronnoc> ^ nate beat me to it :)
[17:29:22] <Fuchs> until then, having a neon development system in a VM if you don't need HW access or dual boot if you need it  (e.g. working on kwin or whatnot) should be mostly straightforward
[17:29:25] <ngraham> ‎ronnoc‎: That's essentially KDE Neon Dev Unstable
[17:29:43] <cmacq2> yeah, that was one thing I was wondering about as well: both the VM (think emulator like Android), and the flatpak approach
[17:29:44] <ngraham> it works great for that purpose, until you need to test a hardware feature
[17:29:55] <Nightrose> ngraham: do we need to advertise this more then?
[17:30:00] <ronnoc> yes
[17:30:24] <cmacq2> also, tying in with the privacy/security/reliability aspect:
[17:30:34] <argonel> ngraham: are you using docker?
[17:30:35] <cmacq2> could we provide tooling to build KDE software in a reproducible fashion?
[17:30:40] <ngraham> no, just a VM
[17:30:49] <ngraham> I keep meaning to learn Docker, but haven't gotten around to it
[17:31:05] <ngraham> we do have some rudimentary documentation on this though: https://community.kde.org/Neon/Docker
[17:31:08] <Fuchs> cmacq2: there already is some CI in place, if you mean that
[17:31:32] <cmacq2> no, locally reproducible
[17:31:32] <Fuchs> cmacq2: https://community.kde.org/Infrastructure/Continuous_Integration_System   which is basically "build KDE software in a reproducible fashion" for tests and the likes
[17:31:37] <tetris4[m]> Fwiw, I remember this talk in last year's Akademy that I think is related: https://conf.kde.org/en/akademy2017/public/events/372
[17:31:42] <Fuchs> oh, that is trickier, I guess, due to distribution differences
[17:32:29] <[ade]> and reproducible builds (.org?) has reports on the state of KDE software, mostly built on Debian. Many KDE bits are not-quite-reproducible (in the sense of bit-exact the same when built twice). There are common causes for that, but .. that's probably chasing it a bit too far for this office hour.
[17:32:44] <cmacq2> probably.
[17:33:03] <Nightrose> But might be a nice thing for someone looking for something to contribute
[17:33:25] <cmacq2> my point is: that if we could get that to work, what it would imply is that it would be *really* easy to build & for us to know that what they are seeing matches what we are expecting
[17:33:33] <Nightrose> If you are looking for contacts I can introduce you to one of the main people behind it
[17:33:41] <Nightrose> *nod*
[17:34:31] <cmacq2> if we can get something off the ground here, well *I* am definitely interested as you can tell ;)
[17:34:50] <Nightrose> Hehe deal. Let's connect after the offie hour then.
[17:35:33] <Nightrose> Ok more questions? Otherwise I have one.
[17:35:35] <ronnoc> So in addition, maybe another takeaway here is that https://community.kde.org/Get_Involved/development should perhaps have a section on running Neon-Dev-Unstalbe for a temporary and clean playground to mess in?
[17:35:46] <Nightrose> Yes sounds like it
[17:35:52] <ronnoc> in a VM or Docker
[17:36:06] <sebas> would anyone want to write this?
[17:36:31] <ngraham> I can, since that's my primary environment
[17:36:31] <sebas> It's not rocket-science, just needs perhaps two or three hours of detailed writing and testing this alongside, and then we can refer to it
[17:36:41] <sebas> sweet, ngraham!
[17:36:43] <cmacq2> cool!
[17:36:46] <ngraham> the question is, what should be its relation to the existing instructions?
[17:37:00] <Nightrose> It would probably be good to have the eyes of someone new for this.
[17:37:05] <ngraham> we don't want to present multiple paths here or else it's really confusing for new contributors, and makes it seems like we'r ehedging our bets
[17:37:53] <sebas> ngraham: as addition to the "test your patch" section maybe?
[17:38:05] <ngraham> I would favor making this the default new contributor path, and moving all the stuff about how to build on bare metal to the more advanced page (because it is more advanced, really)
[17:38:13] <ronnoc> Well, IMHO, for someone -completely- new to Plasma, a VM would seem ideal to me as the lowest-pain-way into it
[17:38:28] <tetris4[m]> How about putting this under "Setup your development environment", and perhaps link elsewhere for per-distro specific instructions?
[17:38:44] <ngraham> if we're recommending a VM, we don't need per-distro instructions, which is nice
[17:39:20] <tetris4[m]> sure, but they are probably still useful for people that want to go down that path.
[17:39:21] <argonel> i'm certainly curious about the vm workflow, look forward to reading it :)
[17:39:27] <ngraham> my proposal is to make the main page introduce KDE Neon as a VM development environment, and put all the other stuff on the more advanced "Build From Source" page
[17:39:44] <ronnoc> someone hosing their system in unforeseen ways by updating packages on a daily driver seems a bit like adding potential failure points so I agree w/ Nate
[17:40:03] <Fuchs> sounds good to me, if you add instructions (under advanced, maybe) on how to install the VM into dual boot it would also fix the edge case of needing hardware access (GPU and bluetooth come to mind, potentially others)
[17:40:51] <ngraham> I don't know how to dual boot into a VM environment,can you do that?
[17:40:55] <ngraham> if so, that sounds pretty cool
[17:40:58] <[ade]> keep in mind that the stronger we push KDE Neon as The One True Way To Develop For KDE, the harder we could be alienating not-Neon distro's
[17:41:18] <ngraham> Neon isn't a distro, it's basically just a dev environment
[17:41:19] <[ade]> ngraham: it's a neat edge case with VirtualBox, for one thing
[17:41:21] <BCMM> potentially stupid question: is there a reason it can't run in a plain old chroot and access the system's real X server and bluetooth stack for stuff like that?
[17:41:29] <sebas> ngraham: check with ochurlaud, he's been restructuring this stuff lately
[17:41:45] <einar77_work> [ade]: I concur (but I won't press this further, so that the discussion can go on)
[17:41:51] <ngraham> Who is ochurlaud? (i.e. real name?)
[17:42:03] <sebas> Olivier Churlaud
[17:42:12] <bshah> ngraham: I've been recently experimenting with running Plasma Mobile in qemu and building/testing software on it ... I would be happy to review/discuss more about this workflow
[17:42:21] <ngraham> cool
[17:42:22] <[ade]> ngraham: you set up VBox with a passthrough vmdk pointing to physical disk, so you can physically boot to that disk, or start a VM with the same. It gets messy if you suspend one and then boot the other, though :)
[17:42:44] <ronnoc> [ade]: not the one true way, just maybe the recommended one for someone new & looking to contribute, I'm sure the other sections for setting up envs in particular distros isn't going anywhere
[17:42:49] <tosky> BCMM: you don't need a chroot to develop KDE stuff; for Plasma it may be a bit more complicated
[17:42:54] <asturm> pff, suspend... witchcraft
[17:42:57] <Nightrose> *timekeeper hat on* 18 mins left 
[17:43:15] <ngraham> [ade] I will look into that, thanks!
[17:43:18] <einar77_work> ronnoc: those in general will probably need adjustments (as a second step), they're too barebones to be useful
[17:43:28] <einar77_work> (I just looked through them)
[17:43:42] <jankusanagi_> ngraham: people see KDE Neon as a distribution; they can download a .iso and install it as their OS → distro
[17:43:58] <sebas> let's not discuss this here now though
[17:44:10] <[ade]> .. but let's not discuss that particular elephant
[17:44:11] <ngraham> ‎jankusanagi_ That's a pretty significant failure of messaging on our part, and yes, a discussion for another time
[17:44:18] <sebas> is there anything people would want to know or discuss about the privacy goal?
[17:44:23] <jankusanagi_> sorry, not my intention :p
[17:44:38] <sebas> or comment on what you're especially unhappy with in terms of privacy?
[17:44:50] <cmacq2> not unhappy
[17:44:53] <sebas> to me it sometimes feels it's a bit too abstract and not directly beneficial, or seen as that
[17:45:03] <Nightrose> also: What are the places where privacy matters most to you?
[17:45:10] <cmacq2> but we don't really do the flatpak thing yet
[17:45:27] <bshah> I've question about Privacy goal. I understand that we're promoting privacy (and security, which is not scope for this question currently) but my question is, what privacy related products we're already offering? and what we want to offer?
[17:45:37] <bshah> (both software/hardware wise)
[17:45:57] <cmacq2> I think this is where our flatpak or $app_runtime integration comes into play
[17:45:58] <sebas> to me personally, our own tools are just fine, but we can't really cover the walled gardens, so we don't reach far enough (and I don't see an easy solution to that, too)
[17:46:15] <cmacq2> you could offer things like partial access to user's contacts etc.
[17:46:31] <cmacq2> but only if you really do get to arbitrate
[17:46:37] <sebas> bshah: about half of our software relates to privacy
[17:46:45] <ronnoc> to me, privacy in applications is really up there in importance. e.g. Vaults and things like what will Falkon do to ensure user's safety and privacy while browsing the web?
[17:46:59] <sebas> krita less so, kmail definitely and there's a lot of stuff in the middle (such as plasma)
[17:47:09] <cmacq2> and then we also need to look at security
[17:47:29] <sebas> yes, privacy and security are closely related
[17:47:31] <[ade]> our oftware can promote safe, secure, private communication for whatever they need to do.
[17:47:32] <cmacq2> not just security bugs per se, but also relying on old openssl with the kdelibs support stack
[17:47:42] <Fuchs> personally I don't think it's about offering software specifically for privacy, but rather make sure that our software keeps privacy in mind (kmail, kgpg/kleopatra, browsers, file managers ...) and makes things easy for users to achieve privacy
[17:47:56] <sebas> also secure protocols, wayland vs. x11 for example
[17:48:11] <sebas> Fuchs: both are in scope
[17:48:14] <cmacq2> oh, most definitely
[17:48:33] <tetris4[m]> communication and encryption tools come into play here, and also tracking.
[17:48:33] <cmacq2> and things like not using /tmp and general temp file badness
[17:48:45] <sebas> I'd go as far as privacy by default, you should be able to trust the software without changing settings first
[17:48:47] <[ade]> another little example: if baloo is going to store index information per-device, then the database per-device needs to be audited to make sure that private information doesn't leak via the index.
[17:48:59] <vkrause> offering alternatives to some particular privacy-invasive google service comes to mind
[17:49:03] <sebas> "KDE takes care of my privacy by choosing decent defaults" alike
[17:49:51] <bshah> [ade]: nice example, is it already case or should we report bug? :)
[17:49:53] <sebas> vkrause: yes!
[17:49:56] <ronnoc> what is our recommended chat / IM solution these days and how does it achieve those goals. And, should we be shipping one by default? We still list kopete as the app in many places.
[17:50:08] <sebas> ronnoc: we're on IRC! :D
[17:50:11] <cmacq2> what is the state of kwallet...
[17:50:21] <ronnoc> sebas: :P
[17:50:26] <sebas> j/k ... I think community consensus leans towards matrix, but we're not there yet
[17:50:39] <sebas> and neither is matrix, but it's the most promising future solution
[17:50:59] <jankusanagi_> XMPP ftw =)
[17:51:01] <sebas> Sho_ is spearheading the client side, and also in contact with the protocol and server people
[17:51:04] <[ade]> kiosk, too, is one of those "things"
[17:51:23] <bshah> reference to cmacq2 question: can we do something about kwallet? due to it's annoyance I've seen lot of people "disable" kwallet and hence storing passwords in plaintext..
[17:51:28] <sebas> is it, though, [ade]?
[17:51:40] <Fuchs> both (IRC and matrix) will be supported
[17:51:47] <bshah> there is solution for it kwallet-pam, but we're not advertising it more I believe
[17:51:49] <sebas> it's about restricting users for certain environments, the overlap with privacy is pretty slim IMO
[17:51:49] <argonel> does kwallet actually interfere much?
[17:51:56] <Fuchs> details are at  https://blogs.kde.org/2017/09/05/konversation-2x-2018-new-user-interface-matrix-support-mobile-version    mostly
[17:52:11] <argonel> i'm used to macos' keychain where you only notice it when its broken
[17:52:53] <einar77_work> bshah: kwallet-pam needs downstream adjustments, but once set up, it's painless
[17:53:07] <argonel> kwallet5's asking about blowfish vs. gpg is a bit annoying, but maybe that's solved now?
[17:53:16] <einar77_work> argonel: keeps on asking actually
[17:53:28] <cmacq2> kwallet + chromium can definitely be annoying -- the combo doesn't seem to take "no"/cancel for an answer
[17:53:28] <argonel> ah.
[17:53:32] <einar77_work> perhaps it's a matter of UI
[17:53:33] <vkrause> btw, if someone has travel booking confirmation emails, boarding pass emails or pkpass boading pass files to donate to the work for a free travel assistant beyond Google Now/TripIt, feel free to send those to me :)
[17:53:41] <einar77_work> UI/UX
[17:53:49] <sebas> cmacq2: do you know if there's a bugreport about this?
[17:53:58] <cmacq2> don't know
[17:54:00] <tetris4[m]> the kwallet issues sound like things that Usability goal could tackle ;)
[17:54:01] <sebas> problem is that kwallet isn't exactly actively maintained or developed
[17:54:03] <argonel> well, the thread about the future of kwallet was quite self-defeating
[17:54:33] <cmacq2> filing targeted/focused bug reports is also a thing for onboarding, come to think of it...
[17:54:41] <ngraham> yes, let me dig up the bug report...
[17:54:43] <cmacq2> (it coul be easier)
[17:54:53] <ngraham> https://bugs.kde.org/show_bug.cgi?id=333137
[17:55:09] <ngraham> also potentially https://bugs.kde.org/show_bug.cgi?id=353960
[17:55:43] <Nightrose> ngraham knows all the tickets :D
[17:55:44] <ngraham> FWIW we have a whole page on how to write good bug reports: https://community.kde.org/Get_Involved/Bug_Reporting
[17:55:47] <ronnoc> vkrause: related to  KDE Now by chance?
[17:55:59] <ngraham> I have a gigantic master text file of all the most annoying KDE issues :)
[17:56:21] <tetris4[m]> cmacq2: yes, and there is a whole discussion on the task about bugzilla about that which got merged with onboarding, I plan to bring it up again as part of the goal.
[17:56:23] <bshah> ngraham: would it make sense to put this text file in e.g etherpad?
[17:57:39] <vkrause> ronnoc: kinda, but pushing this a lot further than KDE Now did
[17:58:35] <sebas> vkrause: making kdab lifestyle easier? :)
[17:59:09] <vkrause> travelling regularly certainly helps with the motivation ;-)
[17:59:17] <sebas> I bet it does
[17:59:42] <Nightrose> Hehe alroght folks. We're almost at the end. Any more input/questions/... on the goals?
[17:59:59] <Nightrose> Anyone looking to help with making them happen?
[18:00:00] <ronnoc> vkrause: Very cool. As a Kolab / kdab user, I'm all for that!
[18:00:16] <vkrause> I managed to get to FOSDEM with a screenshot of a KDE-rendered boarding pass, next step is getting to the PIM sprint with one live rendered on my phone :)
[18:00:50] <sebas> what's a kde rendered boarding pass?
[18:01:02] <vkrause> not using the images you get from airlines, but the updateable pkpass files
[18:01:27] <vkrause> ie all visuals and the barcode have to be rendered by our code
[18:01:49] <sebas> I don't even know what a pkpass file is :)
[18:01:57] <DottorLeo> hi!
[18:02:10] <sebas> but also, my sweet sweet lady is waiting for me
[18:02:15] <sebas> in the real world
[18:02:19] <Nightrose> If you want to help with any of the goals feel free to ping, tetris4[m], ngraham, sebas or me. We're happy to help point you in the right direction to get started
[18:02:28] <sebas> yes, absolutely
[18:02:43] <vkrause> sebas: Apple Wallet pass files
[18:02:43] <sebas> I'm usually here on IRC, easier to reach during European office hours
[18:02:57] <sebas> vkrause: still doesn't ring a bell :)
[18:02:57] <Nightrose> Thanks for joining, everyone. If you found this useful we'll do another one.
[18:03:00] <ronnoc> Nightrose: Thank you for hosting! Lots of good info here in this short time, that's for sure.
[18:03:12] <sebas> +1 on the thanks, it was useful and enjoyable! :)
[18:03:18] <sebas> thanks Nightrose :-*
[18:03:24] <argonel> yes, thanks all! look forward to the next one :)
[18:03:26] <Nightrose> :*
[18:03:26] <cmacq2> yes, thanks!
[18:03:31] <eukara> thanks :)
[18:04:30] <jankusanagi_> yep, thanks =)
[18:04:35] <tetris4[m]> +1, looking forward to the next one =)