Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
this session is a core conversation it's got two parts how to get good reviews and how to give good reviews and the first part is mainly focused and prolific patch writers but also it's applicable to any bunny and then the second is focus on the people
who do reviews so if that sounds like something that you're really interested in reviewing court issues then you're in the right place otherwise you can pick a different session it's totally okay with me and that's all right so hi I'm Kathy
I'm ESET on drupal.org and too tall for this microphone I work for con press which is based in Hamburg Germany and I work there part time they pay me to work on core which is really cool and then they pay me to blog about working on core which is also
really cool and this is Andrea hi I'm Andrea sober I work for the nerdery and where I developer Drupal and I'm Zen doodles on drupal.org so we have a big problem in that there are a lot of issues and a huge chunk of them twenty percent of them are
needs review and the problem with having issues lingering in needs review is it's very discouraging for the people who worked on it hard enough to get it to the point that it needs review so they worked really hard and then they cannot progress without
somebody else helping them people who work on core can't work in isolation the issue queues go back and forth and it takes many people collaborating together so if you only have people working and on producing patch and you don't have people reviewing
it halts the process and it discourages the people who are making the patches it's also really hard on reviewers to have so many issues lingering for a really long time at needs review so there's over 2,000 core issues waiting for for reviews a thousand
three hundred and fifty have been waiting for reviews for two months or more and 500 have been waiting for a year if you contribute and you work really hard and nobody reviews your thing for a year you're not going to work because you you want to be useful
with your time nobody wants to just work because they work I mean they we want to feel productive and we want to feel useful some issues have comments on them so they kind of got a review but the review is like works or doesn't work and we also want to
get better reviews when we do get them we want more reviews we want reviews done when the patches are fresh and current and we want reviews that have actionable feedback to do this one of the things we can do is recruit core developers to work on more issues
so some of the things that we're going to talk about is how to make that easier so that we can we can grow those pools of people so let's say you are writing a patch and you work really hard on it and you post it in the issue and you market needs review
and nobody looks at it so what can you do to get somebody to look at it one of the things you can do is in your comment when you upload your patch is you can be really specific about the kind of root review that you need because you're going to upload
a lot of patches and over the life of an issue and initially you might be looking for architectural or a proposed solution feedback on the general methodology that you're using that's a different kind of review then I need a review before we ask a
core committer to look at it because that kind of review is I need to make sure that we've met all the core gates that all the standards that we need to are in place so when you post a patch be really specific about the kind of review you need maybe you
need a accessibility review maybe you need max somebody to manually test the thing that you're posting so just adding some words to direct the people who are going to come to look at it is really helpful and in addition to adding words to the comment when
you post a patch are these great tags that you can tag and and anybody can change the tags on an issue you don't have to be a special mission on drupal.org so use tags I make sure the issue summary is up to date hold on hang on good I don't have to
read all these because I'm going to talk about them so use tank so let's go back to that for a minute so for example these are some sample of tents the really nice thing about the tags field on triple org is its autocomplete and we've been standardizing
the tags a little bit so that when it's something is needs review they all start with needs so you can start typing needs space and you get a list of tags that already exists there and you can pick from those so needs architectural review needs usability
review needs manual testing needs screenshot and this is really awesome because this is how people find your issue who want to do what you need them to do so you get people who stumble upon your issue because it's it's the status is needs review and
but they'll be like like myself I'll find a needs review issue but it doesn't need my kind of review I I really like doing manual testing and sometimes that's the thing that I want to do so I will look for issues with that tag and then do that
so if that's what your issue needs mark it with the tag and then you will get pools of people who are actually want to do that and they will find your issue make sure that the issue summary that you have is at least correct so it doesn't have to be
like super perfect I like issue summaries that use the issue summary template or all up to date with all the comments but at least correct any actual misinformation that's in the issue summary and the reason why that is important is because let's say
you really want your patch reviewed somebody finds your issue because you did use a needs tag and then they start to read the issue summary and they get confused and then there's 25 comments of an argument and they're a little bit more confused and
they get to the end and they see your patch and then look who they want to be efficient you potential reviewer doesn't want to waste their time and so they're going to move on to another issue they're going to be like I'll look for a different
[ ... ]
Nota: se han omitido las otras 3.011 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.