17:32:27 #startmeeting Mindshare Committee Weekly Meeting 17:32:27 Meeting started Wed Apr 8 17:32:27 2020 UTC. 17:32:27 This meeting is logged and archived in a public location. 17:32:27 The chair is riecatnor. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:32:27 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:32:27 The meeting name has been set to 'mindshare_committee_weekly_meeting' 17:32:44 hellooo! how is everyone doing today? 17:34:16 Hello 17:34:18 .hello2 17:34:21 x3mboy: x3mboy 'Eduard Lucena' 17:34:23 Fine, I just think about the daylight savings, in Mexico already apply it 17:35:22 Here in Chile too. It was applied this saturday 17:35:40 Now I'm -4 UTC 17:35:51 should we set the meeting back an hour? 17:36:27 Well, I'm better with the current time 17:36:52 hhlp, o/ 17:37:01 for me it's fine 17:37:15 ok, also fine for me :) 17:37:34 * hhlp Sorry I'm late muy computer freeze I've just recovered... 17:37:35 :) 17:38:19 Hey 17:38:22 we have been asked to take a look and weigh in on change process 17:38:23 https://pagure.io/mindshare/issue/197 17:38:25 I'm late but around 17:38:33 hiya Sumantro :) 17:43:06 * riecatnor is reading 17:44:35 * x3mboy is reading too 17:48:29 my first thought is positive towards a community change process that is defined 17:51:48 I'm supportive of having a change process but we need to know what makes a change process template look like. Also maybe, when do we have that, like in engineering, the changes which are going in for Rawhide now , might be changeset for F33 and which means they have a scope to define what are the new things that goes in every release. Usually always should have a change owner and u 17:51:48 nless we sort out the teams and who represents them, it's hard to put a change owner name 17:52:28 I suggest we pour in our thoughts and discuss it on the ticket 17:53:22 Sumantro, what do you mean by "hat makes a change process template look like" can you clarify 17:53:27 what* 17:54:05 My main though is: What things should pass through this process? 17:54:09 I think we could run this independently of the release cycle, I see now benefit to doing it that way 17:54:17 no* 17:54:22 But overall I agreed the idea of having a defined process 17:54:36 We could just wave in the ML to discuss the details 17:54:48 https://fedoraproject.org/wiki/Releases/32/ChangeSet 17:55:19 Every changeset in the wiki 17:55:58 I think having this on the wiki is a good idea. I think the things we will want to capture will be similar, but different 17:56:02 so, we still want an owner 17:56:48 Has a bunch of placeholders, which need to have information like : owner, progress, contingency plan, benefit to fedora 17:56:49 and we want some way to track things 17:56:53 And stuff like that 17:57:15 yeah, sure, seems like something that needs to be defined. I am not concerned with the feasibility of making a template 17:57:30 I am more concerned with what we think the process would ideally be, and figure out how to implement 17:58:07 riecatnor: +1 17:58:12 Riecatnor +1 17:58:25 so I could throw out some questions we can all semi formally answer to see where we want to go 17:58:48 Do we agree that we want and need a community change process? 17:59:36 Yes riecatnor! 17:59:37 Actually, this might be better on the ticket as you mentioned. Can we all throw out questions 17:59:44 I will put them there 18:00:03 I think since we all seem to lean towards yes, we can use that as a basis and not go down the "no" route? 18:00:36 There are mindshare folks who are not here today either. 18:00:39 hmmm 18:00:48 I believe it is beneficial and we should make this happen :) 18:00:50 * riecatnor apologizes for rambling 18:01:01 +1 18:01:08 +1 too 18:02:01 I will write something, but I am a bit hesitant. I feel it would be mostly coming from me.. so I want to ask a couple more things 18:02:21 do we want to run the process as has been suggested? 18:03:38 +1 18:03:42 +1 18:03:54 Yes, please 18:04:01 Yes 18:04:17 ok, that is enough for me to frame the post accordingly :) 18:05:27 next I think we can discuss the advocate updates 18:05:50 unless someone has more to add to community change process topic :) 18:06:09 Omg, right 18:06:43 I don't have Any updates sorry 18:06:48 Busy week 18:07:38 absolutely, no worries! 18:07:48 :( 18:08:02 it's fine bt0 :) this is crazy times we are in 18:08:31 sanity and mental health over contributions right now, and always! 18:09:24 Maybe we could take a few moments to talk about the git forge situation 18:09:41 have people been reading the mailing list? I think it finally quieted down 18:09:42 ok 18:10:54 I did. :) 18:11:11 a lot of feelings there 18:11:18 Mostly the important parts multiple times 18:11:27 right, lol. 18:12:29 does anyone have thoughts? want to just complain or give commentary? 18:12:32 :) 18:14:10 I would say, feelings are real. Migration script will be needed and will the council give the team a migration plan ? 18:14:25 there is this here: https://pagure.io/Fedora-Council/tickets/issue/292 18:14:58 Woa, reading 18:15:19 i also opened this https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedoraproject.org/thread/2JXE3GOMER2VQLYDACG2YDE46YR5GB2O/ 18:16:25 So I guess, we can use this instance to think about what we would have wanted to see done.. we can learn from it to help shape the community change process 18:16:57 yes, feelings are real >.< 18:17:59 so, I wanted to point those two places out in case anybody here has some opinions and thoughts 18:18:31 would really love to broaden the conversation and see an overwhelming bunch of positive comments and ideas being brought forth 18:19:23 I am glad people have the outlet and space to really truly disagree, argue, vent their feelings.. I think we as individual Fedorans can influence the conversation to move in a positive direction 18:20:06 +1 for migration scripts 18:20:18 Might be a good idea to spread word on Telegram for folks, from https://t.me/fedoranews too 18:20:36 I don't know if this news has flowed too far across the non-software parts of the community just yet 18:20:39 ah, yes, to that too. I think setting that as a hard requirmenet is important 18:21:13 jwf, which thing exactly? :) 18:21:26 the two links? 18:21:51 It will be tough, but I am honestly a little excited about GitLab. From an issue management P.O.V., there are a lot of features and automation for things that is currently not possible in Pagure. Just keeping a living archive of past discussions and decisions in PAgure issues will be important 18:22:12 riecatnor: The announcement itself, that GitLab is the new home for most of Fedora development over Pagure 18:22:14 I love pagure; many contributors have worked in the codebase, and it's something than the feel of as the product of the community, but we also know how to move forward and be pragmatic, +1 for the migration script 18:22:19 s/is/will be/ 18:22:31 bt0++ 18:22:34 what do folks think about teams staying on pagure 18:22:41 Hi jwf 18:22:44 like, does mindshare want to stay or move? 18:23:03 I think to move 18:23:12 +1 to move 18:23:13 riecatnor: This is totally my P.O.V., but the worst case scenario is having Fedora folks split across two different platforms /o\ 18:23:20 lol 18:23:42 I can see your point jwf 18:23:42 It would be good for Mindshare to model a migration for the rest of the community too :) 18:24:41 I was already in a mindstate of "i dont think pagure is the best place to collaborate on a lot of the things the mindshare teams do" but that is totally my P.O.V. 18:24:58 Like, it kind of sucks for design 18:25:04 It took a while for me to come around to that, but me too 18:25:07 and I don't see gitlab as an improvement 18:25:32 My thought process says "why are we looking for a tool that works for every part of fedora" 18:25:44 it makes sense to me that different teams would use different tools 18:26:36 tho I understand this idea of wanting to keep things in one place. 18:27:06 I don't disagree with you :) Sorry if my comments from the peanut gallery took things a little off-direction from the ticket. 18:27:30 No worries, we are doing open floor and I am glad you spoke up 18:28:29 does anyone have a response to my perspective? 18:30:01 Yeah 18:30:15 Have much sense for me 18:31:16 But we need to continue the development pagure to support our current and future workflow 18:31:41 So, it's interesting, because maybe if the requirements we gave CPE had been curated using this perspective, we would be in a different plcae now 18:31:41 is the workflow formalized or written down ? 18:32:06 Not really, or maybe 18:32:31 I think no... 18:32:41 I am not making an argument for Mindshare, or any other team to stay with pagure... I guess I just want to float the idea that I don't see pagure OR gitlab being an optimal fit for some teams 18:32:55 I can handle this 18:33:17 And I agree riecatnor 18:33:29 riecatnor any tool is a good fit for every team 18:33:38 But we have tons of tools 18:33:42 x3mboy, what do you mean? 18:34:07 (also I realize we have been an hour, I am fine to finish this dicussion tho :) 18:34:16 In this case we need a ticketing tool or issue tool and pagure is really good at it 18:34:56 For code, the madurity of fedora makes pagure insufficient for some stuff, and gitlab is really good at it 18:34:58 Yeah and it's integrated magically with antora and docs platform 18:35:09 Like CD/CI integrations 18:35:46 So, maybe 'move' to gitlab is not the best for the whole project 18:36:01 But it's totally right for code related teams 18:36:14 I think pagure has a CI integration 18:36:28 https://docs.pagure.org/pagure/usage/pagure_ci.html 18:36:59 For us, as mindshare is not the best move. I never tried gitlab for following issues, but pagure have done a hell of a job IMO 18:37:20 and usually, the problem with CI is not on the forge side, cause that part is kinda "easy" (do a web request to trigger, receive the result from web, and bam, that's the basisc) 18:37:54 the problem is all stuff outside the forge (aka, dealing with jenkins, etc, do it in a way that do not make the cost skyrocket, etc) 18:38:22 x3mboy, I totally see the reasons why we might want to make the move for technical reasons 18:38:40 I think jwf made a good point tho, we might want to move as a team to show solidarity 18:38:48 misc, the technical part will be OK, we have a lot of great people that can deal with it 18:38:59 or, we could say nah, we want to do it an entirely new way 18:39:35 I can say, let's move 18:39:47 We move from tracker to pagure and we didn't die 18:39:47 for me, the future is still open, and I would encourage people to think with a growth mindset.. and maybe weigh in on those two links I sent 18:40:14 lol, true that x3mboy ! 18:40:26 it did seem pretty painful at times tho :P 18:40:50 ok 18:40:56 anyways, thanks for all who weighed in on the discussion today. Hope you all have a great day! 18:40:58 Personally, there are a lot of things that GitLab offers from a ticket/issue triage P.O.V. that outdoes Pagure, just because I can automate more things than Pagure allows me to. I love Pagure as full FOSS, but it keeps me doing a lot of manual work that other platforms have automation for. 18:41:42 I think as a ticketing tool, GitLab is a better platform than Pagure, but that's only if you understand and know the tool. I spend all my working days in git forges, soooo obviously I am biased :P 18:41:43 jwf, I am curious about the functions. Tbh, I have never used gitlab. Maybe it's time to see what it's all about :) 18:42:10 #endmeeting