DrupalCon Portland 2013

Unconsortium: el siguiente paso en la colaboración de Drupal con el sector educativo

Zach Chandler, Brian Wood, Shawn DeArmond  · 

Presentación

PPT (pincha para descargar)

Vídeo

Transcripción

Extracto de la transcripción automática del vídeo realizada por YouTube.

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 unconcern which is what we hope is going to be the next phase of collaboration and higher education I'm Zach

Chandler I work at Stanford University and with me today is brian wood from UC Berkeley and Shawn 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 coasts at New York City 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 worked there 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 for ideas

from from everybody we're not claiming that we have all the answers 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 we'll examine some of what we what are the known challenges to the approach that we're sharing okay and immediately after this session there

is going to be birds of a feather for higher education broadly we can dive into the topics we bring up today but the real purpose of this boss is just to get everybody who works in higher education both together in the same room to you know 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 so that is in room a 107 you can check the boss boards and it starts at three fifteen so there's something that

was bothering us and so we 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 are not sharing code

in any meaningful way with each other um some of us I connect up to drupal.org but there 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 you know can you imagine what it would look like if the scientific community acted like this instead of you know peer review again so in the next few slides I'm

gonna 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 you know whether it's succeeded and what's available so we all do that in the dribble

contribs base but how many of us have the the ability to check with colleagues at other universities this is there's currently no where 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 this culture on purpose another thing I would like to talk about is this 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 are what our peers who are peers our 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 one point o rly so 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 and instead I think what we're

we should be striving for is hundreds of imperfect beta and alpha releases so they're in at elite institutions we have this culture of exceptionalism and you know there's a lot of you know congratulating ourselves but really we should be focusing on

the fact that this is use case driven work drupal as a content modeling system and and it should be driven it by user centered design and use cases we share the same use cases so you know we're in the same system many Kate many times reusing 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 they're think they're

ready or not so that's the problem space and now we're going to take a look at some actual use cases thanks x so the stuff that Zacks 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 what we've been doing some some real life stuff that we've been doing to try to address some of this stuff and

what I what I want to get out of this is something real at least something like something real that we can to get 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 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 nonzero number of you kept your hands down let me just nutshell inside of a nutshell version of what the features

module does all that clickety-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 clickety-click

stuff that you've done into a particular use case you select what you want to was part of your use case and export that into code so it saves your configuration as a module technically it as a module that spits that it spits out and there's a few there's

a few really great benefits to that when 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 Bourque 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 put it on github or Drupal Euler or for God's sakes mail 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 the main focus of of what we're going to try to share here it's not necessarily

the 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 consider modules or install profiles drush make 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 is part of our ITIL adoption

the ITIL adoption we need to build a stye Service Catalog anybody does that ring a bell to anybody yeah I thought so so and so I say okay well we can we can do that as you describe their requirements I said aw 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 Zack 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 Zack introduced me to Dave ream 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 that's there 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 we were 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 you no one will end up rising to the top it'll probably be Stanford because they're best at everything but we will have lots the port the purpose of this is to have lots of different varieties of different ways of doing things out there

story number two is UC Davis uses casts 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 cast settings and ldap server settings and basic configuration along with that as well as kind

of a module that are a feature that created user fields and as someone logs in with cassatt pulls from ldap and saves that information into user fields not all that complex but still very useful and we were 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 cows in ldap so he says let me see her let me see your feature I send it off to him well there's if you haven't noticed there's one problem

[ ... ]

Nota: se han omitido las otras 5.448 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.