Topic to discuss
Thoughts on the release process? Do we want to schedule releases? How often do we want to release?
Issues on github
Fla: I think we should use more the "milestone feature" of github. Right now, we almost only use it when something is already merged. To decide during meetings what we want to see in the next meeting and put a milestone on it would allow to share this to potential contributors saying "this is the target".
So, what do we want to see in the next release (not the one coming right now, the next one)?
- #4416 opengraph 404
- #4264 youtube embedding broken
- #4683 correctly strip HTML and Markdown
- #4269 Comments are out of order
Clean up issues
- Read some old issues, starting with the least recently updated ones.
- Check if the bug still exists, if some more information is needed and if the issue is suitable for newcomers.
- If it is an important or easy to fix issue: decide if we want to add it to a milestone / promote it in a bugmash monday
These tasks can be done by a non-technical person, so we can call for contributors, we only need people on pods using the develop branch.
Improve podmin's life
A nice admin panel
It's important to help podmins to deal with common tasks easily without having to use command lines / geeky stuff. The admin panel should be improved to add new actions like:
- Ability to remove a user (including remote user) to fight spam
- Ability to close / reopen a local user
- Ability to clean ghost pods to improve performance
- The list of the 500 errors occurred
- Current memory / cpu used?
Related github issue: https://github.com/diaspora/diaspora/issues/4183
Graphical interface to install / update
Recently more spam has been appearing on Diaspora pods. Some things are already being fixed like Captcha support which should land soon in develop. Other things we should do to combat spam?
A hosting company recently sent this to the press team, promising "diaspora hosting for as low as $4/mo" in a shared hosting environment. They are basically making (afaict) non-valid promises using the Diaspora official branding (see included url).
Hello Sean, I noticed that you are the community manager so I wanted to reach out directly. Please let me know if there is someone else I should contact to discuss further. My name is Gregg Hawkins and I'm the marketing manager for Arvixe, a web hosting company. I wanted to inquire about becoming a recommended hosting provider to the visitors of your website. I have created a landing page, which can be found here: http://www.arvixe.com/diaspora-hosting More specifically, I'm wondering what it would take for you to create a tab on your website that says "Web Hosting" and on that page simply put a paragraph introducing Arvixe and then linking to us? I'll be looking forward to a positive response! Regards, Gregg Hawkins Marketing Operations Officer
How shall we respond?
What did we decide?
goob: Let's start now. Hopefully Fabian will arrive soon. flaburgan: Okay so first topic on https://wiki.diasporafoundation.org/Meetings/20140114 flaburgan: the release process flaburgan: The point is, the stable version is too late behind the develop branch jaywink: Wiki: https://wiki.diasporafoundation.org/Release_process goob: I'm not sure set dates are a good idea for the project as it is now flaburgan: many bugs fixed in september are still not available in master, this is bad goob: while the development is being done by a fluctuating number of people doing it in their spare time.while the development is being done by a fluctuating number of people doing it in their spare time. goob: (oops) flaburgan: goob, fixed dates are maybe not the solution, but at least an idea MrZYX: git log --oneline master..develop | wc -l MrZYX: 252 flaburgan: like "max 3 months between two releases" MrZYX: not that much flaburgan: MrZYX, it's not about the number of changes MrZYX: IMO it is flaburgan: more about the time they wait jaywink: I don't like fixed dates either, but a bit more often than currently would be nice. better release often than be too slow goob: I like the idea of a release cycle based on achieving milestones jaywink: we don't want too many pods moving to the develop branch so releasing working stuff regularly would be important flaburgan: we chose a long release number, release.major.minor.hotfixes flaburgan: so we can release minor version without problem goob: jaywink Do you think we should do more minor releases? jaywink: goob, yeah jaywink: milestones are nice but what happens when some big item does not get ready that is in the next milestone? it delays everything - not good goob: I think use milestones to prioritise rather than have them set in stone marekjm: new version every N months regardless of the number of changes marekjm: ? MrZYX: also might create the false impression that work on a specific item is not desired goob: So no release would be held up indefinitely because of one milestone not completed. marekjm: I think milestones shouldn't be tied to minor versions IMO flaburgan: I like the approach of mozilla, release at "fixed" date (can variate one week but not more) including only what's ready when the date is here goob: (Milestones actually next item on flaburgan's agenda) marekjm: flaburgan: +1 jaywink: MrZYX, you are the only one here who has done releases? how long does it take to push one out and is there any way to streamline it? goob: prob with fixed dates is releases with little value goob: especially for a project with no full-time developers. jaywink: fixed date is ok if it's a fixed date that happens often :D MrZYX: we're not enough active developers for fixed date release. period. MrZYX: jaywink: fabian has done one or two too, florian one I think flaburgan: that's true when we look at the october month flaburgan: not a single commit :( MrZYX: if the prep work is done (announcement, gem updates in the changelog) its < 20 minutes goob: we could perhaps set an aim something like 'At least 3 major releases per year' flaburgan: goob, that would put some pressure goob: also have to consider whether it's worth each podmin updating - release needs worthwhile things in it. jaywink: what about taking an AP at every single meeting here (now that we have these, yay) to decide on release status - a simple question = release or not? then we either release or not on a monthly basis, likely less goob: Fla, we've done 4 per year so far. DeadSuperHero: I kind of like that. flaburgan: my point is, I really want to avoid the situation we are right now: there was enough to release in the middle of december, and we are still waiting for it MrZYX: jaywink +1 flaburgan: goob, major? only 2 flaburgan: jaywink, what's an AP? jaywink: we cannot decide how many major releases we do - it depends if we have major stuff :) goob: oh yes sorry. Got mixed up. jaywink: flaburgan, Action Point - agenda item :D svbergerem: jaywink +1 flaburgan: okay, this seems okay with me flaburgan: once per month, we discuss if we want to release now or not marekjm: jaywink: I think it's a good idea flaburgan: is everybody okay with that? flaburgan: one month seems nice goob: Like jay's idea, to take poll of whether we're close to a release at each meeting. MrZYX: we should decide who's in charge to do one too then jaywink: must use these meetings for something ;) MrZYX: because I got exams for the next three weeks MrZYX: what I want to say, I'm not always here to save your back jaywink: MrZYX, would gladly help but no rights ;) goob: Good point. We do need more people who can do the crucial things MrZYX: jaywink: you want some? goob: so we're not reliant on one or two people to be available all the time. jaywink: MrZYX, always :D jaywink: I'm no ruby expert but I know enough git I think DeadSuperHero: What does everyone think about task delegation? jaywink: DeadSuperHero, what do you mean? DeadSuperHero: I don't want to be the one to say "oh, let's use yet another tool", but something like Trello might be nice just for claiming tasks to do. DeadSuperHero: I just wonder whether the way we delegate who's working on what is a little cluttered. svbergerem: I think it depends on how often we need something like that flaburgan: github is enough imo jaywink: I guess the problem is that we don't have full time or even part time developers, only people working on their free time - so traditional task management might not work goob: Shall we try to make a decision about release cycle? flaburgan: goob, what do you mean? flaburgan: for this one? jaywink: the question: during each monthly meeting we decide whether to release or not? marekjm: I agree with jaywink, this wouldn't probably work out well for us svbergerem: +1 jaywink: goob, ? flaburgan: we can discuss about the next release right now flaburgan: we are waiting for someone to review the upgrade to devise 3.2 by MrZYX goob: I mean what to do about the agenda item: release cycle. goob: Is jaywink's idea the answer to that, or is there more to decide on? flaburgan: when this will be merged in develop, develop pods will pull that and test it for at least a week flaburgan: then, we will push a release jaywink: goob, if my idea gained support (I think it did) then release cycle would be "per month or less" :) flaburgan: https://github.com/diaspora/diaspora/pull/4511 flaburgan: jaywink, I would say per month or more, if we decide to report to the next meeting the release flaburgan: that's what I understood jaywink: well 12 meetings in a year = max 12 releases a year svbergerem: jaywink: I'd like to add "try at least every third month" to push bug fixes to the pods but still decided on a monthly basis goob: Do we need to do anything else to prompt getting ready towards each release? jaywink: svbergerem, yeah agree flaburgan: jaywink, yeah, sorry, I understood "one release per month or less (than a month) :p" goob: Such as focus energies on particular tasks to get them in the release. goob: Which sort of ties in with milestones (next agenda item). jaywink: should we first decide two things; jaywink: 1) do we agree to the proposal of deciding each release in the monthly meeting? flaburgan: yeah, milestone powa flaburgan: 1) yes :p goob: I think 1) has been agreed. jaywink: 2) do we decide to do a release asap or wait till next meeting? flaburgan: jaywink, I think we will decide that at each meeting jaywink: if the devise PR is wanted in, we should decide in the next goob: on 2) do you mean for this next release, or for future meetings/releases? jaywink: goob, this next release marekjm: 1) decided and put in the pad marekjm: 2) I think we should wait until the mext meeting marekjm: *next flaburgan: jaywink, don't you agree with what I said? we release as soon as devise is merged and tested goob: next release asap unless there is anything major holding it up. goob: and if someone (maybe jaywink) is available to push the release while MrZYX is busy. flaburgan: goob, we need someone to review MrZYX work jaywink: IMHO release asap after devise is in is fine if we agree on that flaburgan: I agree :) svbergerem: agree goob: I agree MrZYX: I abstain goob: of course, 'asap' might mean after the next meeting if the review of the devise work takes a long time! goob: but the intention is as soon as we can. flaburgan: yeah flaburgan: let's decide the release number in the same time flaburgan: 0.2.1.0 or 0.3.0.0? flaburgan: is this a major or a minor version? goob: the question is: is there anything committed which merits a major version number? flaburgan: Ruby2 flaburgan: eventually MrZYX: captcha is a major UI/UX change -> major version bump jaywink: +1 for major jaywink: we've got a huge list of changes :) goob: raven24's work on federation was talked about as the thing to make the next release a major one goob: I'm not aware of anything else which does so in its absence. jaywink: firefox is soon going over 30'th major release - let's not be too scared of "going too fast" :) fedgem would surely be a major too goob: ok then (i'm easily persuaded) :) flaburgan: goob, nothing unfortunately marekjm: I wouldn't naming the release major in the 'release.major.minor.hotfix' scheme marekjm: *wouldn't fear goob: four votes for major (0.3.0.0) - anyone else want to vote? marekjm: because it's not a first number - so it doesn't give the impression of "majorness" svbergerem: marekjm +1 jaywink: marekjm, yeah 99% of people will still think of it as minor jaywink: imagine firefox 0.3 svbergerem: from a users point of view I wouldn't call this major but 0.3.0.0 sounds good flaburgan: https://github.com/diaspora/diaspora/pull/4673 is a new mobile version menu flaburgan: this would be enough for a 0.3 too marekjm: so it's safe to assume that we agree that there should be a jump to 0.3.x line flaburgan: yep goob: yes to 0.3.0.0. svbergerem: yes flaburgan: okay, voted jaywink: so next: Issues on github -> Milestones (..sorry for rushing :D) flaburgan: which brings us to the next topic flaburgan: yeah, we need that : flaburgan: :p flaburgan: so my point is goob: Milestones, good idea to use these more, and set them in advance as things to aim for flaburgan: I think we should use more the "milestone feature" of github. Right now, we almost only use it when something is already merged. To decide during meetings what we want to see in the next meeting and put a milestone on it would allow to share this to potential contributors saying "this is the target". goob: and as a means of prioritising development tasks. goob: I recommend having a separate meeting after each release in which milestones for the next release can be chosen. jaywink: does anyone who does development work in a priority order or just what fancies them at the moment? goob: Or I suggest that, rather than recommend. MrZYX: so all of you have the impression that our work is just unfocused? that suddenly more will happen if you just say what needs to happen next? goob: MrZYX not that, but I think if the priorities are made more public (using Github milestones) more people will be aware of them goob: and can also perhaps prioritise some of the work they do. marekjm: MrZYX: is it irony? because I think it's justified. marekjm: the irony, I mean. MrZYX: I don't think that awareness will increase amount of work done either marekjm: +1 flaburgan: not by us, but maybe by new people flaburgan: bugmashs are nice MrZYX: bugmashs are sufficient MrZYX: we don't run out of them flaburgan: if we can point directly to "next" flaburgan: milestone flaburgan: I'm often lost in all the issue we have MrZYX: I don't think adding milestones will improve that jaywink: what about tags instead of milestones? MrZYX: what tags? jaywink: a bugmash is not a milestone. a milestone is a plan for a certain release flaburgan: MrZYX, I think jaywink means labels goob: I would hope that it might encourage at least some people to help MrZYX and other core developers with the key priorities jaywink: so not really agreeing we should use milestones for this jaywink: yeah labels MrZYX: flaburgan: sure, I mean what specific tags are missing goob: MrZYX, what do you suggest? Or are you happy with the situation as it is now? jaywink: good question :D flaburgan: MrZYX, well, we already discussed about that, maybe "high, medium and low" priorities flaburgan: my point is, some of the issues don't affect a lot of users goob: Perhaps a 'high priority' or 'key task' label? MrZYX: so if we already discussed that and it didn't happen... flaburgan: some of them are just suggestion flaburgan: and we're lost in all these issues goob: And if someone takes up one of them we'll try to help them as much as possible. MrZYX: point me to a single suggestion labled with "bug" instead of "feature" flaburgan: look at those issues https://wiki.diasporafoundation.org/Meetings/20140114#Milestones flaburgan: they have to be fixed asap goob: (obviously depends on having enough people available to help!) flaburgan: but I forgot them for this release MrZYX: I think that is the major misconception here, adding more project management techniques won't suddenly attract new people flaburgan: I agree jaywink: MrZYX, agree - we need more devs not management :) MrZYX: or make the involved people have more time flaburgan: I just think that, goob tried to keep track of dozens of issues on loomio to know what he can present on diaspora hq flaburgan: this should be done directly on github goob: I'm thinking to try to encourage people who do a bit of development here and there to tackle the issues which really need work flaburgan: a milestone is a way to say "this is the target" svbergerem: IMO we should go through some bugs before every meeting, discuss what needs to be done ASAP and put those in a diasporahq post goob: If a milestone says 'We want this done before the next release' it might encourage someone to take it on first. flaburgan: svbergerem, agree flaburgan: goob, I don't find where you listed all those issues flaburgan: it was on diaspora or on loomio? goob: I'd prefer not to get into discussion of individual bugs/issues in the meetings. svbergerem: goob: a milestone sounds like "this will be done until the next release" which is just wrong MrZYX: +1 MrZYX: additionally it sounds like "everything else won't be done" which is also wrong flaburgan: agree flaburgan: so we will not use milestone for that flaburgan: but don't you agree we should have an easy way to access to the issues which have to be fixed asap? jaywink: flaburgan, I think the only way would be to get someone to assign labels to them on github MrZYX: what about using the confirmed label? goob: So how best to make the prioritisation of tasks more public? Or are things best left as they are? flaburgan: the confirmed just means "I can reproduce" jaywink: something like "priority" would be more describing imho flaburgan: yeah I'm more in favour of something like that MrZYX: thing is, prioritizing a bug I can't reproduce won't make it fixed faster... flaburgan: MrZYX, that's a different point jaywink: well labels should not be abused, I think no one would mark issues priority unless they are confirmed :) have we been using the confirmed label before? only 8 issues are confirmed if so goob: If a bug can't be reproduced, it's unlikely to be a high priority! MrZYX: okay, I won't do the added maintenance work of deciding what to label as priority, if you find somebody to do it, fine with me, I can ignore that just fine flaburgan: I just want to be able to quickly sort issues that are affecting a really small number of users, issues that are an interesting suggestion but not urgent, and the issues like the 404 with opengraph which affect every users on almost every posts they do jaywink: do agree with flaburgan that there is no good way to find "urgent" issues from the labels flaburgan: maybe it's not that important flaburgan: I agree to do the "priority" labeling flaburgan: even every labelling btw svbergerem: "confirmed" sounds good to me flaburgan: unfortunately I need the merge rights to do that flaburgan: okay let's vote svbergerem: you know that those are bugs you can reproduce and we really want that someone fixes those jaywink: svbergerem, if we agree confirmed then cool flaburgan: we can use confirmed for that if we want, even if that's not the initial purpose flaburgan: okay let's vote flaburgan: do we agree to use a label to mark issues which should be solved in priority? goob: We can also publicise priority tasks via DHQ jaywink: not sure about "should be solved" part but agree to using a label ;) confirmed is fine jaywink: so +1 I guess svbergerem: "confirmed" is no priority IMHO. It just tells you that it definitely needs to be done marekjm: svbergerem: "it definitely needs to be done" which is priority ;-) goob: 'confirmed' is fine for bugs, but what about things that are not bugs? jaywink: vote vote vote - we can tune things later ;) goob: e.g. federation code, account migration, etc - which are priorities. goob: how to we make it clear to anyone who wants to join in that these are priorities above many other things? MrZYX: you don't join just to join jaywink: goob, well a feature would be confirmed at least if it has been decided upon - eg for example a vote on loomio or if it is clear it is needed by everyone and how to do it MrZYX: you join with your own purpose jaywink: like the bootstrap thingy MrZYX: once again, it's not about coordinating workforce, our issue is lack of workforce jaywink: people should above all work on what they want - not what we tell them to goob: the purpose might be liking the project and wanting to help improve it. jaywink: it's the important thing in open source flaburgan: okay so maybe we should have different approach flaburgan: we could use https://wiki.diasporafoundation.org/TODO-list to track the issues we'd like to solve in priority flaburgan: and link to this page with the diaspora HQ account flaburgan: what do you think? flaburgan: but that means maintain this page up to date jaywink: if github had better access management I would definitely vote github :) mode (+v goob) by MrZYX goob: (oops) - definitely, that's something i'd like to try to address separately. good to both try to encourage people to join in, and to have a list of tasks we really want people to work on. goob: or am I barking up the wrong tree? jaywink: the problem with syncing issues to different places is they go out of sync flaburgan: jaywink, agree jaywink: so the confirmed label sounds the best solution imho, though it requires the github team to maybe rethink some access rights - I think only a minor part of the currrent members actually use diaspora ;) MrZYX: I've seen projects doing separate repositories for issue tracking flaburgan: that's why I'm more in favour of github jaywink: MrZYX, well I meant in general that one tool for issues, etc .. now it is github MrZYX: (not sure I like that approach too much though) svbergerem: "confirmed" label for reproducable bugs and features that were decided on loomio? jaywink: +1 for that marekjm: yup, I think this is the way to go flaburgan: I'm still not convinced "confirmed" is the best word to use flaburgan: but I agree to do the label task goob: If everyone agrees that 'confirmed' = 'priority', it should be fine. goob: So I'll agree to that. goob: (Just realised we've been at this longer than an hour and we're only on item 2…) jaywink: yeah we should move on goob: OK, agree that issues with the confirmed label should be treated as priority? flaburgan: fine with e flaburgan: me goob: Fla and I can also start to ask for help with some of the non-bug priorities via DHQ. flaburgan: yep flaburgan: but nothing controversial here so no need to debate :p goob: Yep, debate on Loomio for anything major or controversial before 'confirmed' is set. goob: Everyone happy to move on to the next item? flaburgan: so next topic svbergerem: yep jaywink: plz :) flaburgan: svbergerem, clean up issues svbergerem: Clean up issues: just do it :-P goob: I think we're cleaning up old issues at a reasonable rate at the moment. goob: but can certainly publicise this task more to get more people involved flaburgan: I just did a post about that with my podmin account on diaspora-fr.org flaburgan: my pod is running the develop branch flaburgan: so the users can help to try to reproduce issues goob: as long as that won't lead to lots of people finding old issues of 'I want feature x!' and bumping them all. ;) flaburgan: :p jaywink: yeah - one thing to do via dhq account imho would be to get people to sign up to CodeTriage goob: So things OK as they are, we'll try to publicise this task a bit more? goob: jaywink, yes good idea. goob: So we're still using Code Triage, then? I had a feeling it had dropped out of use. jaywink: http://www.codetriage.com/diaspora/diaspora jaywink: 46 subscribers - we can get more goob: Is it still wanted as a tool? @MrZYX? jaywink: goob, it's not a tool for the project - anyone can use it without the project agreing :) MrZYX: ^ goob: OK. If it's useful to publicise Code Triage via DHQ I'm happy to do that. jaywink: it's just basically "mail me a daily issue from this project plz" jaywink: goob, that would be cool :) goob: Is there anything else about cleaning up issues we need to discuss? Or can we move on? flaburgan: okay, so goob and me are going to promote codetriage and say to users that me need people to try to reproduce bug svbergerem: we should also work on the feature requests: put some of those on loomio and vote jaywink: yeah definitely close or at least vote+close on some of the weirder ones.. ;) svbergerem: yep flaburgan: agree mode (+v goob) by MrZYX goob: Sorry MrZYX connection keeps dropping out. MrZYX: no worries, that's a script ;) goob: Oh good. goob: Re Loomio: use it if there's a debate about whether a feature would be desirable. goob: Not everything needs a vote. flaburgan: let's go directly to the hot topic of the week, cause it's already late flaburgan: Press stuff flaburgan: (it's not a good title) flaburgan: https://wiki.diasporafoundation.org/Meetings/20140114#Press_stuff MrZYX: I'd say lets ask him for a demo account with a running pod MrZYX: set a deadline of two weeks jaywink: MrZYX, good idea MrZYX: after that ask to remove our branding MrZYX: set a deadline of another week MrZYX: and if then still needed escalate to the FSSN jaywink: Awesome plan :) MrZYX: I don't think he'll succeed in providing that demo account goob: Sounds good. Can we insist on removal of branding? I.e is the name and logo trademarked? I forgot what happened with that. MrZYX: so we don't need to worry about his request MrZYX: goob: yes it is and my latest status is that the FSSN owns it now flaburgan: seems okay goob: OK thanks. It certainly sounds like a good plan. I'm happy with it. flaburgan: who is writing to him? svbergerem: Just in case he can provide a demo account: decide in the next meeting what to do? jaywink: I wouldn't request removal of branding IF he can provide the demo account jaywink: ye jaywink: svbergerem, +1 MrZYX: svbergerem: I'd say so MrZYX: jaywink: sure goob: We can ask for a prominent notice on that page saying 'Arvixe is in no way connected with or endorsed by Diaspora' or wording to that effect. MrZYX: I think people get that goob: But to start with, proceed with MrZYX's suggested plan. MrZYX: look at the wordpress hosters goob: Anyone want to volunteer to write to them? I'm happy to collaborate with wording. MrZYX: it's clear that they just run the software for you jaywink: so who will write? if no one else wants to take this task, I can goob: OK MrZYX, thanks. flaburgan: so goob or jaywink? marekjm: I can collaborate with @jaywink on the writing task (sounds like some school homework...) flaburgan: ^^ goob: If jaywink and marekjm are happy to work together, that sounds good to me. OK with you two? marekjm: fine with me. jaywink? flaburgan: you can post the message on loomio first flaburgan: we should probably open a loomio topic about the whole story anyway jaywink: do we really need to discuss an email sent out? :) goob: I think no need. We've agreed on what the message should contain. I'm happy to leave fine wording up to them. flaburgan: it's just to keep track jaywink: it doesnt' have to be long, just saying that they should be able to provide a running diaspora installation as a demo to us and confirm the minimum specs listed on the page to match that - if not, false promises should be removed? flaburgan: so, next topic, spammer accounts (it will bring us to the admin task) flaburgan: do we need something else than captcha? marekjm: jaywink: exactly that. goob: jaywink, I think first email can simply request demo pod, and then email to request removal of branding if demo pod not up within two weeks. goob: (I mean, email again after two weeks). svbergerem: agree, next topic? goob: Spammers: there's also the post reporter feature – https://github.com/diaspora/diaspora/pull/4517 – should also help svbergerem: goob: I agree goob: Won't stop them signing up, but may get them removed more quickly. jaywink: need to go guys - thanks for the meeting :) will catch up with logs tomorrow. see ya! goob: Thanks jaywink. Sleep well, mate. marekjm: bye jaywink. I'll PM you about the email to that company. svbergerem: I think captcha and post reporter feature should be fine flaburgan: we need to provide an easy way for podmins to delete users svbergerem: thats right flaburgan: report users is kind of useless with that flaburgan: without that sorry flaburgan: so this is the next topic flaburgan: and last one for today flaburgan: we need to simply podmins life flaburgan: the current admin panel is kind of useless flaburgan: https://wiki.diasporafoundation.org/Meetings/20140114#A_nice_admin_panel goob: I can agree to 'simplify podmins' lives' and 'improve admin panel' goob: but what can we usefully decide on here and now? flaburgan: that this is the priority for the next release? flaburgan: :p svbergerem: add feature requests on github? MrZYX: do you know the facepalm smiley? here it is for you: m( I won't repeat myself another time flaburgan: https://github.com/diaspora/diaspora/issues/4183 flaburgan: don't get it sorry MrZYX: things don't happen by saying they're needed flaburgan: yeah I know flaburgan: but that's not in my skills at the moment MrZYX: but that's not relevant svbergerem: what about the feature requests to keep track of that? goob: Fla, touché! marekjm: OK guys, I gotta go. If someone wants to keep pad updated - feel free to. I tried to protocol most of the decisions made so far on the meeting. svbergerem: (4183 seems to be just about the "clean ghost pods & users) MrZYX: I think we can wrap up, no? goob: We can all agree that it's important to improve the podmin experience, but I can't see what we can decide on other than that. flaburgan: svbergerem, yeah, I'll open a new issue flaburgan: goob, nothing flaburgan: I just wanted to point that the focus should be on that for the next release svbergerem: MrZYX: +1 goob: flaburgan, let's make one of the DHQ posts a request for help on these tasks. flaburgan: goob, okay goob: I'm happy to wrap up. Just been writing some minutes which I'll put on the wiki. flaburgan: everything is already summarized here https://flaburgan.framapad.org/4