Alright, so it's let's get started. So I don't know if maybe you want to share your screen because I think mine as usual is just not working
yeah sure. Should I yeah, if you prefer their
sound the ball because I don't know if you're on the chat so that everyone can keep them on so besides the usual version that that we have in the wiki The only days I have actually moved like most of the agenda items to individual tickets, because I tend to be like ongoing issues in a lot of cases that that popped over from one meetings to the next. issues will be a bit easier to keep track of. And we know we'll have a board also to go through that. So we can load that in share screen can go about this.
All right. Perfect. Thank you. So it's a little small, but maybe we can start with the ones in progress because those were properly views meetings. So the one was, is an ongoing task count from anywhere engineering, but I think time because he you, you're taking over from my earliest work on this great thing about like
ways to do the court report like the one that you did today.
Yes. So Ellie is actually so we've decided that I'll be taking over this and he's just working on this. So there's no context switching so just don't jump in. While she knows everything. But she has just let me know, in terms of feedback today, that she's busy putting together a survey to see now to the core contributors just to get through the feedback on everything. So I know. I don't know if that document was shared. I know you and her had some back and forth. I don't know she said that. That hadn't been shared with the larger core contributors. The
document has been shared. It's in the forums, but I don't think we had a lot of additional commands on top of it.
Okay, the key takeaways and possible solutions document. Yes. So we've been busy doing a she's busy doing a survey on that and then as soon as art will be more we can hopefully Yeah, but there was my first spring chicken today twin pretty smoothly but I yeah, I think the document the working group document Yeah.
All right. I mean, is there anything blocking you? Or any questions that that?
No, no, at the moment is just about getting out. Just get find the time to finish the survey. And then as soon as you send it out, we'll just keep tabs on how many people stopped responding and we might have to just push that a bit so we can get through this Foster. And so we can Yeah, so we can actually get somewhere. So I'll let you guys know probably in the next two weeks, hopefully, we'll have some more feedback. Hopefully the surveys sent up at that stage and then we'll take it from there. But I'll keep you guys posted.
If anyone's comments are stuff that have been overlooked and etc on top acetate for improve a bit because the some of the coordination work that we do here but also like passing on information between between everyone with a laptop or collaborating a bit more. Absolutely.
I mean, all right. Yeah. This there's barely anyone built in the form the chicken this mat this past month, so if possible, and so I think this will really help.
Yes, definitely. I mean, I'm sure best prints by Christmas was like, the lowest points we could have. But yeah, it's true that there have been a downward trend over the past few months. Good to see that. All right. Next item, I guess. So that is an no bind up on the MFPs. So this one is something on which and hopefully you've given updates in the past. I don't know if that's still gone on because I haven't followed since the last update on The MFE documentation then I'm
not sure I have an update. I do know that. There is going to be a meeting on Thursday to decide on Redwood so that we solve some of the problems that have been reported regarding the introduction of new MSPs in the past, right. The idea is to this has been led by by Jana and the product working by the way. And, you know to make it clear what's going to be in read more than what's not that's the main
main goal.
And then to figure out how to get there and make sure all the features are ready in time and tested and documented. And everything right. So it's, I guess it's tangential to this. Like it's part of the efforts to improve MFP documentation
so Oh, yeah, that's that's actually an action item in the ticket so yeah, that's actually happened.
Yep, that's that's perfect. Yeah. Also talk to these on the last product working groups does look at that's where other things are going to go unless he's having like a bit of follow up on the product side and maybe some coordination around that thing. That's probably seen an open question as how the technical coordination will happen. Because guessing will be the purview of the product working group with at least having any coordination at all, I think will be a big
step. Yeah, this this first meeting is very, very open. It's I shouted it out, and the BTR and the frontend Working Group channels. So anybody that's interested, can and should join, but I did invite some people specifically so that you know, particularly the BTR leads and leaders and people that are involved, but anybody that's interested in this topic, can join that.
Yeah, I was gonna say, there are always technical details that the engineers are going to be best placed to prioritize and understand how they should get done and why they should get done. But I think that the one of the purposes of this
kind of cement, the product lead organization that we want to have, and it's based to an extent on feedback that we've gotten from BTR about, hey, we pulled in this MFE because somebody wanted it, right. That's not enough product management discipline to run the project successfully. So we want to do is, get those conversations as early as possible in the release cycle. Inform the conversations based on like all of the product management research that we do. In advance. And ideally, like when we have engineering lead, changes that are making it into the releases that they would actually be reflected in the same release plan as the product lead changes so that we would have one place where we could see everything that we aspire to have in the next room will.
Be better and will be a good iteration in case. So I think that takes care of most of the action items in there. Maybe one which is slightly tangential is that you had one about three repository in the GitHub organization that started with the prompt and I don't think you got the chance to go what those were
think I think total appears to have been one of them still a bit stuck, and I should go
if you learn something, yeah. The form for the next one is
max ticket after that will be the debugging system. Three issues. So there there was some follow up in the thread itself from thread in the meantime, at your live there, Peter replied is not here today right now, but he did mention that like, potential cause I think in the problems right, I didn't look in the tender but especially in a pull request that he thinks needs to fit back. There review chats Anyone is able to review this
puts it in the chat. So I don't know if anyone knows a bit more about this issue and is about to talk about it because certainly not the fine details there.
No, nobody knows. Anyone can give a review to Peter maybe
not something I can review but I can ask. See if Dave Ormsbee or Kyle are able to spare some cycles to review it. I think they'd probably be placed
right, next step for this one. Then there was the translation issue that originally Yeah, report that's an extreme from from to trans effects. So there was a bit of back and forth Yeah, unfortunately is leaving the community so I wouldn't really keep following up on that. bombardment, John, that for him, it's fixed. Or at least he doesn't know of any new issue with that, but I still have some outstanding questions for him. Again, I don't really know that issues. We can only ask questions, but I remember that and mentioned that there was a permission thing going on with crumbs effects, like not all translator and access to the new content. And I'm not completely sure if already like everyone has everything to do their work and it's just a matter of waiting for translations to be done. Or if there are still technical blockers. But Omar is not here. And and we don't know Does anyone know anything about this? This is
something I work on, somewhat indirectly with Omar. So I could say I'm going to ask Brian and then it's the last comer. So Omar is really the right person to ask here. But I can I can insist on Slack. The bears, are there any issues there? I'm not aware of any issues as far as I'm concerned. So when's printed up communications is translated and translatable using Apalis and it works. But yeah, I I didn't try translating it myself. I'm gonna
alright. Yeah, because sometimes that can be also the diff between like it works technically. But for our users, our translators, or whatever that is. So that I think the best would probably be having the last word from the translation working group. I think, right. Yeah, it's it. Eden Steele was leaving the translation working group.
I think so.
Yeah, I think this was like picking it to eat and it would be the right next step and there's some technical details we know we need then Brian Smith would be the right person.
Since the translation working group should have involved in the next releases inviting her to the meeting on Thursday. Could it be a good idea for her like to be aware of, of the scope right or but the thing
for sure, because especially now that we won't have around to keep an eye on translations, I think having some one more, that might help Yeah, okay.
It's always good to hear today, so, so I will just put that as a as a next step. Good.
All right. So then there was Lana for Project UX meeting, but I think that has been mostly so maybe I should ask Andy, that's that's the case. But I think the plan is for your ex to join the the project. Working Group meeting at least the UX one and having going on walking, training that from time to time, but I'll take an action item to to double check with Allium this. Lets you know Casey and online if you
haven't discussed that, but I am having a meeting with her tomorrow. So I can I was gonna say I can follow up with her if you want.
Definitely.
We'll just make up put some comments in this. In get in Yeah. In the comment section.
Sounds good. Hope. All right. So then I think before getting to the less important one, urgent one from the in progress, we could go through the new topic. Because there are a few of them that have waited for a few meetings, we didn't really get a chance to go see them. So if we look at the first one of the upcoming meeting agenda column so that's just basically a recap that I've moved stuff over from the wiki. I've also closed a bunch of issues on the on the on the board on the working group coordination project. So if you saw anything that seemed to have been closed a bit too quickly, didn't get the right update. Don't hesitate, because there were a bunch of issues and I think I closed on me the ones that don't need to be worked on anymore, but let me know my bounds there. And in general, that means that now if you want to add a meeting to this, an agenda item to this meeting you can of course still use the wiki page, that's fine. But you can also actually open a ticket on this project on this column. That will be exactly what we'll be looking towards all right. So go on this issue. Yeah, there is the something that we've discussed some time ago, which is to try to call contributors to take on more responsibilities, whether it's additional permission, right, some different repositories to be able to review merge things, but also maintainer ship. So that has been like a round of additional maintainers for the current phase of maintenance and working maybe you want to talk a bit about that. But yeah, like might like we also had talked about very simple action items like posting, promise read, posting under meaning needs to be the core contributors to ask people to take over, maybe, in general, I might be good to have a look at people who haven't found work to do recently, but work or contributors to maybe suggest some so I don't know if anyone would like to help a bit with that. I could take an action item to goes to one of the threads and forums and on the mailing list. If anyone wants to help those.
No, all right. I guess I'll start with that first and we'll see what comes out of it. I mean, in general, what could be good would be for each organization to try to have a look if there are other I don't know maintenance ships or repositories on which it would be good to have more rights and maybe try to extend that because what's also behind that is also things like review of pull requests and being able to accelerate the upstream reviews of our environment, or parts of the codebase that are actively maintained. So that's quite probably to them.
I can I can, I can join you, they can join you for for this fun, but I would like to be in another meeting or in Slack but I could. I would like to start from like from the need, like what are the rebels that are currently not assigned to any contributors or, or
the one working group is that finials working on producing that list of repos now, so it sounds like that. The need is we should work with Neil to get the description of the need for a describe it because I think that's the place to start right. Relatedly Zabi I was going to ask like, how is how is litho flow going to be like we have a sense of on average how much time core contributors are spending on average, like how many what percentage of core contributors are meeting their their obligations versus not to have that sense?
Well, like I said, lately, it has decreased a bit over the past few months. So so if we take maybe before like just the December one which was particularly low during the holidays, I think we add about see, like, correct me if I'm wrong, but about half of content. creators are replying and doing any hours basically. So it's possible that there are some people who did not reply and actually did ours too. But most likely, most of the areas should be the ones with the reporting. And if I remember correctly, it's about 300 hours or something like that, every couple of weeks every sprint so, so you can find some of the stats actually in the last ones so I think more or less like, like the vast majority of contributors don't do all of the house thing. There is also good proportions of people who do a significant amount but yeah, I would say probably, if I had to do just a blind guess right now, that would be worth like, looking into numbers a bit more, but probably a third of our contributors would actually if not fulfill all the house do that work and maybe like half of them as is kind of something like that. But, but again, it's it's something that we can look at a bit more closely. I know that we have done a round of discussions with contributors around this a year and a half ago or something like that, and led to a few more recently. So there are also some stuff that can be read about that. In the report that she posted. But I think in general we have a lot of activity between what people organization committed and what what is being done. There's a bit of a gap. And I think I mean the fact that few people do a lot of the work and that a lot of people don't necessarily do their commitment is not something that's specific to openedx I think this happens in every open source project. Like it's always a bit like that. I think the important bit I think for me is to kind of just I acknowledge and recognize that like maybe like keep the status quo people who are inactive maybe maybe something that we had discussed at some point was to have another intermediate statues for people who contribute but maybe not as much as a co contributor to a more like a contributor label for that, and also maybe you also have some people get time at one point but less later on so we could have like a kind of an inactive status like Alumini alumni contributor and then if they want to reactivate the activate so rather than necessarily like weeping. We want to this to make sure that the work is done because it's volunteer work. So we don't really have a lot of low rate would be more to like maybe clarify who is reactive with not active so that typically when you have this kind of question that it's it's more clearly currently look, the number of contributor would be the ones who are actually active as just having a bit of them expect something. So again, I see that, yeah,
I want to talk about that gap or lack of whatever. So the question is, is it the lack of what is it a self reported activity, which is like, not enough? To be a contributor or it's a result, which like, we don't see a result of that. We don't know how many hours is spent. So how do you measure that contributor is actually doing something?
It's always a really difficult question. Right? Right. Understand? Yeah. Yeah, we basically basically on on, like voluntary reporting, because it's, that's, I mean, maybe there are other better solutions, and it's quite possible, but it's quite difficult. I find in general to really track everything that everyone is doing, because there are so many different types of contributions, so many different types of skills, technical or not, and etc. So, yeah, currently, it's like basically we ask the people like how much time do you spend doing contribute to a worker about the mounts and we take that at face value. So people could even lie, but I don't think generally people do for that. And it's true that one out of one person is not going to bring the same result than one out of another person, but they will have both spent an hour trying to do something. So it's, that's kind of like the base denominator that I see. But, but what do you have in mind? Do you think we're missing some of the work like that probably.
What I have in mind I don't really like to have something definite in mind, but a rough rough question or maybe a rough idea is like, how the whole work is whatever scheduled manage it, whatever is it like some kind of sprints where contributors are committing to something that in a week or in a month, people can bring that knowing that we will be spending that much of time we are committed to to contribute or something like that. And with this maybe this volunteering, contributing a is very much similar to what we have in rock again, called like strategic work, and it's always deprioritized against some firefighting or whatever. So maybe we just well it's not just but maybe if you need to build up some sort of a cadence where people are actually working and knows that they have to bring something and so on and this will maybe contribute to the fact that they not did prioritizing those hours against something else. Sounds great.
Yeah, I was gonna kind of extend on what Sergey was saying a little bit. I think they agree with him. I mean, I think that they answer has been in large part that core contributors like No 10% of your time, figure it out. I think we have an opportunity in the case of maintainership we have a predefined set of expectations. We could potentially come up with like, let's say we have a rubric of repos that need maintainers and complexity and we say a complexity three repo requires like two hours a week of work. Something like that. Then we could say, you know, if you're doing a complexity three repo then you're you're covered in terms of like your responsibility and if you improve the state of the art, you can do that in less time then so much the better, but we just give people clarity and more measurability in terms of what they're doing. And also we make sure that you know, people have an opportunity to focus on something that everybody benefits from like maintaining the request.
I mean, why not? Around the Sprint's and having people commit to that, like if you have a specific recommendation as to how to put it in place, I would be really happy because that's, that's kind of the origin of thoughts for how to deal with our contributor. It's still sprints that we that we have currently at the canons of two weeks, but in matter of fact, it tends to be more of a way to like know when to basically do reports and retros and etc. and meetings rather than people really committing to any specific amount of work like we tried that originally, but like, it seems like currently, we don't plan the work a lot at least in terms of community contributions and etc. So there might be some stuff that are more recurring like what you mentioned, add like you're on, maintained on a report that that we'll be picking up on the work, maybe stuff like, moderating the prompts or stuff like that. Also a bit like that. But in general, I don't I don't think many people do plan their sprints. So I will be curious, like, again, we are right in the middle of trying to think of better ways to organize all of that. So it could be good occasion to rethink that. One thing that I've seen working a bit on the domain is like having a bit of like a mix between a sprint and more of a hackathon that the GitLab community is doing where they do. Like I think every month or every couple of months there the tag issues that are that can be taken basically by the community at large public AkhaTEN. Then over a week, you kind of select which issues you would be interested in that each issue or commitment etc gives you a certain amount of points. So that could be compared to maybe a bit what you what you mentioned in terms of complexity or something. And then basically you have the rest of the months to complete it to manage it. And etc. And if you manage it, like the sum of all the things, the tasks that you committed for at the beginning of the month, if they are completed at the end of the month, automatically, that gives you a certain amount of points. So that could be maybe a way to go at that which is based a bit less on just reporting and number of hours why we could still do that but but also more precisely on on commitment and maybe maybe that's that's something to try
what would be the next step for that?
That's I think we will add it to the agenda for the kind of kickoff maintenance and upgrade Working Group. Like figuring out how like, could we make this an easy option for core contributors to get their hours so I think that would be probably the next step. Let me follow up with Finn, about when he and Jeremy are planning to do that. I'd like to get it on the calendar sooner than later.
Yep, that sounds good. We can bring it up in the context. And I guess, depending on what we think could work we can maybe try to like bring it up on the forum and next etc to to have like more people also actually saying that but sounds good. So for the like to put that on the agenda who takes that? That you want to suggest it and Yep. All right. Sounds good.
Should we also create I mean, since since it seems that this specific to do is is related to to just advertising contributors to take them on permission, rights and responsibilities for the maintainer ship program to be greater a new to do for discussing how these Sprint's would would, would work in reality
you Yes, but it might make sense to have that in two different things to not our church that ticket to match. So firstly, you're right, probably both you and I need to just like post something based on whatever finagle come up with so that that will be like advertising for maintenance stuff, but maybe for the general of how we commit and run sprints that could go into the other ticket that we talked about before. Based on the feedback and interviews for money and extra
and sorry, I missed something you were talking about Jim O'Neill getting together to push forward on maintenance was that a specific thing happening and
yet it's two of them are supposed to be the planning a kickoff for maintenance and upgrade Working Group been? I'm going to forcefully ask for a date. Under separate cover because it's been pushed out.
You have some leverage over some of them.
So do I understand correctly that this is an older action item maybe coming from the
working group or something Oh, yeah, I would say it's you know, from coming in the maintenance group. We didn't really have enough dedicated kind of ongoing capacity keeping like the work on the rails and like figuring out what the right next steps were. And, and also there was like a bunch of work that too you were doing via Jeremy's teams that was like on a separate board, but related to the maintenance stuff like so maintenance, there's ongoing maintenance call it simple upgrades, security patches, chloric refactoring views, then there's the upgrade side of things, which is Django core dot two, new version of node, etc, etc. related work. They're both important for the platform help. So like Jeremy has been leading one you know, leading magnets little bit so bring them together have one working group, a new one. Under which umbrella I don't know but that is focused on these two tasks and making the making it possible to distribute that work more broadly, and also ensure that we have the right kind of project management delivery discipline around that work, so it's actually getting done.
Alright, so let's get on with that. Next time. Yeah, synchronous, asynchronous tools. That's an old topic, but I wanted to renew it a bit because I've certainly not just that a lot of the content and discussions and etc. tend to happen
often on synchronous setting, so I know that even though I'm probably not the most remote from the community, there are regularly things that I miss just because they are discussed in some obscure slack room and even though I still follow the forum and what like many means, then whenever I regularly missed those and so yeah, I wanted to bring that up that are maybe making a bit of a conscious effort to embrace like asynchronous workflows. I mean, this goes as far as the meetings that we have, but I think on the meetings we have started doing some movement at least for example, if you have the working group, I've started doing more async updates, moving stuff to discussions or exit transfer that seems to be going in the right direction as a community, but it feels like maybe the next table time maybe to take into account now is also thinking about being mindful at least of how we use synchronous tools like Slack, which is immediately we get an answer. So that's great. But also it means that it's not as archived it's not as public model people might miss it now says something like, I don't know the forum, for example, where yes, currently we have less discussion there and sometimes less attention to discussion there. But it's also because I think there is a chicken and egg with this, where the important discussion happened. On slack so people tend to go there and then we end up with a situation where the really core of the community the ones who are able to be on top of those Slack channel the whole time will be extremely well informed and have answers pretty quickly. But we also have a larger part of the community that is more disconnected, especially the ones on different time zones.
We don't
spend that much time on Slack. So yeah, we haven't really talked about that, um, those times before, so I wanted to have a bit of a discussion about that and seeing what what do you guys think about that?
As I mentioned something, I'm sure. Just from a product perspective, and a UX and UI perspective, I do find that I tend to miss when people ask for reviews because they often get asked on Slack. So if I'm not in the loop of my slack, is Yeah, if I don't sometimes I mute the channels just to so I get into the flow of work. And I don't see those immediate I don't see those comments. I don't know if there's a way that the reviews can be rather asked through the you're making more on the wiki. When someone puts something up on the wiki and ask for review from a product perspective. The product team is asked mentioned there rather than in Slack I'm not sure what the base would be. But I just think it is easy to miss that just from a review perspective.
It makes sense to me. I mean, I think people depend on a few being specific people, unless their teams already on the wiki that you can that you can pick. Exactly. I haven't. I've only been interviewing people there because when people are on already like following a specific page, they will get notified or additional comments. From might be good for that. I mean, I know that I sound like an old father who is talking about the farm but that's kind of normally how, how those things have been resolved. Like it's such an easy way to touch a lot of people and you know, fundamentally asynchronous way. So
and that will be cool if it could be you mentioned teams if somehow the product or the UX UI team is all notified of these reviews. I don't know it just so because sometimes also on the forum you you don't you're not scarring everything immediately. Just sort of some sort of some sort of ping that okay, there's a new review that is up for maybe then it's your expertise and it's up for grabs. I don't know. I'm just some sort of reminder that because sometimes you get so into your flow, and you're working on so many different things that you don't you kind of don't go and scour the forums or scour slack and like okay, there's something new that I can work on, or there's something new I can contribute to in the coming months or coming weeks. So it's like almost like a little just thinking thing, reminder, all the time that there's something else out there. Just yeah.
You do like most of the tools we use I think that should be aware of having teams and grouping people. I know that there are already some that exists on GitHub, because I think there is for example on group for all the committers so I don't think we have that for all the working group currently on on the form that you can do groups because we use that on the on this course but I don't think that has been configured. And probably Same. Same thing on the wiki. So probably on this that would be like to be able to ping people somewhere. Might be a question of just like configuring the right groups. With with the right people in it or something to make sure that every time they are paying they will receive an email and get a chance to see that the team was was paying. So maybe that's something to add to the to the the brainstorm around ways to improve like collaboration and etc, between contributors because that would definitely encourage the use of the other ones if there is a way to ping actual teams I think. Yeah. Great, thanks neither I see you have your enterprise. Okay, Sandra is up first. Alright, sorry, you were up for a second
to get into you want to raise your point
maybe it's my turn.
Okay. Are you on mute? Are you calling
so do you issue
I sort of missed Ashley's point about whether slack or GitHub or reviews or whatever, but the larger issue is that I think everyone's overwhelmed with the number of number of channels through which they might need to do something and see things going on. So maybe I love the idea of configuring teams is pinnable. I literally had a question this morning from someone. Can I ping BTR on a pull request? And I didn't really answer and I think the answer is no. But if we could configure more of our channels to be more usable in those ways, that would be really great. Also, individually. It's hard to know how to tailor those, each of those channels to only show you the stuff you actually want. So I think I think a lot of people say things like oh my inbox is impossible. So I never see GitHub notifications, or discord has got way too many things going on. And those people configure their servers. Just don't look at this discourse. And there are ways to configure those things. And if we can help each other with how to configure those channels, we'll all find each of the channels more usable. And I would be glad to help with some of those things.
Yeah, just sort of curiosity to me, and could you couldn't ping BTR on a pull request. So meaning in GitHub or somewhere else?
Yes. So I'm not sure exactly what this person meant. But they it was either on an issue or on a pull request. It was in GitHub. So yeah.
Yeah, I mean, that's where that is possible if the teams are configured correctly. However, it's the sort of thing where it significantly divides opinion. So I always kind of like walk away slowly when this topic comes up, you know, Can we can we make it possible? Yes. And then 50% of the people in DTR will be really mad that we enable this and they get paid off. And the other 50% When they get screen?
I know and maybe maybe the answer is to forgive teams. It's not literally the membership of the working group. It's the people in the working group who are happy to be pinged on GitHub. I don't know. I mean, we we have lots of tools at our disposal, sometimes too many tools at our disposal.
And I'm curious what would be the objection to being pinnable? Like, you
get more more noise more traffic in your inbox that is already a dumpster fire and you want it to show up? Like GitHub gives you a lot of control over and granularity over what actually reaches your inbox. So in this case, I agree with you in general, this case is
it might be that people don't realize that when you get a ping from a pull request, there's literally an unsubscribe link. That means a particular pull request, which is really handy. And maybe people just need to be shown that and then they will feel better about it. I don't know.
Yeah, it feels like if somebody is really committed to this idea, which I am supportive of, but not It's not me. That starting a conversation about it in discourse to get people's input would be the right path forward and then we can decide like maybe we'll decide that each group has this like sidecar thing, which is like BTR notify or something like that. And people can opt out of VTR notify, but it will exist in it. As long as we have at least one person in each of those notify lists that that would be useful.
Can you hear me now? Yes. Okay. Yeah, I was trying to say that as, as in every so to say big decision and go in more a sink. It's always something bigger than just simple, whatever notification tools and so so obviously, technology allows us to be pinged or like via a pull request or push requests. You can also configure your Slack channel notifications based on some jorts. So you think about something like you think you should be pinned or something like that. But what I'm talking is that maybe we should come up with some sort of rules because work in a sink, in essence means discipline, it's not technology. It's some kind of another Mindset and like, obviously, each working group should work. In a way they pleased to work. But it kinda inevitable that we should be more thin gray cannot do that work synchronously, because it's on different time zones and different types of works and so on. So it should be like a golfer, I don't know, technical overseeing committee to push into that direction or groups and so on.
Yeah, I meant to that it's true that we always jump on the technical aspects and I'm as guilty of that as everyone else. But, but you're right, like fundamentally it is an approach a behavior, like how you organize your work is how you respond to solicitation. are you structuring your day whether it can be interrupted or not? If you will have time following up on stuff that I do, I think because that's that's actually one of the things that I think has been holding us back on this is that we've tried many times to add async stuff in things like typically we will for example, but we did with this working group, I'm switching one of the two meetings to something async but as a matter of fact, the async part a lot of people kind of don't do that part at all. Like, like if we look at the threads of this group on on this course. It's like mostly like the original report, by, by Tim I'll be posting some questions. Some people are on some my question mostly the people will come to that meeting, I guess. But a lot of people won't see the discussion, want to engage with it and want answered the way they would if that was an actual an actual meeting. So I agree with that is that like, having a bit of like, a general philosophy and instructing a how to how to approach not just the technical aspect because it's true that you need to be able to set your reputation right, but also, the fact that without how forever they will come time to actually work on the things that have been discussed in meetings. There is no way that work will be done.
Just wondering if we had something similar to to like, a set of guidelines so their other communities have regarding like, how we communicate or, or how we should handle or commitments or, or our updates in in this specific goal we are using for tracking that, nor case GitHub, for example. So at least recommendations are of how to use each one of our channels could be something useful because it's not just that people don't worry work as sink because they don't want but also because they don't know how to do it properly. Right. So, I know here we have a lot of experience placed in in the group of providers that we have to actually manage several teams. A synchronously so I'm sure there's a lot we can we can we can have experience we can provide for for this specific issue. So something for example, like what do you have in open graft? I've read your your handbook, and that's something really, really useful. So there you have several tips of how, as to how and when
you should communicate your teammates and everything so aiming to have something similar in the community could be
very, very hard. That's right. I guess it's really we don't really have a no openedx Handbook, right. Maybe that could be worth looking at and thinking about what we would put in there. And I guess we could start with something simple rather than simple are smaller than the N book of the world project. But at least nothing's under that angle like communication tools. where to where to start, what to use and etc. Could be a good thing. Would you be willing to work on something like that with me? Yeah, sure. Cool. That could be an interesting for sure. So,
so as a next step, I will just add that we will you had the dispatcher you could go in with a little bit more scope for for them. So I would just sit there and let's see, I
would I would get in touch with Neil, for example. We've been writing some documentation for maintainers. That's related. I think they're gonna be different Handbooks for different people for different roles, or one with different roles in it's like open crafts, I don't know. But anyway, there is some written stuff already. Out there.
us so we'll reach out to him.
And I think to see what that's one of the things that could be learning about a handbook because we have a lot of stuff here and there, but like trying to bring them together up onto something more career and cohesive about what the project be good. I mean, GitLab use it also to good effect that thing, like they also average on more roles than we do but yeah, all right. So I think we were almost to time.
Suspect product use and your average you as new UX UI product people in the community.
Cool. Sounds great. Can we have a good time for that? All right, and we are actually at time so there are still some new topics for next meetings which actually, I think is in later this month, right? Because we just moved the one from Christmas. So it's good. We'll get a chance to catch up with the backlog that we had a little bit so that's great.
