Um, so, uh, Peter, Peter, Emily and Sriba, uh, Sriba, we cannot see you, but if you want to turn on your video. Um, well, I wanted to take some time with the three of you and really look at the, the topic of, of acquiring these works and get all your guys expertise sort of together and on a table and, and I'm also encouraging the audience if you want to ask questions around acquisition now is a good time. Um, but so before just sort of opening up that that the floor. So this this architectural model that that Emily also showed in her presentation and that we spoke about in the in the beginning. I remember that for me this was a really pivotal moment like this was some sort of epiphany where, you know, what I could feel there were parts shifting in my brain and opening up new new sections. Did did you guys have a similar experience working with 3D printed artworks. I don't know maybe Emily you want to start. I can, I can share my recollection of that, of that process so. So I remember, you know, we had been talking about this a bit in the museum and had visited some other print studios but I remember this, this was the first time we actually had a print made and when I went to the place that was going to print it. It was fascinating because it was the first time I was a client and as soon as I walked in the door I had to sign a non disclosure agreement. And I had asked for a tour and they had agreed but you know, weren't terribly interested, I think in what we were doing and as they were showing me around like everything was covered, you know, I had signed an idea but there's honestly nothing I could disclose because of the proprietary nature of all of this, and that was a real eye opening moment for me of, you know, going to other studios like more in an educational context or, you know with artists or makers. I love talking about it and this was just that remind or like, Oh yeah, this is a multi billion dollar industry, where a lot of the knowledge is proprietary and that that really changed my perception around approaching work and all the legal issues related to it. Should I go next. Yeah, I guess from like my and there is the hour back case study I think was the real, you know, little moment for myself and I think make it random as well I can still remember the conservation staff meeting where she was talking about it and I was like oh you know I'd be interested in getting involved with that knowing that you know print objects and things like that nature. And it was interesting because it was it was a unique example where I mean just talking about Emily experiences with the proprietary proprietary nature like this huge industry is Talba. It was the first time she had ever used the process and so and she's a very like open and very lovely person so she was a really great collaborator with us to kind of help us figure out things with this piece as we had questions coming up. And it really I think informed our practice and really made us aware of how it can enrich the collection. And I guess I'm speaking specifically about, you know, how I mentioned we had acquired works prior to this. There were three printed that I just basically ignored I was like these are objects. You know, that's the domain of the objects conservators, but now going through this whole hour back process or case study really revealed how we need to all be collaborating and you know get these, you know, printing files and how they what utility they can serve in document the kind of just sort of bring us together and working more collaboratively and more sort of like how we can all sort of team up in the care of these objects I think is really what is one of my biggest things that I came out of this specific instance this this case study. I mean, Riva, did you have a moment where you felt like, I don't know, some things was falling into place or something. Well, I, I would say that in my role I primarily work with a lot of objects and artworks that are two dimensional. So, well, there are two dimensional images or renderings of what could be three dimensional objects, but I am learning more about the use of 3D printed material. In artists objects and their artwork, and also in regards to the stewardship of museums and caring for these objects and really understanding, you know what the process will be into the future of how we can maintain or conserve these objects in the collection and, and sometimes it's really interesting to hear about the artist's well, it is very interesting to hear about the artist's process to because I think having conversations between museum and artists and creators it can really create more questions and just creating a new, new ideas around how we collect and how we conserve and how we preserve artwork objects so being a part of that process and a part of those conversations to really understand what it is what it means, what it looks like into the future, and possibly being being able to foresee into the future, of course we don't know, perhaps all the things that could come up, as far as technology goes into the next 30, 30, 40 years from now. But it is always very interesting conversation, always an ever great conversation. So, thank you. Meredith, Shraibh Nooyth asked in a text in the chat, how, what are, what are conservation considerations when acquiring, when we acquire works that deteriorate like how can we sort of reconcile with that. Maybe I want to sort of piggyback on that question, or as a follow or as a follow up question is, is reprinting even a viable conservation strategy. Who wants to go first on the easy question. We'll be talking and we'll see where that goes. So, I would say, I think of reprinting as just one tool in the toolkit. It's not, you know, it's certainly not the end all be all it's a rare thing for in in moving forward I think it'll be a rare thing but I think where it can be interesting is with these more iterative works, like for the architectural model that I did talk about it was designed to be made a different scales and that's a really interesting potential within the work where I think I would find it very sad for works like that if a museum just said no, the work has to exist only as these kind of sad little yellow bits of plastic and that's it. Like it's it's an expansive work in its conception. So I think it can be interesting in those cases that said it's a tool but it's not the only tool. I think we can have some great other tools that would be really helpful for caring for these works, including the basic stuff like working with an art shipping company to prevent the shipping damage that you know prompts some of this discussion, preventive care. You know those, those are great places to begin. I also had some interesting conversations where people asked about reprinting for things that kind of like fall in the normal domain of what a conservator does like some little parts have fallen off and someone thought maybe like oh does this need to be reprinted and we can, we can handle that kind of thing like we can put broken parts back on something. So, some of it's just interesting to see where people sense of what's possible with objects. So what do we do. I want to read actually this question again now that I've, now that I've talked a little while. So it's, it's, what should we do with things that are maybe more in the ephemeral range or realm that aren't expected to have infinite lifetimes. I would say this is not new territory, I think in, in contemporary art, or, yeah, in cultural heritage. And there are so many benefits to still acquiring works by, you know, for things that aren't expected to last one being like support of an artist, name recognition also funding, especially like in an artist emerging period of the career and just like a vote of confidence like a support for what the artist is doing. And I think that it's, I don't know, the classic example being Eva Hesse like you just needed to make the work that you needed to make and yes it didn't last or didn't last in the same way that it was when it was first made. But wouldn't change anything about a practice. And certainly wouldn't. Yeah, that's, that's a whole other other conversation but my point being like, there are real benefits for these works still being in a collection. They can still be accessed by researchers or scholars, even if not exhibited. And again the support of the artist is really important. So, that's where my mind is, what do what other folks think. So I think Emily, I mean, Emily is the object conservator so the better person to talk about sort of the preventative measures and protecting the objects themselves. But I guess just this whole idea of, you know, something that's going to have a finite lifetime. I just go back to things in terms of the pre acquisition conversation you know it's just being very upfront and just having these very frank conversations with the artist or creator and being like this thing's going to go away at some point, you know, especially this material that deteriorates so rapidly, or some of it does. And really just discussing that and just getting their thoughts on how they feel about, you know, should we reprint, you know, is this just the object sort of having those conversations, both the artists but also within your institution to see how everybody else, knows about that, while also taking the measures to sort of hedge against that and I'm looking at Mark Heller's question about, you know, Mary Oxman who prints and like acting and like how are we going to reprint that and it's going to be pretty hard. So I think we hedge where we get the files we try to document as much as we can about the process, knowing that it's going to be pretty impractical in this present moment for us to reprint but maybe you know in the future. It's going to be very common, you know, who knows what's going to happen in 20 or 30 years. So we just sort of hedge our bets in a way by trying to gather as much documentation as much sort of ancillary material around the object. You know through these conversations through like this is all like documentation but sort of metadata in a form to just help describe and sort of contextualize and then give you know our successors. I think there's a lot of tools to deal with it down the line with the technologies that we don't even know about that could potentially extend the life of these works. You know, just looking at, you know, if there is an agreement or some kind of agreement between the artist the artist estate and in the collecting body, you know, we can put language into our agreements that can speak directly to that process of conservation and in the event that materials start to deteriorate. This is how the museum can make reproductions of that material or be able to preserve the material or in some cases artists are like part of my work and I think Mary Oxman is a great example of this is that my work is supposed to deteriorate over time and we do not want to see it being kind of a reproducer or manufactured in a way to conserve it back to its original state so it really does, you know, depend on, of course the artists and what their intentions are with the work, but also getting with the artists living really having those that dialogue to understand how do you see the work into the future 100 years from now like how would you want this work to be preserved. Or maybe 10. Yes, or maybe 10 exactly because as we know technology is is a fast moving target. Yeah. Three but can I give you a follow up question does since so when the museum goes, you know, or is planning on reprinting an object that has been degraded and now the institution is planning to recreate the objects. And if there's if there hasn't been any sort of wording in in a contract. Do you advise, not officially, do you advise to, to put that in writing that that the museum is now undergoing a reprinting effort ahead of time. I mean it is always, you know, in my word as much as possible creating language around what we can see what what is foreseeable into the that we can can possibly draft an agreement around so these are the issues that we see. So how can we include language in an agreement that would cover any foreseeable issues around the preservation of this work so. And in some cases, in many cases, there is no agreement or, or the museum hasn't had an opportunity to talk directly to the artist because our artists has passed or for whatever reason is unavailable. And I think in those cases it's really. It's a dialogue that needs to happen internally and I know that many, many museums as a moment included we have, you know, a team media group of colleagues from throughout the different departments of the museum, of course curatorial exhibition covering technical media, we come together and we talk specifically about these matters, particularly where an artist may be unavailable to speak on their behalf. Hopefully there's a representative that we can work with to have more conversations about how how the museum can steward the work but I think it's a very it's a very interesting question. It comes up and and and how do we how do we work. How do we work these details out when we don't. Yeah, the information so yes as much as we can from a legal point of view we definitely try to include as much language agreement that can cover these bases. Thank you, I have. I'm just going to make one brief little plug regarding Mark's question about the nary oxman piece with the biodegradable materials just little plug for the exhibition in the spring there's very interesting update on how they're handling those things so this is a moment in the spring to see that And we're at the end of our time and I see an extremely interesting question in the Q&A from Tatiana Cole about looking at the reprinting of contemporary photographs, and maybe we can pick up that question later. Maybe, Peter, you've been asked the question in the Q&A can you give me a 30 second answer on how to catalog these objects when they come in with that on the digital, if you have digital files coming in if you have objects come in. If you reprint the object, how do you, how do you sort of bring that into a cataloging system. Yeah, to really quit make this super fast but the answer Tatiana's quickly. Yes 100% we look to other mediums so reprinting photographs film prints. I think just looking at sort of practice based decision making, I think really trying to inform looking to other disciplines about how they've handled it in the past to form this particular case study so yeah 100% looking to other disciplines and what they've done but in terms of the cataloging we went to it's alongside it so I gave the example of we have MoMA have these X components where there's one component for the object, another component that would be an X2 for the digital file and then if we were to reprint. It would be an X3 so it would sit alongside it and then what we would do is just tie the relationship together within our collection management database to be like this came from this, this is why we printed this and sort of just make those relationships within collection management software, basically utilizing whatever metadata fields are there to make those relationships, put all that context around it put in, you know, free text of just, you know, I Peter did this at this date with this vendor at you know, and just really build it out that way but it would get the catalog right alongside everything else. And then we would just, it would be evolving and its statuses would change just as the work, you know, sort of lives its life in the collection. Great, I would also add in media conservation or with media artworks in general we often have more than one master. So, this is not to go into more details but this is a place I think people can look on how these were solved for other artworks where there's more than one master. I went that way over time with this panel and we could have gone much longer. Thank you, all of you. Thank you, Sreba. Thank you, Peter. Thank you, Emily. This has been a pleasure seeing you all and speaking with you.


So thanks, everybody, for joining us. This is specifically to talk about staffing and capacity building, facing our specific challenge of talent starvation. So just to get a sense while we're resolving some technical, the standard technical issues, standard issue. How many people here are actually currently attempting to hire the majority of the room, in fact? Are there people here who are, this isn't a matchmaking question, looking for work? So there usually are a few people who show up also looking for work. Our hope is to make this presentation rather quick so that we can get into talking about specific use cases. But maybe we can start to get a little bit of a sense of kind of the specific need. How many people are hiring for very small shots, let's say five people or small, a few people? How many between, let's say, a break off of 30 down to five? And how many for larger than 30, anybody over, say, 200? All right, cool. There have definitely been some conversations with some very, very large shops. And I think that that's a different challenge. And we're very pleased to be talking about the smaller shops, I think, in this time around. So in any case, since we're in a little bit different situation, do you mind just kind of hitting the slides forward? Cool. And I can also, actually, I'll sit down next to you. We can make things easier like that. Is it all right? I assume it's all right. Everybody can see if we're sitting instead of standing. So in any case, I'm Kay Van Wolkenberg, principal of Oensourcing, which is a training company in Boston. And I've been doing Drupal since 2007. And prior to that, I was doing software development, mostly for the web, and also for exhibit displays since 1998, and a trainer since 1990. And I'm Jesse Day. And I've been working with Kay at Oensourcing. And I've been involved in Drupal since 2010. I'm a developer and a trainer. And prior to that, I worked as a teaching assistant and tutor. And so the education and training aspect of what you can do with Drupal is something that interests me a lot. Cool. And of course, there's a third personality who features prominently in our title. And that is Maslow. I'm sure everybody's very familiar with this psychologist. But just in case, because this concept is pretty key to what we're talking about, Maslow is famous for his hierarchy of needs. And his notion was that human beings are capable of accomplishing great things and having great satisfaction. But in order to experience these things that he actually termed as peak moments, you had to have a number of things in place that were basic requirements. And these range from very fundamental things, breathing, water through some still relatively concrete things to things like family, sexual intimacy all the way up to things that are quite hard to truly get concrete about in our heads, creativity, spontaneity, and things like that. So interestingly, the notion of Drupal is often also described in terms of a peak. But more often, that peak has kind of a treacherous side to it, where people picture it with piles of corpses accumulating at the bottom and things getting worse and worse for Drupal teams.  I don't know that that image of Drupal continues to be a particularly useful one for us to propagate in the community. I think that it was probably true, certainly leading up to 2007 from the war stories that I heard. Around 2007 when I started, Drupal 5 came out. And I got the sense that people felt that we were turning something of a corner. And I would say by now, it feels very much like we've turned a corner. And I think that that corner is that now we have a framework that we can rely on. There was a bit of a debate a couple of years ago. Is Drupal a CMS? Is Drupal a framework? And I think it's fair to say that it's both. And that framework basically means that we, as developers, can rely an awful lot on a structure provided by software and, importantly, a structure provided by the community that helps us avoid these harrowing experiences that people describe. And I imagine there are some people in the room who perhaps feel that this precipice is still very much a threat, still very much in place for what it's worth just to illustrate how many people, or maybe this isn't even a fair question, imagine how many people would raise their hands if we said how many people have actually stepped through the bootstrap process, for example. Very fundamental thing happens every time a page is loaded on Drupal, at least ostensibly. Step through the bootstrap process even for the most simple page. I can't imagine just in the conversation that I've had in the community, there being more than, say, maybe one or two. So maybe those brave souls would like to raise their hands. We rely on that, and we don't need to worry about it. And in fact, unless we've got some very dire testing need, it doesn't happen on a project. We don't step through the bootstrap process. So I know that there are people who do it, and that it's a useful thing to continue working on. But if we start talking about this hierarchy of needs, where can we actually start drawing a point at which people can feel successful? Back in 2007, this famous learning curve was put out. And it's certainly worth noting, I think the bottom of the screen might actually be cut off, but it's certainly worth noting that you did an awful lot of learning before you could work. In fact, only the very top two lines represent when people could theoretically be productive and work as a Drupal consultant or in a Drupal shop. And then the next step up was IMCHX or Unconed. So I think that that, we can all agree, has changed significantly. And the thing that we'd like to pause it today from personal experience, from having surveyed a number of shops in the Drupal community, and having trained new users, we can now say that you can successfully hire people who haven't even completed the bottom item on this and expect them to be productive within weeks. That this isn't, I can't quite scroll. Is there a scroll down so that we can get? So the bottom in any case is that you can install Drupal. And we can get into some very specific cases if that sounds a little too incredible for people. There have been some great successes with people coming up. All right, so what does it mean, this thing that I feel, I haven't heard a lot of confirmation elsewhere necessarily yet, but I feel pretty strongly that the fact that we have this framework provided by the community and provided by the software really does constitute a major advantage over at least a few years ago, now much of the functionality that we have access to and much of the functionality that goes into a large range of sites is actually plug and play. In fact, there's an entire class, group, professional niche in Drupal that works entirely on 100% plug and play technology. They click together websites. It's been the dream in Drupal for a long time. And there is a thriving group of developers who do that. Is it, were you able to pull up the Drupal Gardens? Show of faces. Yeah, cool, so we'll switch over. Do we have the URL as well to share? Yeah, sampler.drupalgardens.com. You can see some pretty impressive sites that have been clicked together. Now, this is worth bearing in mind because we think that this approach of focusing on click-together websites is a good starting point for new members of the community. This isn't a new idea that's been put around for quite a while. Is it easy to go back to the, cool, right? So that's the upside. You have all this functionality that's basically configuration. On the downside of this existence of a framework, this also means that you could look for people with web development experience that spans a decade, and they're still going to need training. And that's just the raw truth of it. And I'm sure a number of other Drupal shops here received quite a large range of projects that have come from talented PHP developers. And they're no longer viable as Drupal project. One example not too long ago, we received a project where a talented group of PHP developers had created some quite elegant code for including menus and had put them directly into Garland templates. Fortunately, that was a relatively simple fix. We started with a Zen-based theme and re-themed their site for them, and they were good to go. But while they had this situation, it of course meant that while with Drupal anyone who has permissions can change menu items, in that particular case only the developers could. And they had a bit of a blocker also when they wanted to do certain types of upgrades. So this very experienced team had taken that project down a somewhat unviable path. And I was expecting gasps from the awful scene that's depicted of people falling off the Matterhorn. In fact, the shocking thing here is anybody who's familiar with the doc route in Drupal.org. Some people are smiling, thank you. It's actually supposed to be kind of fun. So people who are familiar with the doc route in Drupal will recognize immediately that there are a couple of filenames in here that are very unfamiliar and probably mean that the team who worked on this site hacked core. If people aren't familiar with this term hacked core, it's a very bad thing that has horrible consequences, including the death of kittens. So this was a quick clue when this was actually part of a training project, the team that inherited this site found that they weren't successful in doing upgrades. So they felt they needed to learn more about Drupal in order to do a number of security updates that needed to happen in fairly short order. And every time they did it, the site fell apart. And so the pre-training review of what they had to work with, of course, revealed that this wasn't a Drupal challenge. We could still train on the items that they wanted to train on. But the real challenge was actually going to be discovering how core had been hacked and why, and then implementing the features that they had through these non-standard coding practices, through instead standard coding practices. So whether or not you buy the idea that starting with click through site building is actually useful for your shop, I can certainly tell you that those two instances I just cited, which are very fresh instances in our mind, would have been completely avoided, had those two groups spent time, perhaps on Drupal Gardens, for example, in a walled environment, figuring out how things happen in Drupal and not having that option of turning to code. One of the fun things about being involved with Drupal earlier than I was, from what I can tell, is there was a sense of adventure. And I think the early adopters of Drupal were real adventurers. And I think that when you're trying to hire for small shops, you continue to need a certain amount of that adventurousness, tempered with a sense of these paths have been well-carved, and it's best probably to pull out the roadmap and figure out how best to do them. So now here's the problem that goes along with it. The roadmap is not particularly well written out. And there's a ton of stuff you have to know in order to avoid this. So part of what we'd like to talk about today is the plan that we've hammered out and implemented and tested that has been working quite well for getting new people from outside the community up to speed in short order. And we'd also like to talk about some of the challenges around getting the existing developers that you have also to continue with their learning and growing their skill, especially with rather dramatic event coming up with, of course, the release of Drupal 8. So I wouldn't claim with Drupal 8 at the point it is in its development right now that we have a good, clear idea of exactly what kind of training has to take place. But I think that this format is flexible enough that there will be some applicable items. And we'd love to turn this into a conversation, like I said, in a pretty short order. So we're going to talk a little bit, like K was saying, talk a little bit about how you get people new to Drupal kind of up to speed. This right here is actually a instructions for climbing the Matterhorn. And it's really not that useful. But we see people trying to instruct new Drupal users in a similar way. We actually talked with several Drupal shops before doing this presentation and tried to get a feel of how they brought in new developers. And some of them said, well, yeah, we hired a front-end person and we expected that they were going to be able to learn the back end. But when pressed a little bit, what they told us was essentially, obviously they provided them support. But we gave them a book and we were kind of hopeful that they were going to figure it out. And in reality, that's just not, you really need to package your training in a more structured way. So definitely instructions, support, they're helpful. But they will be best when combined with a few other more structured items. So things like giving your new trainees simple tasks and tasks that require research and then always coming back and reviewing that. And so really, if we look at these, something like simple tasks, this can be something as simple as having them run security updates. You can have them run security updates a few times. They get into the flow of how they actually have to work with the team. And they kind of start to understand, they made during security updates understand what it is, why you don't hack core.  Of course, to go along with that, you can't let your high-rees get bored, of course. So tasks that require research are a great way to make sure that they're learning, that they're involved, that they're interested in the project. I know when I was just starting out, Kay gave me a task to build views with relationships. And at the time, that was a bit of a stretch. But it was something that I figured out. I'm sure Kay could have done it much quicker than I could have. But he let me work with it and roll with it. And in the end, it's a skill that I've learned and that Kay can now delegate. So it's always coming back to not only your developer becoming a better Drupalist, but you also being able to spend your time in a more productive manner. And of course, code review, if you can't, you need to be able to review what people are creating, review the functionality that they're making, and really just ensure that they are finding and creating functionality with best practices. So with that in mind, we have a bit of a sample learning path. And these are things that we think all Drupal, all people new to Drupal need to know. It's not necessarily just somebody that has no technical experience. Somebody who is a PHP developer coming into Drupal will need to know these things too. If a PHP developer doesn't understand the content system, the navigation system, how users work, then you're probably going to end up with someone who really doesn't understand Drupal. So just the configuration and building sites through the admin UI is a really important first step for bringing somebody onto your team. In addition, I know everybody here is interested in being involved in the Drupal community. And one of the reasons is that we can rely on each other for things like bug testing and just future-proofing our site and innovating. And if we don't teach our developers to rely on the community, then we're going to end up with a Drupal site that may or may not be, you know, be upgradeable in the future. I know one of the things that Kay and I talked about a lot and that we've already touched on a couple of times is upgrade paths. But, you know, if you're writing your code in a way that doesn't provide a reasonable upgrade path, you're going to be in trouble. And then, of course, the last thing, being extending Drupal to reuse content, just in general leveraging contributed modules, contributed themes. You know, Kay talked about the Garland theme being hacked earlier.  So it's not really a knock on them as developers. It's just bringing people into Drupal and showing them what they can do pretty much just through configuration. So we actually have a few sites that we know are built through configuration. This is from thetop.org. It is a site that was built by own sourcing.  And it was built completely through contributed modules. We can see content being reused. We can see users. We have users here being located on the map. And, you know, we have views. This is a, you know, to us very simple, but something that you would not want to attempt to write yourself. And, you know, so understanding the, understanding, leveraging what comes from the community is very important. We also, this is a site that was actually built by the AquaEU program. And I don't remember if Kay actually mentioned it or not. But he was the co-director of the AquaEU program, which was a program to train people from outside of Drupal and bring them into the AquaEU team. And they started on this site when they were one week into their training. They have varying amounts of technical expertise. But this site was built with contributed modules, CSS, and a little bit of jQuery. And I think it came out really well, you know, for any site, not just for a site built by people new to Drupal. So it's really just a testament to the things that you can do with Drupal. And yeah, so these are kind of the, a few of the things that I just talked about feed into these roles that we normally see in a Drupal team. And basically what I talked about were those first three roles, a site builder, a basic themeer, and a site architect. And those are the roles that we believe you can bring in Drupal people and, or sorry, bring in people from outside of the community and really have them contribute right away. Possibly a site architect needs some more experience. But between basic themeers and site builders, they'll be contributing to your Drupal projects within weeks. So there are a couple of other more advanced roles on here as well. And these, I don't know how many people are actually familiar with these roles, but they've been fairly well tested within the Drupal community. They're a little bit different from the way project teams were structured, you know, or probably continue to be structured without Drupal. But site builder, as Jesse was saying, focuses mainly on configuration. A basic themeer generally gets the work done using configuration, a little bit of CSS, in some cases HTML actually, relatively infrequently for really basic theming. And then the site architect helps determine how things are going to be built. That's quite common across different projects. Advanced themeer and module developer are probably self-explanatory enough. But so how do you deal with the more advanced roles in that case? Let's say that these people are already very familiar with the first three items that we've identified in our hierarchy of needs. And then they are like actually a lot of projects looking for the next level of skills. I'm imagining that if you have experienced folks on your team, they are already working with what Addison Berry likes to call altercoding. Oh, I'm sorry, I'm misattributing that. That's actually WebChick who was talking about altercoding and how at a certain point you get your site pretty much to where you want it to be and then for the last say 10% you actually need to make alterations to the code. And of course Drupal has quite a number of ways of overriding and altering things that doesn't end up changing core code and doesn't ruin your upgrade path. Pre-process functions and alter hooks are certainly two that are worth talking about. And then yet another level up, if you are not finding the types of modules that you need, then obviously somebody who can work with existing APIs to deal with high traffic situations, to deal with integrations and then some of the larger issues that, for example, the large-scale Drupal working group is working on. You know, these are things that are fairly logical to aspire to if your types of projects lead in that direction and helping to move your more advanced team members in those directions is certainly something we'd like to discuss as well. Of course at a certain point not all the necessary APIs have already been written or underway and not all of the problems that we as a Drupal community will face have been identified. So certainly talking about how one innovates even beyond that is worthwhile. All right. So what does it mean then to set out to actually hire for these roles? If we're going with the assumption that the talent that has, let's say, five, six years of Drupal experience is pretty scarce, pretty hard to find and we're going with this idea that actually we need to reach outside of our community in fact quite energetically and bring people in. Who are those people? What should we do? What kinds of projects can we put them on and how do we help them once we get them in so they're not facing that cliff that Jesse was talking about earlier with a couple of sparse instructions about hidden handles and a ledge you can stand on. One of the important things is to recognize that probably some part of all of your projects actually has a good fit for junior developers. Let's just refer to them for now as junior developers, people who are coming in from outside of the Drupal community. So here are some earmarks of a project. They have a clearly defined engineering task and what we mean by that is it's appropriate to get them involved once they can basically take... How many people here actually use JIRA or some similar tasking software? So a good number of people actually use JIRA. The notion is that once things get into JIRA generally the best practice is that they are actionable tasks that it's no longer at the point of discovering what for example a user story is going to be. We have a user story and we know that we have some tasks to break out to complete those. That's a very different situation from saying we have this audience and we have this message and how are we going to put those two together. So clearly defined engineering tasks broken out into actual actionable tasks and the opportunity to have the learner participate in the team without actually being part of the velocity to deliver that project. So in other words they're taking some of the attention away from the people who are giving them assistance but they're also putting their effort in to relieve some of the tasks. Ideally those things should balance out obviously at the very beginning they're probably going to be needing more attention than they're giving back and toward the end they're going to surpass that but ultimately on a week by week basis you should be able to set things up to balance those out. If you've got such an advanced project that that balance isn't conceivable it's probably not a good fit for someone coming in from the outside. Potentially. That seems to be a real minority of cases. And then team member that actually is a bit cryptic. The opportunity for the learner actually to become a team member is another good sign of a project characteristic. Now in some cases you can't actually involve them in these projects for let's say a couple of weeks to three weeks. Well they get used to the team, used to the tools and used to some of the basic concepts of Drupal and it's certainly reasonable to look two or three weeks out to figure out what is going to be coming up for these people. So what are some of the characteristics that make for good learners? In the survey and I was actually as part of the project, the pilot for AquaEU I was part of the hiring process as well and the characteristics that we identified ended up being quite true through that project. The first thing that seemed the first extinguisher seems to be is the candidate actually a good cultural fit and the culture of your company obviously can be defined in a million different ways but making sure that there is an opportunity for some chemistry for positive experiences in both directions that seemed to be almost as important as any kind of technical experience they were bringing with them. Self-directed learners that the person actually is able to let's say even demonstrate that they've taught themselves a number of things. We're not going to turn them loose entirely on their own but this ability to identify what they need to learn, what they want to learn and then pursue it and then find and use the resources that they need. This is probably the thing that most distinguishes this approach to training to the typical thing where you call a training company up and you say I want two weeks of training from my staff because at that point the training company will come to your office with a lesson after lesson planned out and the time filled up with people sitting in a group like this listening. So this is a very very different approach where you're actually asking people to take responsibility for the things that they are going to learn for the things that you need them to learn and that they want to learn. They need to be self-directed learners. And then they also, and this is perhaps the thing that tempers the self-directed learner part it's good to get indications that they actually know when they've hit a blocker and they can ask for help so that they can take, let's say, they can consider whether a problem is challenging or relatively minor. For a minor one they spend 15 minutes looking around and try to figure out what's going to be a fruitful path and then they go and ask someone for a little bit of a redirect and for a more challenging one maybe they spend half a day but they certainly don't spend, say, three days on a problem that they could have gotten good direction on. And then the final item is that they're responsive to coaching and I think that when you're interviewing people you can get a pretty good sense of these four items and they tended to be quite good guides and we can get into in the discussion some of the specific examples that we have. So once you've got a good project, at least on the horizon and a good crop of pyres, then what do you do with them? Well, obviously they're going to need some of the instruction Jesse broke out the four learning modes, they're going to need some of the instruction. If you haven't used Git before, you can give them some pretty simple instruction. I think we came up with six Git commands that anybody can learn in a very short session and then they can start implementing on these repetitive tasks that Jesse was describing. So they've acquired a little bit of information and they do a whole bunch of things. Those specific things may just be fairly rote but that kind of rhythm of using Git, working with the team, understanding what the tickets are about, responding on tickets, getting them into that flow, give them a bunch of attainable tasks that they can do that on and have a mentor who's actually ready to pick what those tasks are in the project, assign them, serve to get them unblocked and review their work as they're going along. So identifying people within your team who are able to communicate that way, who are able to identify tasks and assign them appropriately that's not tended to be a big challenge for development teams. They generally have people who are able to do that who also have experience with the types of tasks that need to be done. So identifying those mentors and pairing them with learners on the AquaEU project. We did it relatively arbitrarily. We didn't spend a lot of time thinking about which mentor was going to be paired with which of the eight people who would basically meet for 15 minutes, walk out with a mentor pairing and for the most part they went quite well. There's a lot of will on either side to make the pairing work. So true both for new people coming in from outside of the community and for people within your team, the community itself actually provides a fair number of opportunities for mentorship. I don't know how many people attended Gabor Hochi's session on contributing to core, but he talks a fair amount about good ways of learning through getting involved in the issue queue and providing value to someone, a core maintainer, in his specific discussion, providing value by being able to get tasks done at the same time you're receiving value from one of the top minds in Drupal or the other people who are assembled around this at least, sharing their thoughts on the best solutions on the code that you've submitted and things like that. Obviously learning opportunities like conferences and meetups are really big. I think conferences are probably one of the best ways for sharing information about best practices. So I think that's a great investment, especially in your more senior people to send them to Drupal Cons and Drupal Cams. Hosting them in your office is a great way of drawing potential talent and giving to the community. So there are quite a number of ways. We also list a few URLs, Drupaladder.org, great learning resource that Jesse and I have both been involved with and the core mentoring hours and of course the Drupal 8 community initiatives. So these slides have all been saved. The URLs are there on the node for the session. So if you don't mind, it'd be great to have your feedback. We've given a shortened URL here, but it's basically going back to the session node and please go and let us know what you think. But very importantly at this point, like I said, we wanted to keep this short so that we could get into more specific stuff. So we've got about 20 minutes. And please use the microphone. These are actually being reported, so it's great to share that with a remote audience as well. We've had a slide about making other developers issue queues, introducing, that's really great to do that. You cannot force them to do what I thought was an exception. So, you know, that's a great question that comes up pretty often. How do you motivate people? One of the things that we didn't talk quite as much about and I had actually meant to, but we were, I think, pushing a little bit of time, was one of the tools that we use is a learning plan, an individualized learning plan. And usually that's administered by either someone who's very senior in your firm or by somebody who's outside your firm. And that learning plan can be as loose as, wow, I'd really like to know more about some, you know, relatively like a year out type goal. I'd really like to stretch myself about Backbone.js or about, you know, any number of exciting things that are happening in the community. If they're not motivated actually to have those types of goals, perhaps, you know, setting shorter goals and trying to cultivate that motivation would be a good part-way step. But just to, let's just assume that whether they're motivated because their performance bonuses are tied to them actually acquiring that information or they're just hungry for knowledge, that tends to be the case a lot I think in the community at large, I think that that starts to provide, I think often motivation is less about the impulse or will of the person and often it's actually more about achievability, actually seeing steps for getting to a particular spot and seeing the excitement that happens, whether it's a bonus check or actually having skills that are exciting to them. You know, laying out these steps, working out with these steps are going to be how they're going to be enabled and removing blockers I think is the main way. You know, maybe it's my infectious enthusiasm. I've talked to a lot of people who don't feel motivated and by the end of the conversation they're generally talking about what's going to be exciting to them. Does that touch on your question or did you just skirt it? Yes. Do they like where they are? Yes, and then that becomes a hurdle for your company. Is there an incentive? Is there enough reason to move out of a place that might be comfortable? Is that part of the problem or do you think that the problem lies elsewhere? Two types of people. One actually making one. Yes, I think that that individual coaching that has been the thing that the tool that we pulled out of the toolbox in the past in those situations and the individual coaching when it's me who's doing it basically the question that I'm asking. I'm asking all kinds of things around interest and activities waiting to see some kind of spark. So a recent conversation that I had was with someone who was quite excited by the English language and by writing and by finding new ways of communicating with people. And so moving tasks that that person had available in that direction actually ended up being the main motivator and led to a place for room for growth. So I think it's that conversation finding out why that person is there. If it's true contentment then it's probably awfully hard to find an incentive not to stay there. But if there's something that is like a better thing that we can reach for. I'm still not sure that I'm satisfying your question but I'm happy to talk to you more about it afterward. I mean it's certainly something that we've come across. Yeah, another question back. Would you mind using the mic just so that people can know? Oh, it's not working? How about if we pass this around then? Is that better? Yeah, I really enjoyed the presentation and already kind of doing a lot of that in our recruiting. But on a completely different note what do you think Drupal 8 and the symphony stuff is going to have an impact on everything you've just talked about? So it sounds like we've already said a fair amount that was obvious. So unfortunately with that still all unfolding I think it's a little hard to say anything too concrete. One of the plans that we have is actually around local meetup and actually finding people in the community who are interested in first cracking what this can mean for us. Obviously there are things already available. We can already work with the symphony framework and Drupal 8. I haven't confirmed this personally but I believe that there have been recent releases and I'm sure there are people in the room who can actually confirm this. Recent releases that have components of symphony already integrated. Is anybody able to confirm that? So if that's the case and I believe it is then you can already start. One good resource for that is actually the Drupal Ladder. Drupal Ladder.org. Install Drupal 8. Start looking at the issue queues. It will give a very good sense of where things stand with integration what challenges are coming up on the one hand. On the other hand it will help start getting insights into what it's really going to mean to adopt symphony. So we'll continue to work on that question and that's the first direction that we plan on taking. Well first two directions. I really enjoyed your talk and appreciated a lot of the specifics of different approaches you can take to bringing in people who are not necessarily Drupal. One thing you didn't mention though, you mentioned training but kind of you bring in a trainer and they're going to sort of do this very generic approach but there is also the other option of there are trainers, I'm one of them, K and I talked in Chicago a lot about this, who will come in and do custom training to projects. So for example, especially if you're a small company and your existing developers really don't have the time to do this mentorship but you need to bring on new people, you can find trainers who will sort of work with you to provide that customized training, that kind of mentorship even if you don't personally have, your existing team doesn't have that time. But other than that, I have really excellent ideas. Point taken. Boy, that speaker must be dangerous. Okay, let's try from over here. I just want to ask, it's really to the floor, there's so many people here who are recruiting like we are. Have you all given up on local recruiting? Are you looking globally now? And if so, what sort of challenges when talking about mentoring do you get when you've got the team that are not in the same place? I suppose it's not really a specific question. Is anyone experiencing that? Well, and I wonder if it's, is that by a raise of hand? I imagine that a lot of people are feeling frustrated. I wonder if in part, if we can cobble another kind of raise your hand type question, does anybody suspect that the requirements perhaps in the ads that are going out in the local area seem like a barrier? I mean, we keep seeing these, the inspiration was Jesse saying, look at these, look at this long list of ads and people are looking for the entire lamp stack. You know, we want you to have it all. And C sharp.  So, several people said, yeah, they think that that's part of it. So, the response for those who couldn't hear it, if I can paraphrase, the response was like IBM. IBM hires saying, we don't care what you know, we'll teach you what you need to know. Yeah, the motivation to grow as opposed to the money is really where the solution lies, hiring the people who are motivated to grow. Those who are motivated by the, oh, thank you. This feeds back into your first slide, which you just touched on and then moved on with actual sort of training and so on. But you're looking for people who are motivated by the top of the pyramid, not the middle or the bottom. Sure. It doesn't really matter what their skills are, what you're looking for other people who are motivated by self-actualization. Thanks for bringing that back around. Yeah, and to help the lady a little bit, I will say that the training of new people in your company should be a process on the long term and to solve the time problem for the older people through the company that might become mentors and help others becomes also a project management-related issue. So you should include this time in their time and give them a free window every day so they can have time to take care for those new people. So it becomes part of the project shadow, the project budget and everything else. So they create this free time for them to help others and train others. Yeah, that's a good point. And you recreate in a company, it's new. It's new there. He has many times to adapt. He needs time to learn new things. So because he needs a time, we have to take that time from others' time and give it to him to help. Yeah, I think that's a point worth emphasizing. It was really gratifying when working with the Aquia team that basically everybody in the Aquia office recognized that helping the new folks get up to speed was going to solve problems for them down the road. And I think the culture was ready and was geared in that direction. And the project management load that you're talking about, there were a couple of points. Perhaps we should break those out after so that people who want to go off to beer can do that. But there were a couple of key points where the project management load was particularly heavy to prepare for integrating people into the team and giving them real life tasks. And then after that beginning point, then the project management side of things was a bit more distributed, mostly by relying on mentors and by relying on people who owned a set of tasks and could involve the person who was learning in that set of tasks. So they still needed a little extra time. So that was balanced out by being able to hand things off. Drupal is famous for being self-organizing, so it's cool that Mike gets past. Something like Elance or something similar to that, ODesk. I personally don't have a specific recommendation. We've been focusing on getting talent and growing it, so we haven't been quite as focused on... I mean, Drupal Meetups, certainly, without a question, are great for building that kind of Rolodex. I don't know if you're talking about a larger scale than that. And then just working on projects, collaborating with other companies has led to us having resources beyond just the ones that we're growing. I don't know if that helps at all, but it's really been... For us, it's been Rolodex-driven. Does anybody else have a resource that they use? One thing I would say with that is some of the same sort of resources you would use outside of Drupal for looking for that kind of help, like Craigslist and the various... I can't remember the names of them right now, but the various job posting sites that are generalized. But one of the things you want to do there, going back to the point we just had a little bit ago, is you want to make sure that your advertisements are asking for what you actually need in a Drupal. One of the problems that we have is particularly companies who don't know anything about Drupal but want to hire Drupalers, they're asking for the wrong things. What they need is a site builder, someone who can click through and build a site, but they're asking for a module developer by saying, we need a Drupal developer who has amazing PHP skills. And that just frustrates everybody. So one of the things that's important, if you're looking for experience to Drupalers, is ask for what you actually need in the terms that are familiar to Drupal people so that they'll recognize, oh, they're not really asking for a module developer, they just need a site builder, or they need a themeer, because that will really help you connect to the people you're actually trying to hire. Yeah, that's a good point. I think we have the room for about three more minutes, so that's probably two questions worth.