Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
hi I'm Kathy and this is a core conversation and the it has two topics in this time slot one of them is patch reviews how to get people to review your patch and also how to do a patch review some of the tools that we use to do that some improvements that
we need to make to the tools and the second topic that we will talk about after a break in the middle is mentoring mentors how to turn regular people into mentors of mentors and because this is a core conversation the format is a short presentation and then
a long time for discussion and questions so my goal is to do 15 minutes presentation 15 minute questions 15-minute presentation 15-minute questions I won't make my goal so you guys should like beat me when I get to like close to 15 minutes so my name is
Cathy uh oh and so if if you want to stay for only one of those topics that's fine and if you want to switch rooms that's also totally okay really is um so my name is Kathy I'm the SCT on drupal.org I'm also yes CT on Twitter so you can tweet
at me at during the talk or after the talk I review patches quite often and mostly in core but the topics also are going to apply in part to contribute outside of the drupal program itself I do some other stuff like plan sprints I really like to plan sprints
and I love going to them so for example Friday I and spend a lot of time asking other people to do things so that Friday happens and I do some things to make fry to happen also you should all come on Friday Friday sprint day i also have a part-time job I work
for calm press which is a company in Hamburg Germany they're a small Drupal shop of about 20 people and my job for them is to work on core so they pay me 15 hours a week which I split between actually working on core and blogging about working on core
and and then usually I also can't stop working on core so then I keep going even if they don't pay me so a little bit about the process and why reviews are so important web chick has this awesome a talk that she gives and there's a video recording
of it a youtube video and there's a tiny URL a web chick dash how and this is one of the slides in her talk and it shows that we can't solve any problem that we have by ourselves we need somebody to report the bug in a way that makes sense and we can
understand it we need somebody to produce a patch to fix the bug we need more people to try and document more things about how to reproduce the bug we also need somebody to review the proposed solution which they'll find problems with which we get a new
solution then we need another review and another new solution and another review and it goes on like that and if we don't have reviews we don't get anywhere in the process that's important both for the people who make the patch they want their
work not to go to waste shouldn't sit there in the issue queue forever and not do anything and it's also important for the people who are doing the reviews to know that they are really important in the process after it goes through a period of community
review when the community thinks it's good somebody will be bold enough to market reviewed and tested by the community that's when a core committer sees it they will review it if they have a problem with it they'll set it back to needs work so
there's no danger in reviewing something because there's always somebody else that's going to check it after you too you just do the best you can it's a big problem space we have a thousand five hundred open issues that need review not all
our issues we have like fifteen like 10,000 or a lot of issues 1500 of them that's twenty percent a need review so first it's an interesting order but first we're going to talk about how to get patch reviews if you make a patch when you post the
patch it's very helpful to be specific about the kind of review that you need usually you set the status to needs review and what kind of review so you might add a comment when you post your patch like I'm just putting up this half done thing because
i want to get initial feedback on the approach that's really helpful for somebody who finds the issue needs review they know what kind of review to give or you think you're totally done you're like I really think this is great but I need a JavaScript
person to look at it so now you know what kind of review so when you post your review tell people what kind you can do that in words in a comment and you can also use tags there's some really common tags that we use in our issue queues and these are some
examples of them they usually start with needs so needs JavaScript review needs a usability review needs manual testing when you produce a patch you worked really hard on you invested time in it and you don't want to go it you don't want it to go to
waste if somebody finds your issue because they saw its needs review status and then saw that it needs a JavaScript review and they can do javascript reviews you've got a potential reviewer looking at your issue you don't want them to leave because
they can't understand what the problem is or why your approach is a good approach in order to keep a reviewer looking at your issue it's very helpful to update the issues summary make sure that there are a clear description of the problem steps to
be able to reproduce the problem and a description of your approach maybe if other approaches were discussed why they were not the one that was chosen and there should be a summary so we're easy to read five minutes to the point steps to reproduce for
people who are going to test or review your patch should start with install Drupal 7 or install Drupal 8 number one step you have to be really clear step-by-step and they should be numbered if you add uh needs tags like needs screenshot it turns out for almost
four a bunch of the needs tags the community has instructions written down that tell people how to do that so we have instructions written down for how to manually test something we have instructions written down for how to review an issue technically but
those instructions are hidden in a docs page tucked in a corner somewhere on drupal.org so I think it would be really great if when we added needs tags to things automatically drupal.org added the link to the instructions to the issue so this is a mock-up
of how that might look if you know anything about usability and you can tell me if this is usable or not that would be great so there's both an issue in the drupal org kind of infrastructure customizations issue queue and there's also one in dreaded
ER and we can make this happen either of those ways and there's pluses and minuses to doing that but the idea here is that the link is the link to how to do the thing and then paired with the link is the tag so that it's clear to the person looking
at it how that link got put there so the back port a Drupal core patch linked to the instructions for how to do that is there because it was tagged needs backport so there you go so that would be really great and we have issues in the cuse you can start to
work on that to make that happen right away oh I shouldn't here's the close-up so you can see it better and so the issue on drupal.org is 2013 22 2 and the issue in the dreaded er github issue queue is issue 16 so these instructions are all kind of
named with a pattern we call them contributor task documents and there's a list of them at drupal.org / contributor dash tasks / review oh that's an example of one if you go to that one it they're all grouped there in the right-hand sidebar so
you can see all of the different ones that exist that we've written anybody can add a new one so if you know of a needs tags that's missing one you can see how to improve the documentation the kind of system that we use and you can go ahead and add
one you can also edit them to improve them you don't need special permission to do that um feel free it's if you have produced a patch and you want to review it's because we don't have those issues solved yet for how to automatically add these
instructions it's very helpful if you find the doc cut and paste the link put it in a comment on the issue so people who find your issue can actually do the review that you so desperately want if we don't get reviews quickly the patches go stale and
then we make more work for ourselves because we have to either fix it because Korres changed wildly in terms of approach or it's just moved a little bit and we have to reroll it but you don't want to do that as a patch producer you want to get somebody
to review it when it's fresh it's less work for you that way if you are creating patches that are similar or you need to create a bunch of patches that are similar grouping them together under an meta issue actually helps you get reviews because you
can have a new person find the meta issue if you put really great instructions in the meta for how to do a review because it might be like a very special topic like perhaps it's about schemas or it might be about undefined unused variables we have no metaphor
that you put very specific instructions in the meta somebody who finds an issue it's linked to the meadow or they find a minutes link to the issue they'll see those instructions maybe they'll review one of them well if there's a hundred issues
like that and you've written down really great instructions they're going to do a couple more they're going to review another one maybe three or four of them then they'll go on and do something else so if you have something that's very
similar documenting the instructions for how to do it makes it so other people will do what you need them to do which is to review um if you've made a patch if you produced a patch and you want somebody to test it but the audience of testers of reviewers
that you need is it doesn't have the dreaded er plugin installed for whatever reason perhaps their own a device that can't have dreaded her on or they don't know about it you can also build a custom URL to simply test me and you can post that either
in the issue summary or in a comment and when you do that it enables people to test a patch without having a local environment so simply test me lives in the cloud you tell it which projects which module you tell it which patch you want applied to it and then
anybody can test a patch and they can test it on their phone when they're on the train and if that's if they can't use us certain kind of device but they can use another one this is all hosted in the cloud and all they need is the URL that you
send them you can tweet the URL you can mail it to them it's really super handy another way to get people to review your things is to give reviews like literally in terms of a trade you can just say hey I really need somebody to review this I'm willing
to do anything I'll even review one of your patches and that works but whether or not you haven't won 2-1 trade the more you give reviews the better reviews that you're going to get back in return because there's going to be more examples of
good reviews out there people center tend to repeat the patterns that they see happen over and over again not everybody is going to read the instruction the contributor tasks document on how to do a review what they're going to do is read the issues read
[ ... ]
Nota: se han omitido las otras 5.771 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.