 So, welcome everybody. Thank you so much for making the time to come to our session today. Today we're going to be talking about this idea of Unconsortium, which is what we hope is going to be the next phase of collaboration in higher education. I'm Zach Chandler. I work at Stanford University and with me today is Brian Wood from UC Berkeley and Sean DeArmond from UC Davis. So some of you in the audience may have heard me talk about this before, but I'm really excited to tell you that today we're going to be unveiling something at DrupalCon and it's not just an idea anymore. So from, you know, this was born at Bad Camp and we connected with colleagues on the East Coast in New York City at Nice Camp and we're really excited to share our progress with you because for those of you who connected with us early on, we've actually been working on this since then. So just to lay out the agenda for our presentation today, I'm going to start out by stating the problem, you know, the thing that we're trying to tackle. Then we're going to dive into some real-life use cases. We're going to have a particular proposal for you or a set of proposals, but we're really looking for feedback. We want this to be engaging and we're looking for ideas from everybody. We're not claiming that we have all the answers, so that's why we're calling them proposals. We are going to be showing you a new website. We're going to do a live demo and we're going to share with you some of our code projects. And lastly, if we have time, I don't want to cut short the QA period, but if we have time, and I think we will examine some of what are the known challenges to the approach that we're sharing. And immediately after this session, there is going to be a birds of a feather for higher education broadly. We can dive into the topics we bring up today, but the real purpose of this bot is just to get everybody who works in higher ed and Drupal together in the same room so we can get to know each other and find out what our interests are and have a plan for the rest of the week and hopefully other things will spin off of that. That is in room A107. You can check the bot boards and it starts at 3.15. So there is something that was bothering us. And so we have, this is what started this initiative. And the problem is essentially that we are all laboring in isolation on our various campuses and we keep solving for the same use cases over and over again. And we're not sharing code in any meaningful way with each other. Some of us connect up to Drupal.org, but there isn't a true professional network and community of practice in higher education. This is really counter to how academic communities work where we really want to be standing on the shoulders of our peers instead of reinventing the wheel time and again. And can you imagine what it would look like if the scientific community acted like this instead of peer review? Again, so in the next few slides I will be exploring the problem space. Any good project manager is going to tell you that before you embark on something new, you should take a look at what exists for whether it succeeded and what's available. So we all do that in the Drupal contrib space, but how many of us have the ability to check with colleagues at other universities? This is, there's currently nowhere to go for this. And this is, there's a lot of, a lot of unrecorded work happening. Some of the things that we're going to have to get over, the not invented here syndrome. So we have a tendency to only trust code that we've developed in house. And there may also be this, you know, some amount of reputation that we feel is at stake. You know, maybe at MIT they don't want to use a feature built by Harvard or whatever. This is something that just gets in the way and we need to get over this problem and undo this culture on purpose. Another thing I would like to talk about is this notion of peers gets in the way. So, you know, we compete for admissions and things like this and we're actually required for accreditation to state what our peers, who our peers are, peer institutions and who our aspirational peers are. And I don't think this has any place for an open source software development community because we straddle both worlds. So in an open source it's not just your imagined peer institutions that matter. A single talented developer can change everything. And these people work in all sorts of places. So we need to think bigger than our normal networks. Another problem, and I heard Ezra G talking about this just yesterday, that the perfect is the enemy of the good. There's always this tendency to wait for something to be a stable 1.0 release. We're almost there but we're just not quite ready to share it. And this is something that we need to actively work against. If we released only perfect stable projects, you know, we might have two features in our whole catalog. Instead, I think what we should be striving for is hundreds of imperfect beta and alpha releases. So at elite institutions we have this culture of exceptionalism and there's a lot of congratulating ourselves. But really we should be focusing on the fact that this is use case driven work. Drupal is a content modeling system. And it should be driven by user-centered design and use cases. We share the same use cases. So we're in the same system. Many times we're using the same methodology, features-based development just being one example. We should be sharing with each other. And I just wanted to challenge you to think about this. You know, imagine what it would look like if we all shared with each other the projects, whether we think they're ready or not. So that's the problem space and now we're gonna take a look at some actual use cases. Thanks, Zach. So the stuff that Zach's talking about is the stuff that we've been mulling around for the last, I don't know what, a year and a half or something like that. We've been meeting regularly and talking about this. What I want to show you now is kind of what we've been doing, some real life stuff that we've been doing to try to address some of this stuff. And what I want to get out of this is something real, at least something like something real that we can take away from here, that we can take away, that you can take away. And how can this really help us all? And so this is the stuff that we've been doing just in our little tight-knit group here. So who knows about features? Who uses features as part of their development? Yes. Okay, well, since a non-zero number of you kept your hands down, let me just nut shell inside of a nut shell version of what the features module does. All that clickity-click stuff that you do in Drupal to set up content types and views and all that kind of stuff. You can use the features module, which is a Drupal module, it's on Drupal.org, and it allows you to package all that clickity-click stuff that you've done into a particular use case. You select what you want to, what was part of your use case and export that into code. So it saves your configuration as a module. Technically, it is a module that spits out. And there's a few really great benefits to that. One, it can be saved in version control. You can revert it back to a known state. So if you go in and change your view and you totally bork something up, you can say, oh, I'm going to revert that, and it goes back. But most importantly, it means we can share it. So once you have a module, once you have a bundle of code, you can just put it on GitHub or Drupal.org or, for God's sakes, email it, and you can share it with other people. And so that's what I want to talk about here. We'll talk a little bit more about features later too. And I also wanted to make it clear that we're not, we're going to talk about features here, but that's not the main focus of what we're going to try to share here. It's not necessarily the be all end all, and who knows what's going to happen in the future. So we're going to talk about features a lot, but we're going to consider modules or install profiles, Drushmake files or anything else that you want to share as far as code, but also ideas, resources, research, design documents, all that kind of stuff is very, very important. And I'm going to tell you a couple stories about what we've been doing. So at UC Davis, I was visited by our manager of client services, and she says, so, Sean, as part of our ITIL adoption, the ITIL adoption, we need to build a IT service catalog. Anybody, does that ring a bell to anybody? Yeah, I thought so. So, and so, I said, okay, well, we can, we can do that as she described the requirements. I said, oh, Drupal, totally. That's no problem, right? And so we got wireframes built and kind of design documents and stuff like that. She did a lot of research about other IT service catalogs. And at one point, I mentioned to my colleague Zach here that we were going to do this, and he says, you know, we have a service catalog, and we actually already knew that, but we're working on rebuilding it. Oh, okay, cool. So before long, Zach introduced me to Dave Rehm at Stanford, and we were having Google Hangout meetings. We were sharing our research. We were sharing our user stories, design documents, wireframes, and as you can see, there's not much difference here between these two. But what's going to come out of this is not necessarily the same feature. What we decided not to do, because our scope was different between the two, so we did all this collaboration and sharing, but we each going to build our own features. So what does that mean for you guys? It means that now you have two different scopes of two different features for IT service catalog that you might be able to use. And one will end up rising to the top, and it'll probably be Stanford because they're best at everything. But the purpose of this is to have lots of different ways of doing things out there. Story number two is UC Davis uses CAS and LDAP, and I imagine this is a pretty similar case for a lot of you out there. So I built a feature that saved the UC Davis CAS settings and LDAP server settings and basic configuration along with that, as well as kind of a module, a feature that created user fields. And as someone logs in with CAS, it pulls from LDAP and saves that information into user fields. Not all that complex, but still very useful. And we're now implementing that on a number of sites throughout our campus. So I mentioned this to my colleague Brian here, and it turns out UC Berkeley also uses CAS and LDAP. So he says, let me see your feature. I send it off to him. Well, if you haven't noticed, there's one problem with that is that UC Berkeley doesn't care about the UC Davis servers. So my module or my feature right away isn't going to do them a whole lot of good. But the structure is mostly there. So he was able to take it, change a bunch of the settings to make it fit his particular use of the UC Davis. And he's going to talk a little bit right now about what he did with it. What I wanted to mention here, too, is this is, we want to really promote the idea of messy, hasty pluralism, and that's kind of one of our mantras, and that means it goes along with what Zach said about release early and release often. When I built this, I did not necessarily consider the fact that other people outside of UC Davis might actually want to use it. So he was able to take this as somebody else. And what would this take to make this feature work for him? Brian? Yeah, so what I got from Sean was not actually that messy. So I couldn't really rip it apart and be like, Yeah, you know, Davis, they kind of know what they're doing. But it was a great opportunity to put on the hat of somebody who hadn't been messing around with the CAS module, the LDAP module, the CAS attributes module, all these cool things that Sean leveraged in order to get LDAP data into a Drupal user entity. So I approached the task saying to myself, OK, what does this look like if I just kind of gingerly move forward and don't leverage my past experience? And what I found were a couple of obstacles, well, three, exactly. And these things were interesting to look at. And I have a couple of ideas about how to make them better. So out of the messiness with small iterations, like this mini case study, we can kind of look at, Okay, what are some small steps we can take forward? So the first problem I ran into trying to install Sean's feature was that was a bit of a shortcoming of the features module, which is features will export certain dependencies for you, like other modules on your site. But third party libraries are a little bit beyond what it does. So Sean's team probably never saw the error that's on the screen, because they're always enabling this feature on a UC Davis site that would have PHP CAS in the sites all libraries or wherever they decide to put it. But if I'm just a user who's maybe installing this for the first time, I might be a little bit blocked by this this error message. So a way we can avoid this a simple way is when we build our feature and we say, Hey, you know, this would be a cool thing to share with other people. Let's try installing it on a vanilla Drupal seven and and see what happens and tease out a couple of these potential roadblocks. And then the next thing that occurred to me is a graceful solution to this problem, which is that when you need to bundle up more than what features can give you, Drush make will provide for that. And a lot of people think of Drush make in terms of building an entire Drupal site or an entire Drupal distribution. Yes, it does do that very well. But there's also a very powerful switch to it called no core, which will allow you to build just a subset of of data. And so the the other thing is that we might not always have the luxury of time to do a nice Drush make file. And so we can with using focused yet effective and brief documentation, I think we can provide the key pieces of information that people would need to use this. And I think it would be great if we could all adopt an internal slash external documentation style. A lot of us have that sort of feeling like, Well, our team knows that I don't need to write that down. But a couple of quick bullet points can actually serve my team really well too when I have turnover, new people coming in somebody fill in the gap for somebody else. And beyond that it really empowers the community. And then in thinking about read means and how they can be more effective or whatever documentation you provide. Obviously links to existing documentation, but a really great win, especially in terms of a feature is maybe just pasting in the Drupal path to the admin pages that have the variables that you have set so that somebody who doesn't know this code can quickly come in there and be like, Okay, let me go look at that admin form. And there I might see a bunch of UC Davis, all that server said, and I might need to change those to Berkeley. And then beyond that we can provide some helpful steps. A lot of people might be doing all their Drupal administration via the web UI. So we might give them a quick link to Drupal.org and enabling and disabling modules. And then a couple of bullets like you should do things in this order. We might also tell them, Hey, if you enable this feature using Drush, Drush is going to automatically download everything you want for you and save you a bunch of time and maybe give them a sample Drush command. And if we've gone that extra mile to provide our Drush make, just pasting in the Drush make command that you use to build it with maybe another bullet or two, you know, this is what we do could go pretty far to help someone along being like, Oh, maybe I should check out this tool. So what's the next step? I've modified this feature that I got from UC Davis. I've got it working at Berkeley. Now I want to reuse it at Berkeley. I want to make it reusable here. Well, this is kind of where I think we want to create some discussion and get input from the community because there's ways you can re export features. And there are issues around really making a feature your own that that feature I got from Davis is going to have UCD underscore off in its name spacing. That means its code has functions and field names that have that. And that's going to if it's going to at least create a little confusion at Berkeley, and then it potentially could create a conflict depending on what other modules I have installed on my site. And then one step beyond that, what if I say, you know, this guy, Sean really knows what he's doing. And he and when he upgrades his code, I would like to get his upgraded code like three months, six months from now and quickly apply my settings to it and just kind of track what he's doing because I really trust what he's doing. There's there are some strategies for doing that in the in the larger community. And I think we could focus on some definitions of those strategies in this community. Okay, so we've talked a little bit about the problem space and showed you some of the particular use cases that we've been working on. Now it's time for us to share some of our ideas with you and see what bounces back at us. So unconsortium, this is this is part of our big plan here. But what is an unconsortium exactly? So as we're imagining it in unconsortium is a professional network of individuals, not institutions. So when institutions are members of things, people start behaving like institutions. So there you may have the brand of your university at stake in some sort of perceived way. But people are more interesting and they're mobile. So sitting in the front row is Costa Tostiari. So Costa was at the University of Kentucky at their iSchool teaching semester-long courses in Drupal to undergraduates at the School of Information. That's an unusual thing and that's that's valuable to Drupal. And we want to know about people like that. So what if the University of Kentucky joined a consortium? Well, shortly thereafter, I posted a move to Colorado Boulder. And now he's part of the CU team. So it kind of wouldn't have made sense for Kentucky anymore necessarily in the same way because it was really about an individual. So this is part of the way that we're defining ourselves and the way that we're imagining interacting with people and groups. So we're going to propose that we establish a community of practice. Now that means something really specific. So there's community of practice, capital C, capital P is really a variety of learning community focused on practical application of technique. People who teach each other, you know, actively engage in a community. And this is one of the things that people realize that this really got started in the 90s. Looking at corporations and how they work and how people learn there is that people teach each other outside of a formal curriculum. And I think that this is going to be this whole thing that we're talking about doing with features and how atomic to make them and what should be in a feature and what shouldn't. This is something that we're going to learn by doing. We know that we don't have all of the answers, but I think that a lot of the answers might be in this room. So we also want to be entrepreneurial. We want to fail faster and succeed sooner. So we're going to try lots of things. We looked at F servers. We looked at adding RSS feeds to F servers and then parsing those and we're going to show you something completely new today. But it's all about learning from failures as much as from successes. Something else that we're proposing is that I imagine that the types of features that we're all going to be making because we share use cases are going to follow a sort of bell curve distribution, the middle of which the preponderance of these features are going to be things like courses, events, news, people, bibliography. I think a lot of these things are going to be shared, but we're going to, there's going to be some very, very interesting outliers towards the ends of the distribution and specifically I'm thinking about things like the digital humanities community and the kinds of ways that they might be leveraging features and techniques like this. Is John Keely here? Hey John. So John Keely is from the University of California San Francisco and there they've used, so he's partnered with faculty teaching faculty and research faculty to create a Drupal instance that encodes for genomics. So they have common Drupal tools that is sort of like unimpressive necessarily to a Drupal developer, but apply to a domain it becomes really interesting. So they have these long gene sequences and I think RDF extensions and suddenly you have yourself a really viable academic research tool. So it's those outliers down at the edges that I think are going to surprise us. And the other thing that we're proposing is to think bigger than we normally do. So this initiative is already going to happen. It's already happening in California. I mean, if you know Berkeley and Stanford can work together on something then you know probably the rest of us can get along too. But you know so why wouldn't we expand it? You know why would we why would we focus on a small problem, a locality, when we could try to solve a much bigger one? So the internet's have already solved the whole scale and geography limitations. So why would we be regional anymore? So I'm going to resist the urge to do a drum roll on so we have a website. So the the edu Drupal Unconsortium now has a website which is currently running on Pantheon. Thank you very much Pantheon. And in it we are going to try to do well four things at least. Provide a catalog of features that have been made at more than one place. Hopefully all the places. We are going to have a place for people to network and connect. We're going to show community members and their institutional affiliation. We will be blogging you know as a way to foment this community of practice and share you know things that we have tried and things that tried and haven't worked or things that are working. And lastly we also have a proof of concept tool that is Brian Woods work that we're going to show you a little bit of perhaps. So and we're open for membership right now. So if you go to this URL you can create an account and join us. Yeah right now. And I'll turn it over to Brian. So what Zach was talking about the end consortium how it's member driven not institution driven notice we have a page for members not a page for institutions. And already this slide is outdated because Zach just asked a bunch of people last night to go and create accounts so you'll see there's a lot more people on there than just this. We do urge you to fill out your fill out your profile you know institution also interests. There's a field for your Drupal.org user page the URL for that. If you have that picture things always look better if they have your mug shot on there I think so get that in there. The other thing that you'll find in there and I'm going to mention this now just so it doesn't throw you off is that there's a checkbox that says I work for a higher education institution and that checkbox is required for now I'll say for now so we're really trying to focus on people who are at higher education institutions right now. We want to be able to expand that to other companies and service providers that are very interested in the higher education space. We will have a place for you or we will have a place for you right now we just want to focus on the higher ed folks though so you'll see that. Also there's another checkbox that we're not going to display on the site anywhere but we're interested in finding out and connecting with you further. There's a checkbox for I have code to share so if you have code to share check the I have code to share box so that we can get in touch with you and try to figure out where you're sharing it and how we can be able to figure out how to bring that in on the site. But we don't have enough in there we need more so go ahead and go ahead and do that as soon as you can. So I'm going to turn this over to Brian who's going to show you a pretty wicked tool here. Do we still have display on the screen. I can't see what's going on up there. I just switched it. So one of the premises of this this grassroots movement is your use case is not unique and somebody's probably already created something that has covers a fair bit of your requirements and you should go find it before you reinvent the wheel. So that's a nice idea. Where am I going to go find my code by my peers at other institutions. Well we've been putting some thought into this and one of the first places you might go look for code would be on Drupal dot org and Drupal dot org now has a brand new education category under download and extend and you will find 20 to 30 modules install profiles etc there. So that's that's one small step. You know if we try and do searches. If I tried to do a search I didn't know Sean and I wanted to find his feature you know. I might have had some problems getting to him via Google. I could have tried some more focused searches of GitHub and Bit Bucket. But how can we make this better. We thought about the fact that a lot of what we want to do has to do with features and there is the F server project. The F server is a way of broadcasting to the community the existence of your feature or module and it can provide feeds which could be aggregated centrally. But as I thought about it more I feel like F server is a bit of a barrier to participation. First of all you have to install the thing and then you've got another site to maintain and most of us don't need extra sites. And then the project itself perhaps has an uncertain future. There's no 7x release of it and there's relatively low adoption if you look at the downloads. So what can we do? Well I think that code should be allowed to be hosted in disparate locations. We shouldn't tell anyone they have to host their code anywhere. Hopefully all of you would consider at least hosting your code on Drupal.org if it's Drupal code because that's a great place for it and keeps the community strong. But we are assuming that there's going to be code on GitHub, Bit Bucket and then probably in private repositories at different institutions. So how can we facilitate the creation of a rich metadata catalog that would point the community at this code? I want to show you some bleeding edge work that may facilitate that. I was thinking about what would it take to let somebody upload some kind of create a registry, upload just one piece of code? And when I thought about that I thought well telling them to upload a .info file might be a good first step because that way I normalize my data and I take the name of whatever their project is from the machine name and I can get some other interesting information from the info file for instance dependencies that their code has. So the first thing I did was create a simple form that allows you to upload an info file and it requires a download URL because I'm kind of assuming if you're not going to tell us where to go get your code we don't even you know having the information is not that useful. There's no title on this because the title is going to be automatically derived. I'm not going to actually run this because it's of limited use. If you have any kind of interesting code you probably have eight info files. You've probably got a collection of modules or a feature that has created a whole bunch of info files. So wouldn't it be cool if we could give a Drupal site a code repository and have it go look in the repository, identify Drupal code and bring some kind of information about that code back to the site. So one such repository exists here. This is actually some slightly older stuff that was done at Berkeley and it's got a bunch of different things in it. It's got a theme. This is like an entire Drupal core, a branch from Pantheon and then it's got some modules and these modules have configuration in it. So the next thing I attempted was to use the GitHub API to actually go get information from a repository. And basically what it does is it defines the repository you give it and it looks through all of the projects in that repository for info files and then it parses them and creates nodes. So everyone cross your fingers and pray to the demo gods because this is the boldest thing I've ever done. So we'll use our little autocomplete institution field and we'll say please work. Actually, I'm too nervous even to type that. Not that I haven't tested this like 20 times. And so right now a bunch of REST requests are happening and on my local host this actually choked a little bit but Pantheon performs pretty well. Needless to say this would be a great place to implement something like Q or the batch API or something like that so that users have an idea what's going on. Thank you. Wow applause at DrupalCon. That life mission fulfilled. That's awesome. So what's happened here is we've created a whole bunch of different nodes and let's take a look at what they look like. Basically an interesting one might be say one of these modules. And what we've got here is kind of messy stuff. But we from the info file we've got the core. We have the machine name and we have what dependencies. This depends on Drupal's SMTP module. And then we've pulled in data from GitHub so we have the version control URL. So we could run a get clone command with that. And then download URL honestly needs a little more work. That's not exactly right. The HTML URL is a link to the page the HTML page for the project on GitHub. So what what we get in our finished site is the ability to create a view that looks like this one that has received some theming love from Zach Chandler. Listing a bunch of projects that these have been pulled both from that Berkeley repository and from Stanford's repository. So if you scroll down here you'll see some Stanford themes and stuff like this. And then further of further interest since I figured it wouldn't be that hard to to try and identify what code we've actually retrieved here. So you'll notice there's this code type column which basically has as the as the projects have been discovered. I've looked for the identifying factors of a core installation or the or what the things I would see if I'm looking at a theme or whether I'm looking did I find a dot module file and a dot info file and is there a dot make file. So then I if I if so I found modules with Drush make files etc etc. And then there's a few things here that are unknown. This is actually some experimental stuff that probably shouldn't be in there. And there's like some random admin scripts and stuff like that. So there's always unpublished. Okay. So let's do a quick time check. We have a little over 20 minutes. So I think that's enough time to go through some of these challenges before we before we start taking questions. And I'm sure you've you smart people have already come up with the stuff that totally is going to make this not work. And believe me we have to. So let's just for the sake of brevity let's just go through some of these and and just say yes we know we've thought of this and we need your help to fix it. So the first thing big challenge that we're going to have is we really want to establish best practices for building features or other sorts of projects. And so we talked a little bit about that before and Brian outlined some really interesting points about documentation and making sure that features are abstracted to a point that they'd be useful for other people. We know about kit the kit spec which is on Drupal dot org and that's cool. We definitely we definitely use that but it doesn't go far enough. And so we want to go even further than that to establish much more specific namespacing guidelines. But exactly what those namespacing guidelines means we're or what exactly they're going to be. We haven't quite figured that out yet. We would really like to be able to publish a guide on namespacing and how do we deal with override. So if somebody takes the your feature and they they update it they they change some of the views or they change some settings. You're going to see that big fat overridden button on the features thing. So how do we how do we handle that. What's the best way to deal with that so that so that your site will be maintainable for the future. And so we really need to establish these best practices and publish them to the site in the form of blog posts or some sort of FAQ or we really want to be able to say OK if you really want to offer the best sort of thing best sort of code for the community. These are the guidelines that you can follow. And so I talked about namespacing a little bit so that's a big thing so that's not only namespacing your feature as a particular as the name of the feature like we always namespace everything as ucd underscore something or other. But what about content types and fields and views panels taxonomy. What about if you have like a feature set that has four or five different features inside of it and they're all kind of bundled together for a particular use case. Also renamespacing Brian mentioned that briefly well how does he change all that from ucd auth to ucb auth for the feature that I gave him. And so there's going to be a whole lot of find and replace that's going to have to happen. Like maybe we could build a tool that does that like the coder module that upgrades things from six to six to seven. So these are these are opportunities that are available to us to really make this work. Also we have some difficult questions like OK we've been talking about features a lot right. But in Drupal 8 we have this wonderful glorious thing called the configuration management initiative. And we have a whole totally different way of managing configuration as code in Drupal now. So what does that mean for the features module specifically. We don't know there. I don't think anybody's actually made a full upgrade features module may still exist as simply an upgraded UI to the to the configuration management system in Drupal core or maybe this idea of apps will come out and that and that's been gaining a lot of momentum as well in Panopoli and other in other distributions. And so maybe that's the way that we still need to focus. So once again features is kind of what we talked about but that's not everything there's there's going to be more and we just don't know what's going to be in the future. But we as a community can help guide that as well. And so we also want to hear from you what else are we missing like what what things do we need to have that will help you guys in communicating with each other and sharing resources and imagine yourself as a brand new you're a Drupal developer in a university that has never done Drupal before. So what would you need to really get to get up and running. We want to be able to figure that out and the community will really guide all this. So join us. So we think this is worth doing. We know it's going to be hard and we know we're going to need lots of smart people to work with us. We know that we're focused on professional technologists that work in higher education. But we really want to partner with agencies and leverage their Drupal know how and their commitment to higher ed. And I know that some of them are in the room right now. So we're you know we're looking forward to working with you directly on that. So the please visit the website at you do dot org. It's very raw. It's a work in progress. This is a volunteer initiative and if you join us you can help us make it better. We're imagining that this is an organization that's going to be governed by members and by working for a college or university being in Drupal you're automatically a member. It is free. Please come join. So you know what we are going to set out to do and you know we have these challenges ahead of us. But you know one of the foundational principles of open source is that many eyes tame complexity. So we wanted to take that principle and leverage it for things that matter to us every day. And I read so we think that we have built a viable collaboration platform. We don't want to take anything away from Drupal dot org. I think instead what we're talking about is harnessing work recording work that is currently unrecorded. And we're going to make Drupal stronger by doing that. So we invite you all to go to the website and make accounts and help us kick this off. We're starting today. Thank you very much. So I see that we have a mic up front here. And I think for the sake of recording if you guys want to cue the mic that would I know that the D.A. and Drupal kind of would appreciate that. So if you have any questions you can ask us now or we also have the follow up off and we're going to of course be around. I am Matt Garrett from the University of Kansas. I got a quick question. So I went to your site. I see that you have all your code posted. I didn't see a spot for. Hey I want to do this. Is anybody else doing this. Do you have something like that. I think that that is going to be like the killer thing that we do. It's not like what have I done but what are we about to do. Right. So yeah we kind of need some some way to do that. There's a bunch of things missing that I imagine that we could leverage. You know we have commenting turned on for projects but we don't have things like flag or five star you know up downloading. I think we need some mechanisms to have the best work float up. And I think that you know like we said there's probably going to be like a dozen course features. Maybe the best one ends up on Drupal.org and we have this nomination mechanism. But I think being able to identify colleagues with shared problems and collaborate like the way that we did with UC Davis on our service catalog. I think I think that's the future for the organization. Thanks. Mike Jennings I work for the Department of Energy and would it be possible for it to join the site even if you're not in a higher learning institution. My organization funds a lot of of the research and development in universities and so on and so forth. And we're interested to you know follow activities like the one you're doing here. I will say absolutely soon as our kind of minimum viable product. This is really what we wanted to get out but we will absolutely have a place for public and private institutions to be able to join and in some manner or another. And really you can benefit from this already like I don't think there's any sort of permission set. So once you're logged in you can see more stuff. You can still go to the site you can still see everything that's there. You can see all the people that are there and contact them however you feel you want to. We definitely want to be able to involve everybody but in the interest of well presenting a Drupal con we really had to narrow our focus and the fact that we all have real jobs. We really had to narrow our focus. So yes I'm glad you're excited about this. I'm glad there's I hope there's going to be a lot of people that are excited about this. There are news and blog part of the site already. There's a blog part of there and there's Brian's already written a number of blogs. You have comments just for logged in users. I think OK. So that is the one functionality is that yeah we can revisit but right now for comments you do have to be logged in to leave comments. That's enough to follow along. Thank you. Thanks. I just want to follow up on that a little bit because I was really concerned. I imagined this question exactly and I was like having this debate with Zach and now I really understand sort of one idea Zach has and it's not that we don't we want to hide anything from other communities. We definitely want to be as open as possible. Zach's Zach's thought was when we start having people submit projects using some of this code that needs to be you know made a little better. It will be a really rich community for higher education if we have a focused domain of code. But that doesn't mean that we couldn't clone off a site like this and create you know another section for another community or another domain like government or something like that. Well one thing that my office might be interested to do would be to promote your group especially to recipients of our grants and things like that. So I'll follow along. Great. Thank you. Thank you for your presentation Daniel from the University of Oregon. My question is how did you how do you know a city deal with licensing of your code. You're right that's tough. Yeah so there's that's a big problem and it's something that University of California is currently dealing with right now. You know I tried to hide it but you you brought it up anyway. So what I gave to Brian since he was UC I could give it to him but I couldn't give it to you yet. Believe me we have people embedded in the organization that are very interested in doing this and we're proposing change as we can. But that can be difficult to do and different institutions have very different rules about that. He's already got the Stanford's already got a feature service set up and they're sharing a bunch of that stuff. Berkeley you do too right. He has some GitHub stuff that he's sharing that's already available. So it's kind of it's kind of spread out and and I don't know I really have to do with whatever we can get from your institution if you have a public repository or public GitHub account or something that you're already sharing we'll take it. If not we don't really have anything to look at right. And so we want to encourage you to to share your code. We want to encourage you to make whatever changes inside your own university's policy is necessary as we're doing. But if it's out there we'll take it and if it's not well there's not much we can do about that. Yeah the one thing I would add to that is that there's there's some amount of risk taking with this. I mean you're you're you know becoming a change agent for your university perhaps and well Drupal is GPL so you know all of the you know that can be a challenge for some some cases so so Stanford's OK with us releasing GPL. I think other universities might prefer another license which creates conflict for putting things on DDo which is part of the reason why we're doing this. But another thing that's important to think about is that at its heart features is about its configuration. You know I didn't sit down and and write code from scratch for some of the features I've made. It's it's bundling config so I don't I think that you have a you know a reasonable case that this is this is config it's not creative work it's not the university's IP. My name is Ernie Gillis I'm at Berkeley College of Music in Boston so I'm when you mentioned about the humanity side of things that's a lot of beacons went out of my head. The questions I have is kind of more of on the site if there's resources to help people start to learn about either kind of what you alluded to how to talk to the upper management folks to try and say hey here's how we can help share look what's going on all these kinds of things or even just interdepartmentally because some colleges are not necessarily to share across departments. Also possibilities of maybe looking into how to even go into sharing some sort of MOOCs or something to help do trainings on all that kind of stuff to help just broaden that community and bring it more forward. I think that's a great idea. We have I mean right now the platform of our website. We could do that through a blog post and want to write it. So yeah I think that would be a great idea to be able to have that kind of stuff and also I think you know I'm not a lawyer but companies like Aquia and Pantheon and the big companies that do open source like for a living and make a lot of money and they have lawyers and they're very very vested in and making code available. And so it's possible we can leverage the Drupal Association or other companies that to be able to help us at that as well. And yeah I think some of these topics about you know creating change in your campus and managing up and things like that. We might prefer to have an offline conversation about this. No I'm just curious about creating about making a resource space on this to kind of help the community learn more of how to do it. That's a great idea. Hi my name is Ken Niquiz from Lafayette College. I think sharing recipes is awesome. The last two things I worked on or my group worked on before I got here were LDAP CAS and Service Catalog. One of the things that I'm actually Lafayette's been a part of for the last couple of years is we created this ad hoc group of colleges to support Moodle liberal arts colleges to support Moodle. And one of the things that we found really helpful were we do every six months we do what we call hack doc events where we just get together. It's 20 to 30 people in a room hacking. There's instructional technologists there helping out. And I think having some sort of event where people can kind of touch base every few months would be fantastic. Either tag on a Drupalcon or a Drupalcamp or something that people could get to. Can I let me address that real quick. So we mentioned bad camp a few times and where this all came together and we've been doing it for two years now is there's a higher education summit at bad camp that we do every year. And Zach and I have been organizing that for the last two years. And that's kind of been our pseudo platform for bringing people together. And we presented kind of a very very early vision of this this past year. But I can see that as being a platform for moving this forward in the future as well. Sounds great. I had one other quick thing that we've been running into which was we find modules that we'd like to use Homebox that haven't seen a lot of updates lately. So I think one of the things we're also looking for in addition to this kind of thing is identifying other people who are interested in being co-maintenors on projects that just aren't getting enough love or maybe you're doing it in-house but you're not committing back because you're afraid that everyone's going to start swamping you with requests. So thank you. Hi. I'm Danny Norden UX designer also working with Berkeley College of Music oddly enough in a different department than Ernie over here. I'm very intrigued by the idea of a knowledge base. And sort of a repository of code but I'm also wondering if you guys are thinking about a repository of knowledge that goes beyond blog posts. But also you know we talk about defining best practice who actually defines what the best practices and then where is the best practice actually cataloged. So I don't know if you guys are thinking about curating that at all or what was going on there. Well I think for best practices we would be building on Drupal's nature of the duocracy. So like it's kind of the best practices are going to come out of people that are trying to do it. And then just us having a form for comparing notes. The fundamental trick of what we're talking about here is getting features and other code that were built by disparate teams to work together in the same place. So we have that there's the kit specification which is about making sure these things work together inside of a distro. But this is a whole other level of complexity. So I think that as soon as we start thinking that way like earlier Brian was saying he was suddenly imagining the work he was doing being used by somebody else. I think that triggers some changes in the way that we work. So yeah I can imagine that we would definitely be interested in documenting that on our website for broad reuse value and sharing with all sorts of other communities government and others because some of our things are really domain specific and it matters that we're all in higher ed but you know some of them have broad reuse value and we're going to want to share as much as we can. Excellent. And one other thing I'm also helping organize design for Drupal this year which is next month and I'd love to invite you guys to submit the session or another session at D4D because there's a lot of folks in the higher ed community and I would love to see a talk on this very topic. So just wanted to put that out there. It's in Boston actually on MIT campus. It's designed for the number four Drupal dot org and just go there and you'll see it. Awesome thanks and a real quick follow-up on on your question about how best practices might evolve just I'll share my imagination. I you know very hastily threw up you know a bunch of blog posts which actually I you heard almost everything my blog posts there might be a little more detail but my thought is like talk about my experience adapting this thing talk about some improvements I see get some conversation going on about that maybe another maybe some other people we can't do all the content on the site hopefully some of you will too and eventually you know we distill that into a document like here's here's our our zero dot one version of the best practice. I like that and I also want to put forth that the thing you did for code and creating the metadata for code would work really really well with knowledge based articles and blog posts from other places. Yeah if you put them all on GitHub. You could just kidding I'm just kidding yeah I love I would love to invent something else. I am Jim McKinnon from Imagex Media I just actually just kind of follow up and tie in that a little bit as well. I'm more of a I'm a developer so I look at things in the code set of things so as far as having a knowledge base and code and doing practice is great but I also want to do something on the code level so what you have showed to me is you have a repository of finished work more so than anything at the moment and you were talking about you wanted to start doing more collaboration so now I'm looking at this as a list of stuff that could be in progress but it could be in progress in GitHub it could be in progress in Drupal.org and you're trying to get it into one place now I'm looking for you know as a developer how do I get in and help start collaboration collaborating with these guys that are working on this are you going to provide any extra tools or support on that to allow me to join those developers and those groups that are doing this work and also in the flip side things outside of your organization these guys are working on specific edu tasks also you guys need some help do looks at things you need some work how do we get in touch with yourself to build on some features for you for the things like adding these collaboration tools you have a list somewhere. Right, yeah one thing I've imagined in terms of collaboration is that now that now that we can communicate with the GitHub API we can also get information about forks of code and so we could figure out a way to expose sort of originating projects and forks on the site and create relationships you know using Drupal to show okay here's I don't know a Stanford WYSIWYG feature something that ImageX took and took to the next level but and you know that one's over here here's the relationship just similar to what we have on GitHub it might actually that might be reinventing the wheel too much of what's on GitHub but I think it might have some value because you could keep it within this community you could show these relationships really clearly in one space in one domain of code being higher education. So that and there was a second part to your question which the second question was you know specifically for your organization and how do we help contribute to those tools for your sort of things like how do I help build out these tools for EDU-DU. Like what what what something as a university can we contribute towards furthering this site for you. I kind of missed that. So we don't have an email address yet. So you can reach out directly to any of us. So we have so we're imagining a group of members that could be many hundreds of people maybe and we're going to give governance essentially of the organization to them. There is a steering committee Konstantin Tostiati Adam Moore from Stanford Quindum Brasky from UC Berkeley and Brian Allendike from Penn State University. You can reach out to any of us and we should have our contact info on the site or a contact form or the contact form. But you need to log in for that. Oh yeah and I'll go to the box. Yeah so thanks guys. If you come to the box we'll answer your questions or we'll walk there with you. How about that. I think it's a one oh seven. I think so. OK. Thank you everybody.