Merken

FOSS DOCS 101 (keep it simple, present!)

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
my own on whom I welcome announced Friday after lunch
I'm just trying to stay awake myself I apologize if I was a little bit going out to carry a keyboard evening before you give a talk is not a good idea to have so thank you for having me so my name is making and I am having trouble with my clicker so I'm a
technical writer for a Red Hat and I've been a technical writer for almost 7 years now
and I document OpenStack layer before that a document j boss and I've also been involved with the Henry I'm ScrumMaster don't hold that against me there are advantages in that and in my ever decreasing spare time and I run of the European Chapter I guess of right the Doxygen documentation community and my talk about Dawksin developer conferences like this 1 and I also organizing roles workshops like we did here in the beginning of the week and I also coach developers in open source projects on documentation so we actually had a help desk with a couple of my esteemed colleagues on
Wednesday where we interview we had people coming in and getting some advice on their offices project documentation and and uh yes so I don't sleep very much and basin burn unchecked public so kind makes it easier to get around and so am I here and why do they put me
in this gigantic room and and brought me a the year-to-year Python because apparently some people think that documentation is important in and supported me obviously it's my job and was you know if they didn't here I will be doing this for a living but also if you don't do this for a living in are users are the ones who have to use software right so and they care about it because it helps them get a better experience it you know the people who create the software it also helps them because they get to be able to showcase what the software can do and and for the organizations for the communities in so it used to
be and it still is to varying degrees racer like and documentation is kind of a known thing that happens to other people some are just kind of happens magically but thankfully right things that thinking
about so thankfully there's been a shift over the last years the last few years where people understand and that your content that accompanies the software is basically a part of the whole package right so you have to software you create you the support the document and then delivered to users
and so how do you help the success of a software project rate of saw how many people here right documentation for a living or as a you know when a project is like that and regular basis patients and to all those honorary was to and so on and there's this kind of there's a lot of different ways of breaking down and how things can hold out a condition help you but but mainly it's you know what you want to improve the user experience and so it you know content any kind of content to the user guide to be read me it to be strings or an error message right all of these
things are prose that accompanies your code right so the and so not only that but you want to create a portable and adoptable workflow for how to actually create and use your product right so if you have an
internal processes and you're you're a project on the company and you want to be able to train people that you've never met in
person right so it's sort of easy thing to do is to sit down with someone be like OK this values as you know the software or this library or whatever it is that we want to be able to create something scalable and to create something scalable in today's world he had to be able to give people some text trade union giving a presentation of going to events like you know doing some kind of consulting company or something like that those are great but like you want to be able to reach the people that you can do in person and
pseudoknots club how do we get
there I've broken existing down and to the 3 sort of themes that from my experience some make it like you've you can do a lot with not a whole lot of initial investment like you can do this effectively right you don't have to just you know if you're a developer you after you retrain as a technical writer and you know spent tons has time learning a 2nd and so there's a lot of things that you can be pretty effectively
and so the 1st thing that we talk about its content strategy
and counter-strategies actually I come marketing web development term that's being slowly applied to the field of technical documentation and so and it's basically like asking the right questions before you document something OK so i'm going and not be original here and still use the 5 W is because that's what every units reasonable way of grouping surfacing on now is correlators based so you know if we're talking about things like personas do I and I'm referring to end users developers administrators business analysts whatever right it can also divide the users according to skill level so is this project is itself a going to be used by absolute beginners and is this something that and we know very very specialized API used by people who are already at very very experienced you know like you I'm talking about units and you know who were the people that I'm writing this content to make so this is also an indication of you're for users right so you can also do that I can also break down the users according to Geo and then assume that we don't have the doctor comparing like America's verses year courses at Asia-Pacific enough different people in different things 1 and so the next question is what they want know right so for example if I'm writing generals tutorial right I don't really need to give them the the entire history of life on and GenGO and like just getting into deep debt right you wanna get them the information just have information that they need right so if they want to get started learning about about Django fire the generals tutorial what sort of information they need so I will create a tutorial with a very very slimmed-down version and to be able to be digested uh more easily right so if I'm documenting that's a very complicated deployment like that of a service-based architecture is like OpenStack you know so there's a different level of information so and the next question is when they needed right so when I say when it's not necessarily like what time of day you know whatever but it's in the if you look at the life cycle of the usage of your of your software right so if we're talking about gender roles an example I'm an absolute beginner I've never use the thing before right or if let's say we had somebody in the help desk they came in and had a documentation structured at cross-purposes right so you want to if people come into your project for the 1st time you want to give them a bit of background on about what this project is for what they can use it why would they want to use it basis is the beginning and then when they could start when they get started and then they start using the software and then you can give them more common tasks that say like fellas who administrations some configuration and you know and then later on if they get into trouble right like what sort of uh when did they get to your content when they're doing this 1 and then expressions of course when so when I was talking about things like error messages and error messages are basically just another form of content and 0 well phrased informative error message is better than a tender 100 page troubleshooting might is if I can give the information right when the problem occurred that I've save the user a lot of frustration and I've made the user experience better right so if you're having few creating a command line tool you know you just wanna go man this you know this is right there in the terminal so this is aware of and also you know people naturally and after they tried everything I naturally revert to google right so hard way make my content available and accessible online for example or or or do I want to do in a PDF for some reason um but I mean the US's importance and so on this is a this time just kind of throwing a lot of questions because I'm not actually going to answer all of them because there's so many different ways of looking at it so and the last question is why right like why like why are you showing this content to me how is it going to fix my problem I was having this discussion a couple of days ago always someone said that bad documentation is just as bad as no documentation and I actually think that this is of course my opinion that bad documentation is worse then no documentation because if family and I got into a problem I need to find something in the documentation there is no documentation right this sucks right like but I realize that the Sox within like maybe a few minutes and then if there is a bunch of documentation and it's wrong and down the read the whole thing is he taking like and 10 20 15 minutes and then I'm going even more frustrated so why am I writing this like 1 of my solving here right mean what was so so for example if we're writing as and installation guide you wanna get your all the prerequisites you wanna find out the information and then if you deploy it and then you need to know where you can go next as well so this is the kind of question that actually puts all the previous questions to test and sometimes it and covers a different problem right so if I have to write a big big document that troubleshooting for FAQ and it turns out that I'm just really documenting bugs me
1 a considered fixing the bugs so that we don't have to just stick it in the release notes right so this is a tricky 1 but it's very very important so not going to give a couple of examples um I wish to give more examples but there's just like so many other practices sit and talk about solving and so the 1st example
I wanna talk about is user role-based and breakdown of content and this is the global human rights and what I love about it is the 1st thing you see when you go into the
no help help that no project .
org other than the fact that you see above or I see what can see this by the hundreds of years but thank you very much so I I just I was
looking for and like you this problem of users and administrators and theoretically
is supposed to have developers he writes I need to find issue for them and so the 1st thing you see is gone as to who will argue I should put Alice in Wonderland caterpillar mean here and so who are you right I'm
and then affirming user I click on users and then I go to a a browsable sort of categorized them only library OK and the according to what it what to a type of activities I'm doing the best they say gives you the information that I am most likely to look for as as a user and and if I'm an administrator then these are basically the administrator only administrator specific the documents that I need so I need to worry about how to you could figure right e-mail or install a new part software through the solver collections or something like that like this is the thing that they will confuse users and if I throw all that stuff in there the administrators of the lectures just give me 1 in grade and then you have the developers we have the development and there you have the PIC of the platform
demos so this is a really nice example of how to use persona based a role based on information delivery and so the Arch Linux Wickens means people who knows is and what I like about showing it as an example is that everyone
receives about this week and I've been hearing about this since I started going to events and and at 1st glance it looks like a mess right and I'm thinking to myself why right because of that and use actually links and you know I'm still a triumph Linux User in training but I so I'm looking at this and going why it is a of this so much and then I realized the only thing they care about is this right because then I realize this by the time that I get as an archlinux user that it to this wiki have already tried everything I could possibly think of myself right and try Google whatever so I go to this thing already knowing what I want more or less or at least have a few keywords in mind and a wiki doesn't have to be browsable right a wiki-based is not meant to be hierarchically structured right so it's pretty flat have anyone who know tries to manage the documentation and for a more broad and source project like and Fedora this kind things and it's tricky right when you're trying to
address a more broad audience but I don't care about this I will find when I wanted to find fast and yeah so now many of the
example of the use of structured and conciseness and so on 1 of the things that were working on this is the size of because we're was a very kind of heuristic self-reflection attitude and for so in OpenStack
all our documentation is available publicly and customer portal so if you see here it starts off like OK I have like every time you know every link here is a different guide and them and have the release notes but then you know you're
starting to kill more complicated a litmus singularly Holland to before officially 7 upgrading guides and then the Getting Started section is so long I consisting of 2 l where where do I go right so this is actually something that we're working on her head so we're at the moment as we speak you know reviewing everything we have right so it doesn't really matter if you're just starting with you project with yourself a project or if you've been doing this for a a very long time there's always something to improving there's always there's it's never too late to also look back and improve what you have and 1 actually to fix this we don't have to change any of the content of the guides they always do is look at what he's got to talking about how do we break them down and just sort of dump everything in 1 pot and reorganize so working on that and you wanna follow it you can see when the next version comes out at some point so the 2nd
thing I wanna talk about and that is I wanted to use talk cops
but somebody trademarked it and so this be so develops redox is a concept that we've been kind of kicking around other documentation community for a little while some and some of the things are some of these practices have been around for a long time some of them are just starting to sort of come to light but the basic concept of it is that were borrowing terms and practices methodologies from the engineering world and applying them to documentation rate so if like before innocent long gone are the days of a word processor to a printed PDF right like we don't do that anymore but if we can help but because it's a lot of it it's very restricting right so the 1st thing on talk about is the unified toolchain and so for example we had a lot of people come to and help testing like you know which tools are which markup languages which publication tools should I use and the 1st thing I ask is what's your language what technology right like so if it's Python of this whenever right so like in order to make the most out of the documentation to willing we turn to the engineering we turn to the developers and we see what you use you know how do we integrate the documentation authoring and publication into the development cycle right so it makes it easier in a city because you can just added documentation strings in coded and then you can docket right or you can download at or whatever it is you want there's so many tools out there that can just hook into your code and extraction documentation you know not sysadmin you have like get help users get up to document have like there is there it's in this talk about it and write about sports and so to be able to kind of dog food your own engineering tools and so it also things like tracking you know to be able to get the documentation type issue in your bugs 11 right or or deer or whatever it is just using the same platform to tract documentation tasks that sees a lot you know because immunity otherwise people just like many males if you can review it or whatever so we're and that we have a lot of um every product has whatever tracking platform for issues and we have our own documentation projects for some of them and so are engineers are users and they can open issues for us right something for open source projects a lot easier because most of the time it's on the same place but in the enterprise world really big deal with that and so on and then we have things like continuous integration so every time you know make a commit and rebuild the library checks for you know you can check for broken links check for you know sanity all these different things and and iterative authoring and like I used to be ScrumMaster I'm probably never going to stop being Mr. entirely so it's always going to kind of a company really whatever it is I go and I just I hate looking at a giant pile tasks and I'd rather break things down into more manageable chunks of and this is also another thing is if you have iterations in your coding then integrate your documentation into that so like I mean if whether you're working like Sprint plus 1 and or or making a documentation of the feature actually a requirement to deliver this feature right I mean I know that more I have been hearing more more about projects that I really do implement peer-review 4 . 4 the content as well as the code knots that many yet but hopefully I will talk about this in a little bit few can increase engagement of the community in the project so that things like that can actually help right so this is I'm talking more like more infrastructure and which will in the the community involvement
so content curation or as we call is in college sharpening your access and so on when I went to I didn't know that activations rent with a good mix us and I went into the documentation library which basically had like 4 guides each guy was like 1 2 and 5 XML and like with it was just it was it was scary for me and I have been writing and offering an XML for like 6 years so I can't imagine like if somebody wants to contribute something to it then i'll just another just drop the computer and with screening so like things like that so what we did is I I broke down this gigantic XML file into topics in files and it is organized in a hierarchical way His so people
wanna contribute then the source files were carried out in a way that's more modular right so if you go to the next rest documentation on GitHub then you can see the 4 main guys have that kind of structure so you can move things around if you have features if you want to break it down some more manageable and then you have automation which I love
because I'm lazy have so laziness is the mother of automation and and when I say automation documentation context I don't just mean like things like a continuous deployment which is more critical for the bigger sort of projects and some you know if you just have a wiki-based or forget have read then you have continuous development congratulations to an but things like automated testing for documentation and
not just for code examples because good examples can be tested with whatever it is that tests your code right so it's the same thing but you have tools
like Hemingway and amended and also a sublime plugin from 1 of the I think I hear about more and more tools like that they want to fix your grammar for you but don't tell you how what you need to fix right so because we deal with pros and not with code there isn't it isn't as straightforward as you know successful built rate so if I write a paragraph and it's really clumsy and long and has a lot of like it's in
a concise and ambiguous and then you have all sorts of tools and I'm and I'm going to post with the slides and a postman 2 links and because just want to get through a lot of the so you have a lot of tools that can report things like you know that this sentence has a passive voice or but if I rights the phrase in order to have you know some tools will tell you you don't have to use 3 words to to say something to say what 1 word which is good because a but you're not wearing your readers out by making them you know it's it's it's not a novel right like you don't want the point is to at the functional but its functional English right like sentences to serve a purpose and the subtitle of this talk is keep it simple present and present simple is the sort of golden standard of technical documentation so you can do this yeah this window opens you know it's all very very simple and the reason for that is that you know what you're talking about is more important then you know impressive writing expressions racism expressive language and so these kind of tools I would love to see more collaboration more
innovation around it so if you can use Google all the tools of all the things that I will post and I think there is equal and they can be integrated into a lot of different existing infrastructures and OK so and so the 3rd thing that I wanna talk about
is basically the community engagement and the contribution engagement and how do we make how we make how do we Help the documentation improved by engaging the people that we work with care great so in this context an we have seen
that a lot of many times you know the people who work on these abuses pleasure like yeah know I wrote this code but only if the name to write vision but you know how to so what 1 of things I do and end and so my contemporaries do as well as we go and we try to show that's a it doesn't have to be such a tedious time investment so even just a little bit of forethought the things like asking the right questions or just thinking little bit about the infrastructure and how you're integrating into the development cycle right so all these different things and outreach efforts and is 1 of the things that we do that we can do and so
I'm going to a few examples of the types of activities that you can do in order to increased engagement from a community here for a project from contributors of course is not conclusive and there's lots and lots of things you can do but these are kind of the things that I have personally and from talking to people have seen that had a good impact so um of course and you're welcome to experiment and explorer and so the contribution guidelines is things like when you want somebody to contribute to documentation how they do it right so just like when you have how to contribute to the code of a project just if you invest a little this time in figuring out and up and optimal contribution workflow forces are effective contribution workflow for your project it's going to be very helpful down the line that so just as an example and we wrote this and so I think it took us less than half a day
like any like a few hours at most and and it's like 0 1 wiki page on how to contribute to the documentation and has you know what I need to do right so here are the steps that I need to take in order to compute documentation than others and they do and I hope that helps in MAI it doesn't seem to to have been talking to them a little bit over the last few months um but um so this type of investment that can be just a few hours and you don't even have to collaborate on array like if you just figured out how to contributes or change something in the documentation of a project right to have you know and then it'll help others and then you will have to keep doing it yourself and so this is kind of this is kind of uh pre-emptive delegation or been scalability so another
goods the trick is to use templates and the template is
worth a thousand words I've seen you 1 of the examples I love use what is the redox reading templates um and they keep you was like this is really like I would literally go this is a nice mute region where to get that they live in like you you know so even if you don't necessarily have a template if you could just point out the topic or a file for for 1 of your pieces of documentation that you think looks good and that the project degrees like so last year Python we're working on a plan reading and and and they basically are using that as a template for all of the in the evenings and so all need is used to get something once looking right and then you can use it but you can reuse it and use it as a basis later and so things like
collaboration in training you know all these engagement so these are are things that are obviously easier to do when you are the person and so what we do things like us
Princeton access for
documentation and so this is from last year's your Python we mutagenic stocks sprint um and that this is Defcon and they did a workshop about differ system and Jenkins for docs and so these are all activities and that's from hot Fedora so these are all activities that are done in developer conferences right so going into the sort of more broad general open source to community and really helping to educate and coaching training meant to it it helps I mean have I and we had a help desk for this was to be 3 hours and have been 4 hours because we had so many people come in and you know I I love the fact that that the open source community is so open to receive these things but you know if if if the writers and and developers we can all get together and cross-training and share their knowledge so these are good examples of how to do it that so even if
you're not a writer and you have a sort of the newer generation of documentation conferences so as some people probably might remember the Society of Technical Communication STC and which is kind of like your grandfather's conference and and but you have compasses like the docks like open help and you get sort of pop up for ad hoc documentation conferences as a part of of a bigger conference so open-open right the docs are like that of the 2 most popular a documentation communities open up is more focused on sprints and right adopts is more about we have conferences we have meetups as well and the people come to these events are not just writers in fact we probably have like maybe a 3rd of our attendees right Adoxa writers and and then the rest is know split up between the split up between you know developers sysadmins community managers and project managers we got you know uh marking people like you have everybody coming into the same space and talking about content right so but with a
conference coming up next month and product open help has at the next conference in September it's in Cincinnati and and so these are exactly the kind of places that AI would feel at home as a writer and you know of anybody can enjoy because the developers can learn about how a writer think you know and these you know the the project managers can learn how to integrate between the different roles and everybody wants to improve the documentation in order to Help the success and the adoption of the project right because I mean everything is so we have such a huge amount of information that is and the so many project projects so many technologies Hartigan and make it stand out right so if the 1st thing that I see is you're get have read me you've had a make it friendly you know like I you don't want to you don't lose me so early in the reading is the documentation as well so whether you are a squirrel
a badger the beetroot or it can be there you know everybody can care about content and you can care about it in your own way based
on your own role and you don't have to do it alone because there's no you know hopefully there's always going to be someone from a different role that you can collaborate with and so we have questions thank you
and things we've looked like
7 minutes for questions so if anyone wants to us please keep your hand right now modem also out afterward and I thank you very much for this control and given that you're a scrum master I was wondering if you have like iteration and documentation as well so if you bring for example the to or to you basically and make him prove flautists prove your documentation at this
way asking is do we develop documentation and use the same stages as software development here in a sense so if you if you do sprints on documentation so will your product on on the be at a review meeting and say well I don't really like this kind of documentation on the specific feature and you go to model of iterations in OK so that's a that's a good question I did actually focus on that so much because of some it's more I think applicable to the are the enterprise world rather than the sort of small project world but for example I read that we have content strategist who basically act as product owners for the documentation and just like you have um in a release waiting for release planning you have the you know the engineering lead the QA lead the support of the design privatization etc. so I have someone from documentation also in this makes right and when we plan the content strategy for the next release we collaborate with all of those people and come up with a plan and then the content strategist will pass it on to up documentation program manager who's gonna like right so be like the engineering team leader and they would distribute the word and that break it down into iterations are tasks that specifically for iterations and all do is because the doctor the requirements the tasks come up to us already pretty much farther out and so we have a basis however many times we are faced with going to document this feature and then by the time we get to document the throughout the development of the feature for each hinged pretty drastically so we have to do a lot of research so before I actually go to document something I will normally the contact the engineers who developed it or the QA engineers tested to see I look at test plans and I look at specs I look at my blog posts just document something like whole I'm linking to do this and engineers like wrote a blog post about like and you can also so these kind of things helped write blog posts and then send them to your writers because we love that some and then will do is we have so this is I'm talking for most companies that have worked for so far have used a similar process so we'll drafted draft content send it out for uh what we call tech review on a review and then will send it out to peer-review with other writers and so you can have like a 2 steps authentication and your docs before they published and so I hope that answered your question 1 of 2 years
reduced for public facing the conditions what doing what follows the 4 general condition do you do stuff like A B testing to see if 1 way of doing it works better with the clients people use the value of something and the other half OK or even like become analytics on the set of OK so and a lot of these
practices are being implemented to improve processes that don't really work so well for that we can improve right so if we have like for a company like Red Hat a a lot of the bigger companies have different about products and a lot of that you know stuff came from acquisitions and some of its upstream or whatever you can test out the same like if I show you this document from that you can do that but will will will will do specifically now is we've implemented something called a closed-loop program where we actually reach out to customers and we say he give us some feedback on our documentation like would you like what do not like do you like the way that we construct these tutorials or you know do you wanna see some architecture guide you know you see more code more deployment examples you know so we do communicate and with our users and also with the communities because all kind of linked together right so for an open source project users are you contributed right so and most of of the time from what I can see they can be pretty vocal about what they like and not like right so you normally don't have to seek out feedback from your users because they will they will tell you how you know but it is it it is something that we try to implement as well I
was just wondering thank you talk was was very nice of the where it is the thing that I guess multiple organizations which is done this have you seen that organizational position of all false documentation and documentation related to this change because them for example it now and I go and look at the documentation for gluonium the bigger company would want to promote a product it's more in the marketing area of things of event for the people who when you right so it also
depends so thank you so would be it also depends on and on we're audiences right so if I write for developer products then I wouldn't necessarily have it under the marketing organization that so for most of my experience the technical writers have always been under the engineering organization but about its here and have ghostly and at Red Hat we actually got moved to the customer experience engagement ring and so we are in the same that so this is the 1st time that the technical writing department for the organization is in the same place as people who deal all the way to deal with the customers to support an account managers and so we've been moved from like hiding and we know behind behind the engine used in the that actually being more of a 1st class citizen 1 and I know that it depends on here I can't really speak for things like Google or or other companies that are in with the extraction is a but but yeah it's it's tricky it's tricky because I've seen some technical documentation websites and really more been just like a marketing feeling like you really gotta have that clear separation because if if if the the sort of the more hardcore users are going to get very disengaged if you try to you know so moments of we give the marketing of an answer to so this is the last Wednesday
and I like it when the problem is right to as much a condition as possible because it actually makes the code better b the think about it and they maybe just the good but what is the time to move on your professional looked
at really tricky distance so the 1st of all I perfectly agreeing that developers can right documentation for the components of the software that they code to a certain point right so if you have a smaller projects and it's that doesn't have you know so it's as long as I can I can't answer that because you have to see for yourself like it's a case by case basis but once you start having more than a few components that have to integrate at in order to create a solution right so once you move from just 2 pieces of software to something more of a solution or a collection of services are components then you start running into problems because most of the developed world's will focus on 1 component or 2 components of not a whole lot of integration coding uh normally happens I mean I don't know obviously no I'm sure the people who and places to do that but I haven't seen this personal and 1 of the things that have an advantage of getting a professional writer or someone who is even take 1 of the developers is more has a broader view so if you're if you live inside this component is in very hard for you to think like a user right and as a developer you're not being paid to think that implications giving way to think about right so like when we look at the whole scheme of things you know you don't have to worry about that because now you have a writer that can help you sort of group everything together so I guess that's the closest thing I can say to recommendation and you know it would be nice to have 1 writer for every 10 or 15 developers most of the time it's more like 20 here but but yeah I mean this used to be the sort of guidelines and but I I'm sorry if I couldn't answer your question more you know you have a magic formula so but thank you were to lose the energy method might be
for the book and the reason this
Schnelltaste
Bit
Transinformation
Zustandsdichte
Benutzerschnittstellenverwaltungssystem
Gerade Zahl
Red Hat
Vorlesung/Konferenz
Computeranimation
Metropolitan area network
Transinformation
Zustandsdichte
Benutzerschnittstellenverwaltungssystem
Benutzerschnittstellenverwaltungssystem
Open Source
Red Hat
Vorlesung/Konferenz
Projektive Ebene
Softwareentwickler
Hilfesystem
Office-Paket
Rechter Winkel
Prozess <Informatik>
Selbst organisierendes System
Software
Computeranimation
Eins
Metropolitan area network
Uniforme Struktur
Minimalgrad
Software
Rechter Winkel
Mereologie
Systembereichsnetz
Vorlesung/Konferenz
Inhalt <Mathematik>
Computeranimation
Schwarzsches Lemma
Verschiebungsoperator
Subtraktion
Biprodukt
Bitrate
Code
Computeranimation
Uniforme Struktur
Regulärer Graph
Rechter Winkel
Software
Konditionszahl
Basisvektor
Benutzerhandbuch
Projektive Ebene
Inhalt <Mathematik>
Hilfesystem
Zeichenkette
Fehlermeldung
Metropolitan area network
Uniforme Struktur
Skalierbarkeit
Software
Programmbibliothek
Projektive Ebene
Extrempunkt
Kombinatorische Gruppentheorie
Menge
Ereignishorizont
Quick-Sort
Computeranimation
Zustandsdichte
Extrempunkt
Softwareentwickler
Quick-Sort
Computeranimation
Subtraktion
Bit
Versionsverwaltung
Familie <Mathematik>
Schreiben <Datenverarbeitung>
Extrempunkt
Term
Computeranimation
Homepage
Übergang
Task
Arithmetischer Ausdruck
Bildschirmmaske
Einheit <Mathematik>
Software
Geometrische Frustration
Radikal <Mathematik>
Elektronischer Programmführer
Indexberechnung
Inhalt <Mathematik>
Softwareentwickler
Ganze Funktion
Konfigurationsraum
Korrelationsfunktion
Hilfesystem
Metropolitan area network
Softwaretest
Videospiel
Systemverwaltung
Dichte <Stochastik>
Quick-Sort
Programmfehler
Uniforme Struktur
Datenfeld
Betrag <Mathematik>
Rechter Winkel
Geschlecht <Mathematik>
Dreiecksfreier Graph
Basisvektor
Strategisches Spiel
Web-Designer
Projektive Ebene
Computerarchitektur
Information
Fehlermeldung
Systemverwaltung
Rechter Winkel
Vorlesung/Konferenz
Projektive Ebene
Inhalt <Mathematik>
Hilfesystem
Computeranimation
Arithmetisches Mittel
Laufwerk <Datentechnik>
Systemverwaltung
Systemverwaltung
Vorlesung/Konferenz
Extrempunkt
Softwareentwickler
Computeranimation
Demo <Programm>
Systemverwaltung
Extrempunkt
Systemplattform
Quick-Sort
Computeranimation
Gradient
Metropolitan area network
Software
Datentyp
Mereologie
Elektronischer Fingerabdruck
Information
Softwareentwickler
Wellenpaket
Rechter Winkel
Open Source
Adressraum
Projektive Ebene
Binder <Informatik>
Wiki
Computeranimation
Heuristik
Elektronischer Programmführer
Euler-Winkel
Extrempunkt
Binder <Informatik>
Datenstruktur
Computeranimation
Endlicher Graph
Softwareentwickler
Punkt
Momentenproblem
Versionsverwaltung
Extrempunkt
Quick-Sort
Computeranimation
Metropolitan area network
Zustandsdichte
Garbentheorie
Speicherabzug
Elektronischer Programmführer
Inhalt <Mathematik>
Normalvektor
Sichtbarkeitsverfahren
Bit
Subtraktion
Desintegration <Mathematik>
Beschreibungssprache
Formale Sprache
Iteration
Extrempunkt
Term
Systemplattform
Code
Computeranimation
Task
Iteration
Hook <Programmierung>
Datentyp
Mixed Reality
Programmbibliothek
Elektronischer Programmführer
Inhalt <Mathematik>
Softwareentwickler
Softwaretest
Autorisierung
Softwareentwickler
Knoten <Mathematik>
Open Source
Kontinuierliche Integration
Elektronische Publikation
Bitrate
Biprodukt
Binder <Informatik>
Quick-Sort
Programmfehler
Zustandsdichte
Rechter Winkel
Dreiecksfreier Graph
Projektive Ebene
Ordnung <Mathematik>
Textverarbeitung
Unternehmensarchitektur
Zeichenkette
Softwaretest
Desintegration <Mathematik>
REST <Informatik>
Quellcode
Kontextbezogenes System
Quick-Sort
Computeranimation
Iteration
Uniforme Struktur
Zustandsdichte
Rechter Winkel
Vorlesung/Konferenz
Projektive Ebene
Datenstruktur
Softwareentwickler
Analytische Fortsetzung
Softwaretest
Iteration
Rechter Winkel
Desintegration <Mathematik>
Güte der Anpassung
Formale Grammatik
Plug in
Extrempunkt
Bitrate
Code
Computeranimation
Lineares Funktional
Punkt
Desintegration <Mathematik>
Formale Sprache
Binder <Informatik>
Quick-Sort
Computeranimation
Rechenschieber
Arithmetischer Ausdruck
Kollaboration <Informatik>
Iteration
Zustandsdichte
Rechter Winkel
Bildschirmfenster
Vorlesung/Konferenz
Wort <Informatik>
Ordnung <Mathematik>
Standardabweichung
Bit
Subtraktion
Zustandsdichte
Dreiecksfreier Graph
Vorlesung/Konferenz
Extrempunkt
Softwareentwickler
Kontextbezogenes System
Maschinelles Sehen
Code
Soundverarbeitung
Bit
Minimierung
Güte der Anpassung
Computerunterstütztes Verfahren
Wiki
Code
Computeranimation
Skalierbarkeit
Forcing
Rechter Winkel
Datentyp
Projektive Ebene
Ordnung <Mathematik>
Hilfesystem
Gerade
Template
Güte der Anpassung
Automatische Handlungsplanung
Extrempunkt
E-Mail
Computeranimation
Minimalgrad
Zustandsdichte
Gerade Zahl
Basisvektor
Projektive Ebene
Wort <Informatik>
Lesen <Datenverarbeitung>
Kollaboration <Informatik>
Wellenpaket
Open Source
Vorlesung/Konferenz
Störungstheorie
Physikalisches System
Softwareentwickler
Hilfesystem
Quick-Sort
Offene Menge
Subtraktion
Zirkel <Instrument>
REST <Informatik>
Systemverwaltung
Biprodukt
Ereignishorizont
Raum-Zeit
Quick-Sort
Computeranimation
Generator <Informatik>
Datenmanagement
Zustandsdichte
Rechter Winkel
Offene Menge
Heegaard-Zerlegung
Projektive Ebene
Information
Ordnung <Mathematik>
Softwareentwickler
Drei
Hilfesystem
Lesen <Datenverarbeitung>
Red Hat
Vorlesung/Konferenz
Inhalt <Mathematik>
Extrempunkt
Computeranimation
Prozess <Physik>
Web log
Automatische Handlungsplanung
Iteration
Schreiben <Datenverarbeitung>
Computeranimation
Task
Metropolitan area network
Informationsmodellierung
Datenmanagement
Inhalt <Mathematik>
Optimierung
Softwareentwickler
Softwaretest
Red Hat
Biprodukt
Fokalpunkt
Quick-Sort
Modem
Verbandstheorie
Rechter Winkel
Basisvektor
Strategisches Spiel
Gamecontroller
Authentifikation
Projektive Ebene
Unternehmensarchitektur
Softwaretest
Rückkopplung
Prozess <Physik>
Open Source
Red Hat
Analytische Menge
Biprodukt
Code
Computeranimation
Client
Konditionszahl
Vorlesung/Konferenz
Projektive Ebene
Computerarchitektur
Elektronischer Programmführer
Optimierung
Web Site
Momentenproblem
Ortsoperator
Selbst organisierendes System
Mathematisierung
Klasse <Mathematik>
Red Hat
Schreiben <Datenverarbeitung>
Biprodukt
Quick-Sort
Ereignishorizont
Computeranimation
Unterring
Datenmanagement
Flächeninhalt
Vorlesung/Konferenz
Softwareentwickler
Sichtenkonzept
Punkt
Gruppenkeim
Red Hat
Nummerung
Quick-Sort
Code
Computeranimation
Ausdruck <Logik>
Integral
Energiedichte
Dienst <Informatik>
Software
Rechter Winkel
Basisvektor
Codierung
Vorlesung/Konferenz
Projektive Ebene
Zusammenhängender Graph
Abstand
Softwareentwickler
Ordnung <Mathematik>
Roboter
Red Hat
Computeranimation
Software Engineering

Metadaten

Formale Metadaten

Titel FOSS DOCS 101 (keep it simple, present!)
Serientitel EuroPython 2015
Teil 106
Anzahl der Teile 173
Autor Ariel, Mikey
Lizenz CC-Namensnennung - keine kommerzielle Nutzung - 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/20169
Herausgeber EuroPython
Erscheinungsjahr 2015
Sprache Englisch
Produktionsort Bilbao, Euskadi, Spain

Technische Metadaten

Dauer 42:36

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract Mikey Ariel - FOSS DOCS 101 (keep it simple, present!) Does your open source project need better documentation? Do you wish that new users could get started with your software more easily? Do you feel that your code contribution workflow isn't documented well enough, or that contributors are discouraged from documenting their code? How can you give your project docs the love they deserve? This high-level talk aims to introduce the main principles of technical communication in the context of FOSS projects. It is intended for anyone who interacts with docs, whether your project is fresh off the dev environment or has been around since the dawn of Git. Topics include tone, style, process management, structure, and contribution workflow.
Schlagwörter EuroPython Conference
EP 2015
EuroPython 2015

Ähnliche Filme

Loading...