Merken

Don't Be A Hero

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
and this and this and this and this and that and I am in any welcomed the outcome With this is late start on time I guess and exciting I mean my name is lily
Selene my last name is in no way phonetic so here's a little guide for you Lily surely very strange you can find me on the
Internet as Lilly Albert in all the places I'm a software engineer at all modern
health and where we help people with chronic disease by supporting behavior change and I'm really grateful to a model for covering fly in my hotel in giving the time off to come to Atlanta and talk to you all about open source when I am not thinking about things at model and usually thinking about rails
bridge rose grid is an organization that puts on free weakened workshops to help make the Ruby community more diverse we maintain a set of local open-source curriculums and an event management app that we call bridge troll the and currently the chair of the board and when I'm not thinking about a model or bridge and usually thinking about
double union which is a feminist hacker maker space in San Francisco where the CTO and I maintain our membership application so at some point
today these slides will be at this Bentley but they're not there now right now which is linking to I don't think think so so check that out later so when a talk about 3 big
things what is a hero in open source how to recover from being a hero in open source and tips for being a contributor so what is the hero I
tend to think of heroes in the Ruby community as being a lot like super heroes
and some of them have makes a special abilities that we use to make our lives better Lake contributing so much
so consistently have got to be some kind of superpower rate of but a lot of heroes are just regular
people who started helping out figured out how to get things done and who we've come to depend on over time when you 1st think of like a a ruby hero you think of someone who's up on a
pedestal someone who's a highly visible member of the community and but a lot of our heroes are actually members of the crowd and the people
who maintain Germans who make working on a Rails apps so great and you don't necessarily see them a lot so quick
confession I am a little bit of a hero I am the sole maintainer of double unions open-source membership back and I do rather a lot of different heroic things for rails storage so this is kind of great
sometimes for me and it's pretty great for a community like we have these heroes that do so much stuff and make writing Ruby on Rails apps so wonderful and then there are some upsides for the heroes as well so when something's
busted for the w new Napa we need to add a new feature something I can swoop
in and I have all the context in the world and I can help balance and that leaves me feeling all warm and fuzzy and it's great they can also be really nice to work by
yourself because you get a kind of fly
solo you already know where everything is the c can get things done quickly and I get to make large and small decisions for my projects without necessarily getting other people's input and I don't have to worry about other people breaking the builder introducing Boggs they pretty much as afterward about myself break at introducing bugs judges of and if you make enough contributions contributions to get involved with the right project sometimes people do gain some notoriety in
the community right like who doesn't want to be really famous and yeah so sold Robert E. heroes was
do it right now uh
no sorry it's not that easy that there is some real downsides to being a hero I think the number 1 reason that having heroes is bad for our community is that despite all of the amazing work they do and how much gets produced every single here we have is a single point of failure silos
really bad and we know that but they're impossible to avoid if you're the only person working on your project and nobody else has commit access users may be kind of screwed if you use period getting by dinosaurs on so that alone I think it's a good enough reason to stop being a hero but heroism can also really sort for the maintainer I definitely felt trapped by
my responsibilities and special projects from sort of the only person pushing things for if I leave I worry that the project might fall apart and then I worry that if I leave and the project falls apart and nobody cares like what was the point in the 1st place and this existential dread and everyone sat on so the but How do I get here I personally am a
responsibility sponge like when I join a community I work on fixing whatever problems I see and then I end up becoming responsible for the pieces that I fixed and if you repeat this enough time on any project it's burnout
town so it just doesn't work to do too much by yourself that actually quit rails bridge twice in the last 4 years from being overwhelmed and not seeing how I could make it fit in my life and with when we use of gems sometimes the maintainer just kind of slows down the contributions or question issues pile up and sometimes the maintainer will ask for help and nobody ever comes as a sort of keep half maintaining the project and sometimes they just silently disappear and the users have to fend for themselves and you see an issue that's like hey this seems abandoned do we still quarterly do about that so that's quietly a way that people born out but we also have visible members of the community
is range quit it is write a blog post about how Ruby totally sucks and they're over it and that's really really there from 1 distinction note that I'd like to make is that not all prolific
contributors are here at right writing a lot of code doesn't make someone a hero it's awesome that people get things done when I think about heroes there are people who hold projects up by themselves the people who are silos who were necessary for the project's existence and sometimes it happens because the maintainer doesn't what other people's or doesn't trust other people to actually give contributions and that's terrible but I think the more common reason that people become heroes is that they just kind of fall into it by accident you're bitten by a radioactive
spider and idea 50 stars and get having a bunch of users to talk to so what can
we do to help Watterson strategies for recovery the 1st off I think it be
really great if we pay people to do open source development any part of why people are heroes this for a lack of resources and we would have more resources if people could I am actually pay their rent with open source work if people didn't have to spend their evenings and weekends supporting on open source which then supports lots and lots of businesses making up a lot of money 1 organization super excited about is new and it's called together
and it's a new nonprofit trade organization of 501 c 6 apparently some and they are a supporting the Ruby tools and infrastructure with money donated by individuals and businesses on seizure totally check them out and get your companies to sponsor as the appear at so for you go if getting paid to do open source isn't an option for you what else can you do the so 3 big things so that
I would encourage you to think about are documentation project management and recruiting collaborators
sadly none of these things is right some code but you should totally do that anyway that's why we're here I'm a big part of what makes a hero is that they're the only 1 with the tools to solve the problem if everybody in Gotham had a Kevlar
sooner Batmobile they would need that but things would probably be a lot worse so documentation no is 1 of the ways that you can give people the tools that they need to help and the 1st place to start it and is kind of obvious
you're of so you shouldn't just include how to use your library area application but also how to contribute on how to get the app running in the test passing where you track your features and by how you like to communicate the virus a slap you mailing list Google group giving people the basics to actually start contributing you probably are you have some of this stuff in your reading and it can be hard to see what's missing because you already know your project like the back of your hand so what you do next is you find someone who doesn't know your
project and I went through this with double union but not with the hippo and was incredibly useful so to get some fresh eyes on my read me and see what what I was missing and then Walter get have has a great I post about open source collaboration that only 2 in the notes for this and but 1 thing that stock out for that are from that to me was this idea of minimizing friction for contributors so everything they were doing here is trying to minimize friction so that people can get involved and and you can not be as much of a silo so you documentation can help with that a lot of you want to communicate your preferences like if you like squashed commits an animal or specific formats for documentation and letting people know up front so that you're not just nitpicking a pull request you can focus on actually code review and pull requests can be really helpful you wanna disenfranchised people who are excited about your project the next thing you need to do is write down
everything you do as a maintain but there probably a lot of things that you do that nobody knows about and nobody can help you do the things that they don't know you do actually recently went through this exercise with real great and I found this long list of random tests that sort of accrued over the years a lot of them would be great responsibilities for a new contributor but I've just been hiding them because it was way easier and so once you have this list you can share it with
people and ask for help with some of these things so you can be less of a silo and other people can get a better understanding and more invested in your project I admit I have not actually done this with my Rails bridge jobs this stuff is hard but in public Besançon didn't do it on the flight back to San Francisco so hold me to that and next up project management is hard and that's where
people have jobs doing it but unfortunately we start to do it in the workflow you use for your project
matters so when you start off by yourself you can kind of keep of a list of future changes in your head this unfortunate is very hard for other people to access so you start writing things down and the tooling for this is not great most of the bomb project management apps kind of assume that people will be consistent and open source projects often have completely inconsistent sets of contributors and and so I do not have a silver bullet for that so but you do need to find a balance between sort of your personal preference and then what is accessible to other people on bridge troll we use pivotal tracker arm to keep
track of our our upcoming features and of we inherited it from the people who started the up and it works pretty well because the people who do most of the contributing I'm like tracker and use it and I have suspicion that it's not helping people get involved is that you have to kind of ask permission to be part of the team's can hit the start button on the maybe that's that hurdle is to great that so far nothing else system significantly better in inertial and so on on double union we use
get up for everything of which means we can prioritize anything that we can get creative with tags and and it's great because it's a predefined and another reason is looking at get have issues br actively so what I've found helps is just e-mailing out the mailing list saying I k b the fight issues that it would be great to get some help with and so far it's worked like people have picked up issues and then I know people that I should sort of like try to convince to do more things and another piece of project management that is critical is the timing
that you own have when you replied people's for us Mozilla the study of contributor engagement and they found that if somebody receive the code review within 48 hours they were exceptionally likely to come back and make more contributions but if someone had to wait longer than 7 days there was almost no chance that they were going to come back and give another contribution so this is obviously challenging if you're solar maintainer and because maybe you wanna go camping 1st 3 days of 4 days and now the PR is sitting there but you should totally go camping you should not like bring your laptop with you in your Wi-Fi hotspots signify uniport quests you really instead want to find other people who can help review those pull request so that you're not the only person doing and springs is to recruitment how can we
actually find like these fabled contributors and co maintainers to share responsibilities with people we trust and no will help our project grow and succeed when you're making big feature decisions any future decisions like who you talk to hopefully you do get some input for new
users and talking to people is generally a good idea when you're making changes in the act but it has this wonderful side effect of letting you helping you find the people who were passionate about a project or maybe just slightly interested I'm in whose opinions you find valuable and then you can try to recruit some of those people to help you out when I'm talking to people who use the double union there sometimes rails developers but mostly not they have to do a little bit more targeted outreach to potential contributors which is pretty different if your project is a library
and if you maintain a library your users are obviously developers and they're probably Ruby developers which is also that means all of your users are potential contributors of but most people do work on apps in their day-to-day lives at work and library development can is pretty different from application development and Sarah may actually gave a talk at nickel city Ruby that owing to the notes called multitudes where she is are spec as an example of how different the internals of a library or from its API and so there's is steeper learning curve for application developers and when they're working with with a library for the 1st time so keep in mind that even people who were have been professional relatives for awhile might might be a little bit more support as they get started helping with your library and that's OK so all of this can sound pretty
painful instead of writing code I'm asking you to do all of this other stuff this documentation and likely e-mailing people and but I actually really don't want you to do this by yourself I
want you to not just become the PM of your project the find someone else to share all of these terrible responsibilities with right you want other people to help you with coding and documenting and communicating so that you're not a silo for any part of the application of and when you are recruiting people it can be scary if you're working on and happy you really invested and you don't know if someone's going to turn out to be evil right like they could be
actually evil and try to ruin your app but it's much more likely and I found that people will just not do anything at all they're like show up and talk to you and then disappear and so in open source I've generally has learned to manage my expectations of everyone of us which means they have the plus side I get really excited when anyone does anything so the bar is kind of low when you've done recruitment and you found other people and you have
contributors what can you do to sort of help them grow in your project of I
1st started out I'm at double union as the membership coordinator which meant that I had like all the spreadsheets and I had to write e-mails to people and I had to do all these things that were very obviously good for computers to do some and luckily I Mirelle's developer and we had a real that so they all I will just add features to make my job easier and it was also and to the point that I was like a what if I'd never e-mail anyone and I can just focus on writing code and and building tools and so I became an I just worked on that so the alphabetic that it never according this great the Board of W notice that I was like working really hard on the at initiative in the role of CTL
Lakewood Nataša making a title and gift certificate from massage knows like Ostermann the but unfortunately it did somewhat reinforced my a heroic tendencies to them I got a code is also bit everything and but after you know a year so doing that I have now shifted and I'm trying to find someone to be
a co maintainer and I'm trying to build up the team instead of doing everything myself
so you want to help people move from using your application for your library maybe like helping fix bugs to maybe adding a feature and then a small small minority of them maybe could become commentators there's a final grade and how can you help people move through this funnel mom Mozilla in that same study found that showing some the next bond that they could work on would dramatically improve the odds of them contributing again just giving people a little bit of direction and encouragement can go a long way off but having other people adding code and reviewing code and maybe things are getting onto master without you seeing them does require you to let go so you
might be like me you might really love being in control of things and I really I know I can get things done quickly and but that just reinforces the silo that I built for myself so I try to remind myself that I have to let other people help even if it's slower and and even sometimes things fall on the ground even if something things don't go well and I would suggest maybe non-critical buttons or features that are not super super high priority that a simple can be reserved for you folks in markers bite-sized in your backlog because getting people use to your workflow with smaller things means that the more comfortable making larger contributions in the future of what the things I learned from some folks at double union with this amazing phrases don't like the
cookies and you've heard of it before it is the idea that like when you're working on a project with someone and if you say you're gonna do a thing and then you don't do it you have just licks the cookie and put it back on the table and that's signaling grows how come so try to not with the good news from as a maintenance especially easy because people here you say like a lion opinion about this thing I mean if you can say I am doing this definitely they might think 0 well Willie's got that she she obviously care still take care of it and so it's imperative that I if I noticed that i've with the cooking to let everybody know like Haiti I'm not going to do that thing again definitely not please take care of it I can give you context if you need it but please take it and run 1 thing grills bridges really good about doing is Boutros
retrospective the kind of regular meetings to look your process and figure out of what's working and what's not and we use it at the end of most workshops and we get really great feedback from volunteers and participants and we grow a lot just knowing how the workshop whether people but 1 thing that were really bad about is ever doing them in any other context way I was volunteering grow bridge for like 2 and a half years before we did any retches whatsoever and like any project whether it's like your job or a volunteer did there's going to be challenges and are going to be inefficiencies and without a regular mechanism for surface surfacing those problems will faster and things that you could have dealt with really effectively early on will become much bigger deals if you don't find out about the early and so you this time and people and energy problems if you don't surface them so happy report now were doing more actress and so far mostly as the board but I have ambitions for many more edges in the future and I think you should probably go schedule uh rupture with your team like now inch a right after this meeting and if you don't have a team if you're working on a project by yourself you can have your own retro you can sit down and think about use of what's going well for this project what i wanna change and maybe you can share the results of that publicly maybe you could help people know that that you do need more help and but we don't just want to reflect on what busted we also wanna be celebrating people's contributions
and this it so thank you thank you like regularly and letting people know how you value them on your project can go a long way so even if it's just someone opening an issue to let me know that there's a typo or a dead link In a arils bridge curriculum I think them either way like I'm so grateful that people are helping improve the stuff I and especially as the maintainer of a project earlier project people watching looking to you to determine how they should behave and so you can like lead people to be more also if you're Austin yourself in just a quick kind of housekeeping things just don't poured the
passwords just like really if you have an act you deploy get a shared e-mail address gives password manager have somebody else who can publish your genome right is like nothing to be around forever in the home so that more positive things here new contributor
and you should totally us to do it and also there's a talk this afternoon all about this and this afternoon courtney urban is giving a talk in the beginner track you should totally check out but here's some suggestions the
docks might suck the dots will probably stock of the dimension of the project might not have been this talk maybe and but the good news is that you are uniquely qualified to help improve the stocks because you do have these fresh eyes so please help make them better even though it might seem trivial like to make a text change and open up a pull request of like all I did was change the text and the read me to make more sense Parliament that is incredibly useful and you work providing a gift for all future people who were using that library of another thing about solar projects and in particular is that they can be a little weird
and 1 person code impinges lake not always make it gets Cauchy right like if you don't have other people started contributing an incident evening out that things then the cell can be weird so that's OK tho is a mammal challenge 1 thing I wish that people thinking about contributing open new was that you totally who need
permission to open up or request if there's an open issue in you wanna tackle it just go for it you don't have the common you can comment on issues they like other work on this but if you me you're not gonna believe them because no 1 ever does that all of this but you can open it may be a provisional pole requesting emulate hey this is what I was thinking this is the direction i'm going in on because it's a lot easier to talk about written code then discuss sort of like a potential implementation of an idea of an energy do openable request on a project the worst that can happen is the lake is an accepted to somebody else fixed day or the solution was a private meeting was looking for and hopefully they're gonna give you some feedback on like the worst worst thing to happen if the would be to maintain our would be a total tool and like say something really rude and my closure pull requests but the silver lining there is that you know never to use that library again because you don't need to work with jerks because your OS another idea for contributors is to bring your own meant for to the project
show a coworker for someone at your local really need of the code you're working on and get their feedback before submitting the you go to be helpful to get a little feedback 1st because the maintainer might not have time to be a mentor and if you can kind of save them the 1st couple cycles of feedback and that's also a huge gift so here are some
general guidelines for life or maybe open source sentence 1 thing that I would like all of us to do is take a look at
ourselves and ask why we want to do this but if you're currently maintaining a project are you still getting something out of your work are you still enjoying maintaining your library and if you're a prospective contributors why you wanna work on open source if it's out of like was vague feeling of obligations let me just tell you this you don't have to do it but you're not obligated to work on open source but not everybody has the bandwidth and I think the guilt is a pretty terrible motivator by some great motivators awake you use a project and has a blog in you can fix it or you got something out of your project of and you really wanna give back so if that's the case please please contribute to open source and side note get have
resonance bullshit right this idea that people have to contribute to open source in order to get jobs at places just completely it's really irritating but not everybody has time to do this and it from this kind of practice totally favors people who have like a bunch of free time on the evenings and weekends to make contributions to open source and it also has its annoying side effect of people showing up being like I wanna work on open source but they don't really wanna work opens on open-source they would wanna get a job and they think that this is 1 of the prerequisites so if employers to stop doing that that would be really great thank you know because this is all
optional you don't have to maintain a project for ever you don't have to contribute to a project forever you'll have to open source but you totally should because it's totally awesome if you want to uh the flip side of how optional it is is that we need
accountability if we're going to make project sustainable we need to know what happens when someone doesn't do the things they said they would and this is inevitable we need a shared vocabulary around accountability so that people know how to talk about it when they slip up in a totally failed to do something but you don't want them to feel like they're a failure as a person just as they failed to complete a task and I think this is 1 of the things that can be most hard about working on teams because as a as a leader in the relevant community I know that everyone's a volunteer and so I feel pretty guilty when somebody misses the deadline and I'm like hey that thing you're not getting paid to work on do you think mention of and so it's very important to sort of be up front I think vectors can totally come in handy when you have a space the everyone's just expected to be honest but because part of not being a hero is like not fixing things every time they go wrong is having a team that can handle failures and sort of keep going so To recap
silos bad and we don't want people to be single points of failure they can't stick on projects for ever it's not really it's not silos are good for the community or the users or the maintainers because we need succession
planning we should all assume that we're gonna stop working on a project at some point because we have no idea when we might become indisposed in
the short or long term the
teams are awesome they can help take the burden off of you to do all the things so you can focus on what you are most excited about which can then take your project like way more exciting places with less burnout and more
unicorns thank you
Due
to the moon and the movement of things
Open Source
Vorlesung/Konferenz
Elektronischer Programmführer
Computeranimation
Informationsmodellierung
Open Source
Mathematisierung
Software Engineering
Computeranimation
Internetworking
App <Programm>
Punkt
Selbst organisierendes System
Open Source
Stellenring
Kartesische Koordinaten
Bridge <Kommunikationstechnik>
Element <Mathematik>
Raum-Zeit
Whiteboard
Ereignishorizont
Computeranimation
Informationsmodellierung
Datenmanagement
Menge
Hacker
Hacker
Rechenschieber
Open Source
Computeranimation
Wiederherstellung <Informatik>
Total <Mathematik>
Vererbungshierarchie
Bitrate
Computeranimation
Besprechung/Interview
Softwarewartung
Bit
Subtraktion
Existenzaussage
Open Source
Delisches Problem
Element <Mathematik>
Speicher <Informatik>
Computeranimation
Gruppe <Mathematik>
Besprechung/Interview
Projektive Ebene
Ein-Ausgabe
Kontextbezogenes System
Entscheidungstheorie
Programmfehler
Punkt
Rechter Winkel
Zahlenbereich
Einfache Genauigkeit
Vorlesung/Konferenz
Computeranimation
Softwarewartung
Punkt
Endogene Variable
Projektive Ebene
Frequenz
Quick-Sort
Hinterlegungsverfahren <Kryptologie>
Computeranimation
Softwarewartung
Endogene Variable
Projektive Ebene
Hilfesystem
Computeranimation
Softwarewartung
Spannweite <Stochastik>
Web log
Existenzsatz
Besprechung/Interview
Projektive Ebene
Code
Computeranimation
Spider <Programm>
Open Source
Mereologie
Besprechung/Interview
Strategisches Spiel
Wiederherstellung <Informatik>
Softwareentwickler
Hilfesystem
Computeranimation
Wiederherstellung <Informatik>
Kollaboration <Informatik>
Datenmanagement
Selbst organisierendes System
Open Source
Datenmanagement
Projektive Ebene
Computeranimation
Konfiguration <Informatik>
Mereologie
Besprechung/Interview
Gewichtete Summe
Datenmanagement
Code
Computeranimation
Umwandlungsenthalpie
Softwaretest
App <Programm>
Computervirus
Extremwert
Open Source
Reibungskraft
Besprechung/Interview
Gruppenkeim
Kartesische Koordinaten
Mailing-Liste
Code
Kollaboration <Informatik>
Flächeninhalt
Programmbibliothek
Dateiformat
Projektive Ebene
Lesen <Datenverarbeitung>
Resampling
Datenmanagement
Prozess <Informatik>
Endogene Variable
Besprechung/Interview
Projektive Ebene
Bridge <Kommunikationstechnik>
Mailing-Liste
Hilfesystem
Quick-Sort
Computeranimation
Open Source
Pivot-Operation
Mathematisierung
Datenmanagement
NP-hartes Problem
Bridge <Kommunikationstechnik>
Mailing-Liste
Quick-Sort
Computeranimation
Summengleichung
Datenmanagement
Menge
Prozess <Informatik>
Projektive Ebene
Widerspruchsfreiheit
Schreib-Lese-Kopf
Fehlermeldung
Indexberechnung
Mailing-Liste
Physikalisches System
Computeranimation
Homepage
Weg <Topologie>
Datenmanagement
Garbentheorie
Einheit <Mathematik>
Verschlingung
Mereologie
MIDI <Musikelektronik>
Projektive Ebene
Euler-Diagramm
Zeitzone
E-Mail
Softwarewartung
Beobachtungsstudie
Quelle <Physik>
Gemeinsamer Speicher
Notebook-Computer
Endogene Variable
Code
Computeranimation
Entscheidungstheorie
Soundverarbeitung
App <Programm>
Bit
Relativitätstheorie
Mathematisierung
Besprechung/Interview
Programmbibliothek
Kartesische Koordinaten
Projektive Ebene
Kurvenanpassung
Softwareentwickler
Computeranimation
Rechter Winkel
Endogene Variable
Mereologie
Besprechung/Interview
Projektive Ebene
E-Mail
Code
App <Programm>
Erwartungswert
Open Source
Besprechung/Interview
Projektive Ebene
Hilfesystem
Quick-Sort
Computeranimation
Digitales Zertifikat
Punkt
Tabellenkalkulation
Prozess <Informatik>
Gebäude <Mathematik>
Besprechung/Interview
Delisches Problem
Element <Mathematik>
Computerunterstütztes Verfahren
Softwareentwickler
E-Mail
Koordinaten
Code
Computeranimation
Beobachtungsstudie
Softwarewartung
Bit
Besprechung/Interview
Programmbibliothek
Vorlesung/Konferenz
Kartesische Koordinaten
Code
Brennen <Datenverarbeitung>
Richtung
Programmfehler
Gradient
Softwarewartung
Gamecontroller
Projektive Ebene
Bridge <Kommunikationstechnik>
Delisches Problem
Kontextbezogenes System
Computeranimation
Tabelle <Informatik>
Algorithmische Programmierung
Resultante
Kraftfahrzeugmechatroniker
Rückkopplung
Prozess <Physik>
Mathematisierung
Besprechung/Interview
Bridge <Kommunikationstechnik>
Binder <Informatik>
Kontextbezogenes System
Whiteboard
Computeranimation
Softwarewartung
Energiedichte
Scheduling
Verbandstheorie
Regulärer Graph
Flächentheorie
Rechter Winkel
Prozess <Informatik>
Projektive Ebene
Figurierte Zahl
Verkehrsinformation
Weg <Topologie>
Datenmanagement
Rechter Winkel
Adressraum
Passwort
E-Mail
Computeranimation
Hausdorff-Dimension
Mathematisierung
Besprechung/Interview
Zellularer Automat
Inzidenzalgebra
Code
Computeranimation
Skalarprodukt
Rechter Winkel
Programmbibliothek
Projektive Ebene
Hilfesystem
Lesen <Datenverarbeitung>
Algebraisch abgeschlossener Körper
Rückkopplung
Besprechung/Interview
Implementierung
Code
Richtung
Softwarewartung
Polstelle
Energiedichte
Verbandstheorie
Dreiecksfreier Graph
Programmbibliothek
Projektive Ebene
Open Source
Videospiel
Web log
Open Source
Vorlesung/Konferenz
Projektive Ebene
Bandmatrix
Computeranimation
Soundverarbeitung
Resonanz
Freeware
Prozess <Informatik>
Open Source
Projektive Ebene
Ordnung <Mathematik>
Computeranimation
Softwarewartung
Task
Punkt
Mereologie
Einfache Genauigkeit
Projektive Ebene
Vektorraum
Raum-Zeit
Quick-Sort
Computeranimation
Punkt
Besprechung/Interview
Projektive Ebene
Automatische Handlungsplanung
Term
Computeranimation
Videokonferenz
Besprechung/Interview
Vorlesung/Konferenz
Digitale Photographie

Metadaten

Formale Metadaten

Titel Don't Be A Hero
Untertitel Sustainable Open Source
Serientitel RailsConf 2015
Teil 07
Anzahl der Teile 94
Autor Chilen, Lillie
Lizenz CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben.
DOI 10.5446/30661
Herausgeber Confreaks, LLC
Erscheinungsjahr 2015
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract We know that low bus numbers, silos, and grueling hours can make hiring a dev nigh impossible. So why are bad conditions accepted as facts of life for open source software maintainers? Let's stop. Come learn about how maintainers can become leaders instead of heroes, techniques for building an awesome team for your project, and the ways that everyone else can jump in and support open source software in an effective and sustainable way.

Ähnliche Filme

Loading...