CLJ Screening

so the overview of things i wanted to talk about today the first thing was symptoms problems and solutions which is really sort of how we talk about changing closure um and look at jiras and try to work think about things um some just general process stuff about how closure stuff works um how you can help and if at the end if we want to do some q a that's that's fine too so a lot of times bug reports uh that come in usually through ask closure these days um are really in terms of symptoms so um they're you know i tried to do something and it didn't work um so good symptom descriptions include what they're trying to do and i'd say that's the number one most important thing and it's often one of the most things most commonly omitted from the description so um as you're looking at this sometimes you and sometimes it's it's the user generally genuinely trying to help by creating a very narrow reproduction of their original problem um so as they do that they'll winnow down to something very small sometimes that's helpful but it's oft often also useful to know like what were you doing originally like what were you trying to do originally um and so having both is actually pretty useful um but that's something to be aware of um so you want to know what they what they did ideally they might have done more than one thing so sometimes it's useful to know um the the set of things that they did um you want to know what happened and you want to know what they expected to happen because like that's why they think there's a bug and they're filing something they're it's because there's some difference between what happened and what they expected to happen and a lot of times one or the other is not clear um so when i'm looking at good problem reports or i'm looking for symptoms that have these characteristics um often it's also useful if they have tried things they might have tried things that made the problem go away and if they happen to have noticed that that's awfully useful to know about so that's also something i try to look out for and i think another thing might be workarounds if they so if they not that's something necessarily something that made the problem go away but a way that they got past the problem um problem so um often the thing that the user is experiencing is not the actual problem um and of if you take one thing away from this whole talk this is this is the whole the whole game is trying to get to a real description of the problem that occurred and this is particularly important for things that are improvements or new features rather than like a lot of times with bugs like the problem is that there's a bug the code is wrong so that's not a particularly interesting uh problem but when we start to think about bigger things that cross um especially across you know larger feature sets or problems or things like that that's we're really looking at trying to understand the real root cause of what is wrong what is missing what abstraction is missing things like that and so like sometimes you'll hear the five whys is one technique for this is like the user saw this well why did they see that oh because this thing happened and why did they see that well because this thing happened and eventually you bought them out and something like you know you tend to at some point you'll bottom out in like some process allowed this bad code to be written in the first place um but so once you got to that point you're probably far enough so um it focuses on he and i spend a lot of time with rich working in this area and trying to get at a really clear description of the actual problem that's independent from whatever solutions might be out there um and that's that's this is the whole ballgame so um if you're going to focus on making tickets better this is the number one best way to help with that uh and it's hard it's so it takes an iterative process and sometimes it helps to get a second opinion from somebody else or a third opinion even and i'd say this is the part where we actually spend in some ways the most time um it's also good to make presumptions or assumptions explicit if those aren't already explicit mention that so solutions once we find the problem um you ideally could come up with multiple oops multiple approaches um that could that could fix the root problem and alleviate the symptoms and so it's important like finding the right problem is important to be able to come up to generate good solutions and then evaluate those solutions on hopefully multiple dimensions a lot of times we'll get jiras that come in that are you know improvement heroes that come in that say things like add a new erity to whatever so that is a solution that's a that's a thing that you can change that will do something but it's telling you nothing about the problem right like you want to add a new area to this function because you're trying to do something for the purposes of something like the whole problem is unstated if you get it look get a you know improvement jira like that and we have lots and lots of those in the system um so um and those ten like i said those tend to be more on the improvement tickets than on the bug tickets um but you see them there too like you'll see a bug where it says just fix whatever um and uh those are things that we generally try to change and and really try to get at like what is the problem that the user is trying to like what are they trying to do that they're not able to do with what we currently have um okay alex i'd like to chime in just a second i i think that when tickets like this do have problems uh they tend to be of the form closure doesn't have x and and and then the solution is here's here's here's an x add an x and so that that that um that's that's good as a as a first swing but it it never serves as a as a problem uh which i've learned uh the hard way numerous times when when and when going through this process myself yep so like an example that rich likes to use is you know a symptom might be i've got a headache and uh us you know you might immediately say well you know the problem is you've got a headache so your solution is to to take some aspirin um but the problem is that's not the what if that's not the real problem like you're still in symptom and solution space like maybe the real problem is that um your eyeglass prescription is off and that's giving you a headache in that case you haven't identified the real problem the headache is not a real problem that's a symptom right and so you want to keep digging down until you get to the real problem and then you can evaluate multiple things you might take an aspirin that that temporarily relieves the symptoms doesn't actually fix the problem like the real problem is going to the eye doctor and getting a new prescription or whatever so you have to keep digging until you think you've really gotten to the real problem there um so ideally when we work on especially improvements bugs like you'll see in the in the jiras that a lot of uh problem jurors don't have our bug jurors don't have um don't have multiple alternatives considered um sometimes that's because you just find that there's a bug in the code so it's just a matter of fixing the bug but the improvement in feature ones definitely should um and you want to try to come up with some alternatives you want to try to come up with different dimensions on which to compare the alternatives and this is its own whole whole thing i'm not going to get into a lot of a lot of uh description about that um but things you tend to look for are if you've got two columns that have the same sort of answer for everything then you're missing some differentiating dimension so you need to add some rows if you've got sort of the same if they're equally good and there's there's if there's something that's all good or all bad you're probably missing dimensions um and a lot of times what we're looking for is like for the thorny problems you tend to end up with um cases where there are trade-offs where like there's good parts of one solution and good parts of another solution but also bad parts of both of them so then it's a matter of like ah a lot of times that's a point or two is there some novel way that we can combine the two things that have good aspects to them and that's where we've come up with some novel things in closure is exactly in that case [Music] so those are just like words that we use to talk about these things and the ways we think about them um this is a workflow diagram this is out on the closure website um so and i actually made this diagram on the very first day that i joined the closure team back in 2013 um it's been modified a little bit since then i think it probably needs a little bit more modification but it's basically a result of conversations we had back on that day and has been mostly how we've worked on jira's for a long time so generally issues come in at the top and flow down to the bottom each of these nodes in the graph is effectively a cue which is represented by and there are jira reports that represent each of these um sort of act as that cue the colored boxes are basically processes that we identified in practice most of the blue ones and a lot of the orange one a lot of these are done by often dug by focused eye and that's where we could we could use help and then the green ones are mostly rich and you can think about this from a big picture as is this a good problem report um is it a good problem and is it a good solution that's kind of the three big questions we're trying to answer as we move through this process so um you start in you come out come in as an open ticket um triage it says here problem good but i think i'd really say is this a good is the report good like i really want to know like is this um a good description of a problem that we could actually work on um it doesn't have to be a good problem this has to have good symptoms basically um i want to know and i've got some stuff on that later we'll talk about that more um sometimes we go through this pre-screening process where we'll actually do work on the solution before rich ever looks at it that's kind of a that's just something that we've found is sometimes useful as a way to um because betting occurs you know just periodically it allows us sometimes to sort of get group create a sort of a more greased path through the through the process so tickets sometimes by the time rich first looks at them they're ready to move almost to the end so um that's just sort of a side thing that was that's something that we added a few years ago and i occasionally do vetting here is is stated as a rich process but i'd say there's really an opportunity for us to do clean up on it and that's kind of where i'm asking for help the most is sort of to do a community level vetting before rich does his vetting and really the vetting that he does is really more uh really now more of the release assignment aspect of it so um focus i have been trying to go through jurors and and scope out a set of them to give to rich about once a month and so we have a set an initial set for 1.12 um that we put together and so that's where we could really use the hand is making sure that those tickets are in good enough shape for rich to look at as the first sort of gate to get into the system to work on it um once it goes to rich then he's gonna he will market if he thinks it's a good thing we should do we should a good problem to work on build market is vetted and target it to the next release at that point it really depends on what exists on the ticket already sometimes those tickets have patches sometimes they don't if they do have a patch then it gets dumped into the screenable queue it's basically there's a proposed solution there you know is it any good often tickets at that point need work so [Music] if it doesn't have a passion that gets dumped into the needs patch queue at some point somebody does work on it makes a patch adds it to it then it gets dumped in the screenable um screening is something that generally focus and i do um i i'll talk later about how you can help with that um and there we're sort of evaluating you know the solutions considered the solution that was chosen the patch that was added all that kind of stuff it's pretty common for that to then get dumped into either incomplete or sort of what happens if it's the in this sort of cycle cycle and this sort of development phase is a little murky we kind of tend to there's there's fewer tickets that are sort of in this process and we sort of move them around a lot once they get in here but the goal is to move things from incomplete back into something screenable by fixing whatever need to be fixed with the patch and it's not uncommon to go through six seven patches for a for an issue before we get to a thing that we leverage look at so that's and that's not um that's not a reflection on the community those are often focused and i doing multiple batches so we'll go back and forth many times um before rich looks at it and then rich is gonna screen it and look at it um and he may kick it back to that process and we'll you know he's got feedback and we'll start that over again so um that's just how things go and then eventually he will do he will uh mark things as okay which basically means they're free to commit um for a long time that committing and releasing process was done by stu i've been doing that for the last year or so um so but that's core team stuff basically uh and then once they get in then we cut a release so that's kind of the overall process here i've talked about there's sort of three main issue types bug improvement and feature there are some other things in the system but those are the three that we basically use and we really try to mostly focus on bugs and then we we really don't look at the improvement and feature stuff quite as frequently still trying to figure out the best sort of way to move through those we've been using the ask closure voting functionality to find bugs improvements and features that are important that people care about that we should be looking at sometimes we end up working on those sort of outside of jira um it really depends what we pick out so as far as processes go i want to talk about triage vetting and screening and all of these have more words on this screening tickets page which kind of covers all three of these processes there's really a lot of overlap so i put them all on the same page so triage is really about taking new reports and making them into good reports um so typically you're starting from something that's either that's an open state and there are actually lots and lots of tickets and closures that are in that state that have not been triaged so if you want to work on those that would be fine it would be i'd be perfectly okay with people working on those and try to improve them i do go through old tickets periodically and try to see whether those are still problems and you know are they you know i do clean these a little but um probably more work could be done um but these are just the questions that we had before with symptoms so it's really about you know um a lot of times like one of the big things we want to ask is like the user expected something happened and something different happened um are are the users expectations actually correct like maybe they just their expectation was wrong and that's why they saw something different um in that case sometimes it means there's a doc string maybe that's the issue is really a doctrine change or it should really be a ticket on the closure website where the documentation there should be different or something like that so sometimes that still ends up being an issue but it's a different kind of issue are the symptoms reproducible so um you know can you can you say that you know can you reproduce it on your own system um it's often useful to sort of capture the version information about where it's happening um and like if you can check older versions and see whether um see whether um you know it happens on you know when did it start happening if you can you know sort of bisect to that sometimes that's useful um is the scope of impact clear so like is this a thing that's just only happens in very specific kind with specific kinds of data like it only happens with negative numbers or it only happens with long max value or something like that like that's an important piece of information um and then is this a duplicate so and there there are definitely are duplicates in the system um it is one of those things where sometimes until you have identified the actual problem sometimes it's hard to tell which tickets are are duplicates um so sometimes it will happen where like we're looking at a problem that you know on an issue and we find out what the real problem is and then i'm able to go back through jira and find many instances of this problem logged as other things like that's a pretty common case um so uh finding those kinds of things is actually pretty useful um once you have looked at all this stuff you sort of have options you can you can update the issue to clarify the parts of the description that are you know need help um you can you might need to ask questions of the original poster um you can just leave comments it's kind of some of this is kind of is going to be up to you about how comfortable you feel editing the issue with things that are in open state i'm mostly fine if you update the issue itself if you're not sure you can add you can always add a comment like there's never a problem with adding a comment on a jira issue so that's always fine um if you want to update the issue then i think you should generally be pretty sure what you're updating so if you're not sure then you should ask either ask it as a comment or you should go to the closure dev room on slack and ask it there that's that's fine too um and if you are pretty certain that what you're doing is correct you can just mark it as triage that's fine like yes this is a good report i've fixed it and made it better just mark it as triage so if you're a little less sure about working on closure tickets but you want to try to help um this is a good place you you could help just go to the open thing try to make sure it's a good problem for marketers triage um vetting is kind of the area where i we could particularly use some help right now and here it's really about whether this ticket is describing a good problem so um is there a problem listed at all so something that comes in as a user space problem might you know might really be symptoms and so the problem might not be correctly um correctly listed um eric asks if there was a question about a pre-triage queue so that's really the open uh jira report so there's a clj open um and i think i have links to these later on so there are cues for all those things there are existing reports for that um so in vetting we're really trying to form as much of the description the issue description that's about the problem as possible we're trying to make that well-formed um it's not as important whether it's a solution or a patch i'm you don't need to evaluate the patch you need to don't need to evaluate the solution um uh any of those things so that's not as critical um we'll start to work on that once we get into sort of the dove once rich decides that it's a problem we should work on that's when we really usually start to focus on that stuff um so your your actions here are basically to either um update the issue to make it better or to add a comment um and like i said there's some there's some i have some links that i'll talk about for where to do that screening is really about whether it's a good solution once you get into screening i would request that you really have a lot more uh communication with with focus and i um because we're usually things in screening are things that we are actively looking at um so um if you are going to be making a lot of changes or think something is really needs to be changed there please make comments um or talk to us like in slack or something like that so that we can we can make sure that you're not overlapping with we might be actively working on it in some way so um so the question here is really about whether this is a good solution at this point the problem should be super clear that should have already happened through the vetting process but sometimes you learn more as you start to work on solutions there should ideally be multiple solutions listed there should be some proposed solution out of those it should be really clear what's being proposed why it's being proposed if it's one particular alternative why is that one being picked and there should be a description that covers the patch so that if i read the proposed solution and then i go look at the patch i should not be surprised by anything so if the you know if the patch touches three different parts of the code i really really want those three things to be mentioned in the proposed solution so that like in just in general if i read the patch that nothing should be surprising once i get to that point i should already understand what the problem is what problem we're trying to fix you know what the solution is that we propose and how we're fixing it and the patches should be obvious at that point in most ways we it is really helpful to list the name of the patch that is under consideration even if there's only one patch attached to the ticket um it's i know that seems silly but um it is very easy to have a second patch edited ticket and then the first patch is not listed and so nobody updates the description and then it's confusing so it it's it's not confusing until it's confusing which is almost immediately so so that's really helpful perf is an area where we often need benchmarks and things like that and we want enough code that we can reproduce the um thing on a you know maybe it won't get looked at for six months or a year or something like that you don't know and so it really is useful to if you have numbers they you should at least say what closure and java version you're using at a minimum um and you should have enough code that we can reproduce benchmark later um it's it how you attach the perch from our benchmark code is i'm flexible with um but you know if it if you can put it in in the ticket or as an attachment that's awfully helpful um external repos or gists are i'd say slightly less good but better than nothing um and but you know as minimal as possible so that they you know we can rerun them later is awfully useful um like i said i prefer that you mostly stick to comments unless you've communicated with us and we've told you something else and if you have that's fine it's not like you're not allowed to work on this but but i would prefer that we communicate about it um editing jurors jira is publicly readable um because it's a cloud instance and we have a finite number of users that we can add to the system um it's a it's a donated instance that we have so there are some limits there um so generally we we reserve access to jira edits for contributors that are actually working on something so if you're in this meeting then you're probably interested enough in working on tickets that it's okay to have that many of i can see just see from the list that many of you are already contributors and have access but following the becoming a contributor section on the website to sign a contributor agreement and then request access to jiras the process to go through for that as i said comments are always okay that's always fine on any issue um edits um if you're going to really be editing the issue and making updates to it it is helpful if you use the assigned to field so that you can let people know that you're you know working on this issue right now and and it's helpful then also to unassign it once you get done working on it so that other people know and if it's already assigned when you go in to look at it then it is certainly polite to ask that person if you can find them either on jira or in in other places in the world um uh it's polite to ask um i you don't have to wait forever if you ask and you don't get an answer in a day or two it's fine by me if you just take it over and say i'm gonna start working on this um [Music] because it's often that people you know just set it and then forget about it so where to start so these are cues these are all links to [Music] two things and these same links are all exist on that screening tickets page so so under each process you'll see that there are some links to jira filters so for triage there's the clj open filter which is all things that are open and untriaged um you'll see these are all in open status the approval field is not set so these are all things that are open like i said there's lots of these there's 360 of them so you know go nuts um for vetting there are existing cues for triage but in particular i want to draw your eye to the clj 1.12 candidates this is a set of tickets that phogus and i went through and hand selected as important bugs to be looked at for 1.12 um and [Music] so this is a particular cue that i would like to clean up um so that rich can look at them so um some of these are pretty gnarly um a lot of them have had a little bit of work done on them so they're not in general in that better shape but anything you can do to improve these um would be helpful um this sort of thing that focus and i do sort of in between working on other feature type stuff so we you know sort of cycle in and out of it periodically the more that you can do to make these better that would be great that would be something that focus and i could do less of and we can do more of other things so most of these are bugs there are a handful of improvements and features here that were um that were actually in the queue for 1.11 and rich didn't look at so um i believe most of these more improvement type issues actually have had attention from phogus and i except maybe this map merges one which i just pulled in there um so those probably have had more work done on them and if you wanted to actually work on fixing these i don't like most of these have patches this one was not marked as having a patch but might another thing to mention is that if you look at this filter you might have different columns so you can change those by changing the column set that is your default set your set is probably different than my set so you can't edit those and let's see triage is going to be pretty wide um [Music] so it you know if you want to work on stuff there that's fine there's no guarantee that the ticket that you look at might be anything that we look at anytime soon but in general if you work on things that are higher priority those are probably more likely to be things that we look at soon the priorities are not you know really super especially in triage or not really well well filtered but so out there for screening um again anything that's in the 112 candidate list stands a good chance of getting into um getting into 112 and that means it's useful to be doing work looking at the solution stuff um vetted is a is a set of tickets that rich is vetted but are not many of those are not targeted to the current to any release right now so there are things that have already been marked as being good problems um and for a variety of reasons they may not have been you know gotten into a prior release and there actually are a lot of those out there um if you do want to work on these these are generally a lot of these could probably use help some of them are things that really need to be may need to get pulled out i don't know so these are these are in kind of a weird place if you have questions about those probably best to talk to us uh and then screenable things are things that are sort of gotten into we're working on them and looking at them and that list is currently empty because we have not started really working on stuff for 112 years so there's not much there as far if you do get into screening and looking at um [Music] looking at fixes there's a lot of stuff here about how to evaluate patches i would encourage you to read all this i'm not going to go through all that stuff but um there are a lot of tips here about how to do that what to look for all that kind of stuff and that would be appreciated as well oops [Music] oh i think that's the end so um oh and i wanted to mention if you wanted to look at like prior tickets that have been through all this stuff um i linked to the change log um this is just in the closure git repo if you look at you know fixed tickets for um for 1.11 these are all things that have been through this process um so you're likely to see sort of what we're expecting to see and i would say that like there's a list of things on the at the top of this is sort of what does a good bug ticket look like in sort of different fields that we're expecting to see in there um you may not see all of these fields on every ticket it's we're not dogmatic about it it's a you know it's not a hard thing to actually make all of these things exactly but you'll typically see these kinds of things here really when i pick up a ticket cold i wanted to tell a story i wanted to tell a story about here's what a user was trying to do here's what they did here's what happened here's what they expected to happen here's how i can reproduce that if i haven't already said that here is the the actual problem or the cause um like so they experienced this thing the reason they experienced is because some root cause here's some ways we could fix that here's the one i picked here's the description of the patch that implements that thing like i should be able to read through that whole ticket and have like a really good idea of um what happened how we're proposing to fix it and all that kind of stuff like that's the idea and that's what you know that's what we try to give rich is um something that is in that state where um and when he gets to screening like you know he can screen a ticket in you know five minutes sometimes um because if it's well lying you know if all that information is there he can just read through it and like it will make sense and and uh okay so it goes so it's a it makes our use of rich's time very efficient uh when we do that um so i don't know if i have i mean feels like this ticket is one i i worked on a lot um and this one it might be instructive to actually go look at what so the original ask well this is the original thing it's actually and came into jira i think not through ask closure but um this is you know this is a user reporting a problem and a you know and identifying what they believe is the solution um so now it's actually so there's actually a link here to more background so the original problem is i guess that's interesting i've ever seen that before maybe the link's wrong oh it's getting a comma at the end that's what's messing about so this is a you know a deaf test that reproduces this problem um and you look at this in like one of the test season one test fails like it took me some time to understand what was happening here it's pretty well laid out and to use either local or global hierarchies here are multi-methods i should say that have different hierarchies um so that's a good that this is a you know a lot of things that we want here it's kind of a little bit implicit what the problem is but i think it's it's here um [Music] when it got filed in jira it actually had some patches put on it those patches partially fixed the problem but didn't really find the whole problem i ended up spending pretty much a whole day on this um tracking this down there's actually a lot of concurrency issues with it and stuff like that um so this is just a good example of a ticket that that went places that i did not expect when i first looked at it i'm not going to go through all the details of it but i you know literally completely rewrote this issue um it does have some of the stuff in it that's came from the original ticket but i rewrote some of that um i wrote a lot of stuff here about the cause it's not important we read all that i don't understand it all but um it took a while to get to the point where i understood all that and here you'll see there's a proposal of how that should all happen and then a patch and then eventually you know got screened by focus and and you'll see that this is the dash four patch and we went through went through a bunch there's a lot of patches out here um so it went through a bunch of different updates on this uh we went back and forth on it a bunch so and there's actually a related ticket to this as well it also got updated and sort of folded in so uh it can get kind of messy but that's the work i'm trying to figure all that stuff out so i guess that's all i had that i was going to blather about so i've got about 10 minutes if do you have questions about how you can help or where to get started but i haven't answered so hi my name is daniel um i was just going to say it sounds like from what you're saying if i'm you know feel very new to it start with the triaged list and then just from there pick one that looks a little friendly and maybe make a comment or two and really understand it and then try to brush up the fields that need to be included for it to be really considered high quality and then maybe that would be the first thing i do yeah and if you have questions ask in the closure dev room that's fine um we tend to watch it but you know it might go a day or two without getting an answer or something like that but um yeah anything you do to move the ball forward on those triage tickets is fine um some you know we have i i know there's lots of tickets that are been sitting out there for a long time in particular there's a ton of improvement tickets um so um but that's just you know how it is and uh we've been trying to get a little bit better on how we look at the bugs if you actually narrow it to just non-spec bugs that are in the closure jira there's i think 130 something so there's really not a huge set there we've been trying to work on bug stuff the important bug stuff as the priority yeah thank you this is this is pretty exciting so i'm excited to try out uh try out you know working in jira and stuff yeah yeah i guess i didn't go over that details of editing your tickets man stuff is that something that people wouldn't that that's something i'm familiar with um from from my day job i mean so it but you know everything's awful in this space so it just isn't a bit sad uh the reason i asked for this uh pre-triaged thing was to you know it's kind of scary for us to make decisions based on you know stuff that we shouldn't be making decisions on um and but there is also a problem in that the list of open tickets uh may have been worked upon by someone at some point in time or so what i was sort of proposing was uh if i went ahead and i looked at a ticket that just came in right um and i did the updates that i thought were pertinent and then i could signal that hey i think this is you know in in shape for you guys to triage it rather than i deciding that it it was triaged if that makes sense yeah so the best so i'd say the two ways you can do that one is by um tagging either me or focus on the ticket so you can use a person link i don't remember what syntax is there's some way to do that um i'll get a notification about that um or probably better is actually to put it in the closure dev room and slack and just say i looked at this i think it's ready to marcus triage what do you think whatever it is um i'm happy to look at that i'm really not concerned about you marking something triaged incorrectly if so if if you think it's ready i mean i'm actually okay with you just marking it as triage um it's uh it the worst thing is that it will you know it'll get looked at again for vetting and we'll we'll decide differently so that's no big deal what's your thought on on closing issues because uh like is that perceived as a negative thing towards the community or is it a good like i you know i suggested something and then you know even though you say that the future is very long and certainly uncertain um you know uh yeah what's your stance on closing tickets really that's i guess a question well i would say you probably shouldn't close the ticket but i might so if you think it's not a problem or some you know put a comment on the issue or ask me in slack and we can talk about it sometimes i close things and you know i i try not to close the door on too many things but also like sometimes it's just not worth having that open and sticking around a jira and all these cues if it's not something where i think it's likely we're going to do so it's not the end of the world if we close something and then later on we decided to do it that's fine we can file another tip or we can find the existing one and reopen it or whatever so i'm not that worried about it all these tickets have history on them so if you do something and it's wrong you know we can always um we haven't lost anything it's there so it's fine any questions all right well if you uh feel free to hit us up on slack i if it would be you like i'm still not sure what will be useful here like if it's useful to have just an open-ended chat about stuff every couple weeks like i'd be happy to do that so i'll definitely consider that this is kind of an experiment trying to figure out what the best way is to to work with people so um feedback is welcome i guess one one thing that's uh it's really scary to say this but one thing that might have been missing from this is the problem statement right um in terms of what what are you guys uh looking for uh what why are we so there's and there's more than one problem here so the big problem is that there are a lot of tickets that we've identified for 112 and we are working on other things and so i would like help in making them good so the problem is that that focus and i can't do it all that's the problem so is that time is finite so uh but are you looking sort of more more in the in the preparation like the the ticket preparation part more than you're looking into uh like solutions uh part or really both um but the place where right now this moment would be useful is having help on the vetted tickets um in those that candidate list that's the place where we could use i think the most specific help some of those have patches on them that need uh some of them don't have patches some of them have patches that haven't been looked at so there are there's is definitely opportunity there and what you'll find as you start to work on these is it like you'll work on the vetting part of it you'll get your head into the problem and then you want to work on the solution too so like you know sort of often working beyond just the problem stuff um the problem part is the part that i probably most immediately care about at this moment but um you will inevitably uh also work on other stuff as well so sort of related problems are i would love to have more help you know throughout the process i'd love to have more help on the screening parts of it um if we can sort of uh it's one of those things that requires practice and so like if i can help if if more of you can help with practicing on that stuff maybe you'll be you know able to help more with other parts of it as well and maybe we can have a bigger set of people that are sort of actively working on this um in the community and i think that would be good so all right well it works for me because i'm a new bank shareholder so everything i can do to contribute just benefits me right sure [Laughter] definitely or new bank shareholders too all right well i'm going to cut off here thanks a lot for listening and uh i will um see you on slack i guess and i'll think about setting up another follow-up maybe in a week or two i'm not sure there's got some travel coming up all right see ya

An overview of the process for Clojure development and contribution Recorded in 2022