Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
okay welcome everybody this is tooling for core initiatives I'm Gabbar Ho Chi I'm one of the initiative leads four-two blade and this will hopefully be in actual core conversations where you will hopefully come up and and discuss the problems that
I pose I don't have solutions for the problems I have problems so I will try to outline those as best as I can and then we'll see where do we get from here so I don't really know where what kind of next sections will be able to derive from this
conversation but what the methodology that I used for preparing this talk is I best all the core initiative leads and the themes in Drupal 8 2 to give me their tops top tools that worked for them and top things that didn't work for them and things that
they would love to see on drupal org or in any way to help their initiative succeed and I try to collect them in the framework that make sense for for what we do so so when I was thinking about this talk I actually realized that I i will talk a lot about tools
but I want to put it into a framework of managing a project in general and this looks like very much a project you would do for our client that if you would follow all the steps for for for the standard project then we usually have a great idea to implement
and then you would have shot a plan for for what you want it to implement so you would have a higher level plan of where you want to go why you want to do it at all what kind of priorities you have that you want to achieve and then you would break that plant
down to actionable items so in agile terms you would have epics that you break down to user stories for example and you would estimate those things how long would they take and then you would have a backlog of issues with priorities that you want to work on
and dependencies between them and then you would take some of these issues into sprints and work on them so you could get closer to resolution and you would work on your most important things and you would test those things and pair program and whatever other
nice things you want to use there and then you would need to report of course for the client and you would need to figure out what you did and and if you did what you wanted to do so you would do progress reporting and then you would reflect on what you did
and whether you did it right and what you want to improve and go back to either part of the cycle to take a new stories for the next sprint or replan or do other important things there so at least this is my experience from several other projects outside of
the Drupal community where you have control over over what comes in and the team that you're working with and the output and you have a client to report to etc that sounds very formal but when I look through all the stuff that we do in Drupal core now
we go through all these steps although we might not realize we are going through all these steps we actually do and we do a very poor job of doing a lot of these things so what I think I think what we excel at is this is part of the Sprint's step so we
have we have tools to work on stuff but we a lot of the times we don't really consider the the framework of why we are doing it where do we want to go how do we tell people what we did and just reflect on if we are doing the right thing and if we want
to move elsewhere etcetera so we have a lot of randomness in our process and there are multiple reasons for that as Greg always says we are we are this big project but we don't have any resources to allocate for for our work so we can't really plan
at all so we want to we want to do all the enterprise stuff but we don't really have all the resources for that to do we are also very of control so we don't really like to have a project manager that tells us what to do so I think it was really for
me it was really interesting to see that we we've set up we've set up initiative calls every every two weeks we have an initiative phone call with the initiative leads and we brought on some project managers to help us and then we were at least my
experience may I might not talk for every initiative Lee but my experience is we were very resistant to actually listen to what the project mages were trying us to do like oh I don't have time for planning this out and I don't have time for first estimating
this and I don't have time for figuring out my dependencies and then I think as we went we understood that we are actually managing such a big project that we would need to do that and we were growing ourselves into actually accepting that that's what
we need to do and the other problem is we have our issue queue has the primary tool and I think the issue queue is very good to focus on what we do in the now so what we want to do now but it's not very good at figuring out why we do it what what's
the output that we are looking for and what is proceeding it was following it so putting it into context and and just and just making it work in the whole process so we have the issue queue as the primary tool and everything that we did in our initiatives
have alternate issue queues and trying to augment the issue queue with different tools to to help our initiatives grow and the reason we need to use the issue queue is because to get a cup that get a comment in Drupal core it's only going to happen if
it has a core issue and the reviewers for the core issue will only review it if it has discussion that proves that it was discussed and there were multiple options explored and the right option was was proven to work and they will only have discussion if you
post patches on the issue so we have the whole process map that from patch to commit that that will only work if we have an issue for it so we if we if we do it at other places then there's no visibility of what we are doing so we kind of are putting ourselves
in the issue queue and the whole process drives us to do that and the issue queue experience probably for us who work here every day is very cool because we have all this information of what's going on but somebody coming in and then they want to like
see what's going on in to play multilingual it's just a whole bunch of things that they can't make out it's like what the hell so this is the list of the sprint task for Drupal 8 multilingual that I took yesterday and it's just a whole
bunch of stuff so it's kind of hard to tell what's what's actually going on here and who's doing it and why they are doing it and there are if there are things marking stuff important by importance but then we have normal task that we are actively
working on its critical task so it's kind of hard to tell what's going on at all here but we do a lot we do AG meant the issue queue with a lot of tools so when I've asked for initiatives what do you do I've got a lot of a lot of good answers
so we'll walk through some of these and we'll see which one we're successful and we're only not so for planning we do a lot of real-time planning so we get together at Sprint's we have this drupalcon we have actually three days of sprinting
before the sessions and three days of sprinting after the sessions so we have six days in total by the side of the session days for sprinting which is a lot and we use white boards and we use we use all kinds of discussion tools there when we are not together
we use google hangouts in skype to just figure out stuff I think what we do usually approve job is making notes of what we do there and if we have meetings then set out goals of why we do the meeting at all and what we want to get out of it and then we have
some semi real-time solutions where we're like I've heard the view steam and the also the spark team that I'm working with and the entity team used Google Docs to map out different issues and problems and just break down things into smaller pieces
in the figure out priorities and we also use etherpad to make notes which is a real should very similar to Google Docs it's a real-time text editing thing if you use Google Docs documents as well and that's somewhat more useful because we are already
making notes what we don't do often is share those notes with people because they are very rough so it's not very accessible to those who are not at the meeting but at least for these we have notes and then we can refer back to them my gripe with etherpad
is I don't I lose etherpad URLs very quickly I don't have tools for saving either by you or else I should have so I often lose those notes we also have white net discussions on groups that duplin org which is which is more open to the community so
Google Docs and etherpad if you know there's a meeting and there's a link to the Google Doc you will go there and we'll be able to read them right but if you don't know you will not be included we also do wide open discussion some groups out
to put an org of course the tool is has so it's good because there's a lot of people seeing it it's not very good for us because it's very easy to go off topic and to go on branch discussions and all kinds of problems and we don't have
tools on groups at Oakland or to break out that discussions into smaller pieces so so that's what we found there as an issue and then we are trying to report what we what we planned right so often we write up our discussions from personal meetings and
Google Docs and we post them in groups of Dublin org or on Drupal planet or we push the list of issues into a meta issue or we person Greece's blog announcements for major things I think we should do a lot more of this and we also don't do a very good
job of referring back to our plans when we when we when we do stuff so we don't really put stuff into context of where we planned that at least my impression and then we have those plans sat down and we need to break them down and that's that's
where that's where the ish accuse come in pretty heavily so we use meta issues to track some of these plans which connect larger pieces into the actual issues that we want to work on and we also use them for reporting we post back updates to what's
happening the usual problem is there is not a lot of good meta information in most meta issues so it's just a list of a bunch of related issues and then you still need to figure out what it's what it means and why anybody did that and then we are very
good at handling handling the issues themselves so we made up a very elaborate system of tags and different different category systems for for maintaining our issues and we do manual parent sub and related issue management there is a Drupal 7 upgrade coming
up on drupal.org that includes more formal support for parents and sub issues and related issues but tagging is the is the non plus ultra of issue management and drupal org and I thought we are not doing an estimation obviously we can't really estimate
how long something will take because we don't know who's going to do it and we don't know who's going to argue about it for months so we can't really estimate in the sense of actual project estimation what we do instead is we are trying
to guide people on two issues that are likely fit fitting for them so what we do is we use tags like novice challenging medium and we and we do actual meta issues which are in itself complex so we try to indicate that the challenging level of issues and then
[ ... ]
Nota: se han omitido las otras 5.749 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.