14:01:52 #startmeeting 14:01:52 Meeting started Thu Sep 30 14:01:52 2021 UTC. The chair is jeremiah. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:52 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:02:09 That's better. 14:02:18 #info Continue to use meetbot in IRC meetings 14:02:45 So, we'll move on from the "Greetings" section, which I think we've successfully completed. ;) 14:03:34 The next item is from Adrian; "When a package already has notes in dla-needed, please read them before taking the package." 14:03:48 It has happened more than once that I had written something in the notes in dla-needed, but later someone did something that did not make sense due to not readng the notes. 14:03:55 Last week I asked something a question, that was already answered in the notes for that package. 14:04:34 Last week I asked someone a question, that was already answered in the notes for that package which I didn't read properly. 14:04:52 hola (sorry for being late) 14:05:00 hola el_cubano 14:05:01 Just a reminder to everyone that we should read what others have written there. 14:05:25 Hello everybody! 14:05:38 We're just getting started with Adrian's important reminder about reading the notes _before_ taking a package as it will save time and confusion. 14:05:59 Hello gladk! 14:06:14 bunk: how come you didn't read what was there? I mean is it like a tool or process shortcoming, or just plain inattention? 14:06:32 plain inattention 14:06:46 Is there a way to make the notes more prominent? 14:07:20 When taking a package you edit the line above the notes. 14:08:14 I just checked and the NOTES are shown by ./find-work so that there's nothing to improve there either. 14:09:01 I think we can move to the next point then. 14:09:06 Right. 14:09:34 The next point is about suggestions for improving time reporting 14:09:37 Let's give everyone 2 minutes to read what is under "Should reporting deadline and hour dispatch be changed?" at https://pad.riseup.net/p/lts-meeting-agenda 14:09:42 #topic Should reporting deadline and hour dispatch be changed? 14:10:08 jeremiah: try to post those "topic" lines when we switch from one item to the next 14:10:17 Will do 14:10:34 o/ 14:11:12 h01ger: We're talking about "Should reporting deadline and hour dispatch be changed?" 14:11:19 hi 14:11:38 https://pad.riseup.net/p/lts-meeting-agenda contains my thoughts 14:11:39 More info on the topic in the backlog. 14:12:00 petn-randall, h01ger hello! 14:13:15 I would split "reporting worked hours" and "report". It could be too hard to be on schedule. 14:14:14 I think not getting hours the following month is a bit too punitive. 14:14:14 so everybody who is not able to give in the report within two days will be punished by not getting new hours? I would prefer to not change this and have one week for it .. 14:14:36 The proposal seems reasonable for me. I agree with Anton that we can ask for early reporting of hours and leave a few more days for the public report. 14:15:07 * el_cubano agrees w/ buxy 14:15:46 * h01ger too 14:15:54 Sounds reasonable to me to add reports to ledger later, my main thought was about getting the carried over hours known before dispatch. 14:16:04 buxy: but reporting hours is the same as giving back hours, isn't it? 14:16:09 Requiring the full public report on the first of the month could be asking a bit much, but we should be tracking our hours along the way so that a simple entry in the ledger with the hours on the first of the month should be easy 14:16:12 I agree as well, the proposal seems reasonable. But I do think it feels a little hard regarding the following months reduction of hours. Human factors are always a difficult aspect to modify. 14:16:34 ta: does separating the delay for the public report from the delay of documenting your work hours in the ledger answers your question ? 14:17:13 the idea is that in the first 2 days you have to say how many hours you have worked last month, and you can add the link to the public report later (before the 10th as we do currently) 14:17:36 buxy: but the default now is that you worked all assigned hours in that month 14:18:09 yes and bunk's idea is to change that 14:18:10 buxy: only if you didn't do all hours, you need to give back them 14:20:12 So, then part of the intent would be that on the first of the month we report hours worked *and* give back any surplus hours? 14:20:23 I have no strong feelings one way or another, whatever method causes the least headache for everyone involved works for me. 14:20:36 Then does the hours dispatch algorithm change so that if you have (hours > 0) when the dispatch is run you are not assigned new hours for the month? 14:21:11 el_cubano: The point of the second item under benefits is that if you have requested 20 hours and carried over 5 hours, you will get 15 additional hours. 14:21:15 AIUI, the intent is to change the logic so that the allocation brings you back to your max. You don't have to give back hours. The allocation does it implicitly for you. 14:21:45 Oh, I get it now. 14:22:12 This would simplify the generation of reports. 14:22:14 Because we didn't have that before, we had to go with the current approach where the dispatch does not allocate to you more than max*2. 14:22:39 Yes. 14:23:07 I like the more precise dispatch. 14:24:09 There seems to be consensus _in favor_ of Adrian's proposals. 14:24:48 ok 14:24:50 * petn-randall thumbs up. 14:24:52 If there are any questions or comments or hesitation to implementing them, we've still time to discuss. 14:25:11 I suggest to share this proposal by email and offer others an opportunity to comment explaining that there seems to be rough consensus towards this proposal. 14:25:43 I second that suggestion and will take on the task of getting the email sent. 14:26:08 * bunk will modify the test in the pad with the suggestion from Anton regarding sending reports later 14:26:21 #action jeremiah to share Adrian's proposal for hours dispatch on deblts-team@freexian 14:26:28 #action Jeremiah to send email regarding 14:26:36 Oops, doubled the action 14:26:40 heh 14:26:43 Please disregard. 14:26:45 #undo should remove that 14:26:53 whoever the chair is 14:26:53 Ah, sweet 14:27:07 \o/ 14:27:11 #undo Jeremiah to send email regarding 14:27:11 Removing item from minutes: 14:27:41 #topic Publicity, micronews, or something similar to raise awareness of project funding? 14:27:53 Let's move on to the next topic shall we? 14:28:23 This is a timely topic given that we have a accepted project that is in the "request for bids" stage. 14:28:49 We want to get quality bids of course but we don't want to spam lists and other fora. 14:28:59 It looks like we had one project proposed for funding, which seems to have resulted from the DebConf BoF. Do we want to be a bit more proactive in publicizing the initiative through some of the Debian channels? 14:29:15 el_cubano: I think so, yes. 14:29:30 I've spoken a bit with the proposer of the project. 14:30:04 We have a tentative list of places to publish; debian-lts, Debian publicity co-ordination, debian-java and debian-android-tools 14:30:27 I initially suggested going through the publicity team and perhaps some of the news channels (versus list/forum spamming) since we are likely to reach a larger audience of potential proposers that way and not get lost in the noise of forums/lists 14:30:39 debian-project would aslo get a wider attention 14:31:21 el_cubano: I've lurked in debian-publicity and spoken to folks about the process, so this is definitely on the radar. 14:31:29 el_cubano: Are you speaking about the timing? 14:31:43 If we are looking for people to work on Debian projects, we might want to send bids to debian-consultants@lists.debian.org maybe. 14:31:49 Do you mean we ought to do a Debian publicity push before sending RfB to mailing lists? 14:32:01 https://lists.debian.org/debian-consultants/ 14:32:15 I think debian-project and debian-consultants make a lot of sense. 14:32:36 jeremiah: Not directly, but timing is a factor. I think a news/publicity item comes first, then list-specific messages can be published and referencing the news item 14:32:48 Okay. 14:33:07 FWIW I'm not sure that I would send a request for bids on debian-project. 14:33:25 But speaking of the project in general, yes. 14:33:45 Good point. That seems more likely to trigger a non-productive discussion than it is to attract useful proposals. 14:33:46 I'll propose an item for DPN that we can generate a micro-news post from. 14:34:03 I'll send it to debian-lts for review first. 14:34:03 jeremiah: Is it OK if I make a first attempt/draft and have you review? 14:34:09 el_cubano: Absolutely. 14:35:05 #action el_cubano to draft Debian Publicity news item regarding funding of gradle project. 14:36:03 Also, when we publish, we'll bear in mind that any RfB ought not to go to debian-project. 14:36:53 Currently the list of mailing lists for a RfB is debian-consultants, debian-lts, debian-java and debian-android-tools. 14:37:12 Looks like we have consensus and next steps on this topic. 14:37:20 * el_cubano concurs 14:37:25 If we don't have more to discuss I'll move on to the next topic. 14:37:46 #topic Any other business 14:38:07 Are there other items not on the agenda that we'd like to discuss? 14:38:50 jeremiah: Something you and I briefly discussed a few days ago in this channel, is there a need for some sort of automation to validate that hours give-back entries in the ledger? In particular, to make sure that hours are given back into the pool from which dispatch will be made, rather than into the preceding or current month. 14:39:18 I think there may be a need, yes. 14:39:32 We ought to take into account the changes that Adrian proposed. 14:39:51 Especially as it may have an impact on the give-back entries. 14:40:07 Yes, that discussion is what reminded me of this other item. As I mentioned previously, I think have mental model for the logic that needs to be implemented. I can come up with a first attempt next week. 14:40:13 If you would like, that is. 14:40:18 The impact is that you would no longer do give-back except if you really stop LTS/ELTS work altogether. 14:40:26 That would be much appreciated el_cubano 14:40:51 buxy: Of course. I overlooked that particular point. 14:41:25 That said, a script that validates that there are no "dangling" give-backs in the prior months would be a good thing to run alongside (or before) the dispatch 14:41:30 el_cubano: but I'm sure that jeremiah would love your help to further automate the monthly report anyway 14:41:42 Yes, agreed! 14:41:59 jeremiah: Feel free to give me the action on this as well 14:42:07 and possibly do such checks, ensuring that the balance of previous month is really at 0 14:42:33 #action el_cubano review automation and tooling around monthly report generation 14:43:26 I had an initial simple prototype that began to separate presentation from logic and if we could continue in that direction I think it might help. 14:43:57 Any further topics to discuss? 14:44:30 There are recent updates to the ledger in the last 24 hours and I've generated another report for August 14:44:42 That is scheduled to be sent to buxy immediately after this meeting. 14:45:00 To be clear, the change to the report, give-back, and dispatch hours would not start tomorrow, but for November (or perhaps later). 14:45:04 Is that right? 14:45:20 By that I mean, the requirement to report hours in the ledger on the first. 14:45:26 Yes. 14:45:34 I don't think that we pointed to a date 14:45:56 But I'd like to begin delivering the report sooner. 14:46:09 So I think it may be worth it for me to follow Adrian's proposal now. 14:46:22 But assuming that we don't have strong objections from others, we will likely start with it in November, yes. 14:46:22 As we gather info for September. 14:47:26 #info Plan is to adhere to new reporting deadlines more strictly in November. 14:47:42 Any other business we ought to address? 14:48:26 If there is nothing else, I propose to end the meeting. 14:48:35 Nothing urgent on my side. 14:49:07 In that case, I'll say thank you to everyone and end the meeting. 14:49:11 #endmeeting