Aura Christians 커피 ni wwn ni. Aunga, eurangodlau anusatio,よji? Aunga, eurangodlau anusatio? Aunga, eurangodlau anusatio. Aunai, miw yma ycan langa. Aunga, i alumni, ndrubuo. Aunga, miw yma, achbarnia maenai rai amorau vanu apunia i dunga, ndi rangunatio, te aile kori gweldi ndrubuo, aunga, i hasu āli tuwa, gawai kajuta delawe. for the most part about the board and those own little thing with version control but for the most part these concepts will get you into version control. When I first got into version control it wasn't a container it was something called subversion the ideas I found as a learning curve and the entry point and to get a version control very hard and confusing especially if you come from a background, more as a front-end sort of person and you are sort of moving to the development space whereas really you are just expected to know this stuff to know the stuff and you have all this, these jargon of staging files and committing them and revision control and fast vision control and source control and trunks and you go, what does all this stuff mean and it's very hard to get into an entry point. So I work for a small business called Communica, I'm the developer there and you know we build sites in Drupal for the most part, there's a few other stuff we use. I haven't had the honour to contribute to Corge yet but I'm quite active in the contributed space, a lot of patches, I'm the maintainer for a couple of modules up there. The commercial account to account, which is the main one, is a DPS payment gateway even here in Aus, quite large in New Zealand and then an analytics firm in the UK. So vision control doesn't need to scare you. It's actually quite a simple concept and all vision control does, in the simplest terms, attract changes to files, specifically text based files. files so if you if you've ever used revisions in Drupal or nodes and you've turned on the diff module and you click that little button and what's changed and it shows you something like that that's version control at a code level nothing more nothing less it's worth mentioning that version control only really works well and text based documents so stuff like php files module files css files those kind of things even though you can stick binary based files in there like zip files or compressed files image files it'll track those changes but it will track the file as a whole it'll know that the file changed but it doesn't know that all the red pixels were slightly shifted to a darker red shape it'll just track the whole file so but on on a on a layer of text files it will track you know text changes pretty much what you see the red got removed the green got added so when you're comparing get to other larger um version control solutions probably the biggest one out there would be subversion or svn they're essentially the same uh get works quite different to those those other servers those other version control system uses something like a centralized server so if we were to do anything significant like you want to develop a new branch and i'll explain what those things are a little bit later but you've got a new feature that you're working on you have to have a connection to that server to do it just like if you want to be a website on the internet you need a connection to some kind of web host to make that work so get works different it works local so as soon as you make a copy of the vision control repository which which is the bit that tracks all the changes you have everything local all the history forever so if you like clone down Drupal from from Drupal.org you get all the changes tracked from Drupal 4 and so it's insane how much data is there so that that's a good thing a bad thing you can clean that up over time i mean if you take like the span of Drupal there's thousands and thousands and thousands of commits so that transparency is really a good thing because you can see how stuff changed it's not particularly useful to have Drupal 4 in there admittedly especially since we had seven but when bugs are discovered you can quite easily see how that came to be so because everything is local and you don't need a connection to any kind of server get is insanely fast to compare general tasks like merging complex branches and features to SVN when you first start using get if you've got experience you think something went wrong it couldn't possibly be this fast but it is each feature branch that you create each copy that gets created from version control is a backup in its own so if you've got a production branch which has got all your stable code and you clone that into some new my awesome feature that i'm working on you get all the history from the other branch so each branch surfaces serves as its own backup as well so this is really unique to to get there are other systems that do this as well but it's the idea of distributed version control and so if i have a copy it's like i mentioned just before in the previous slide really if i have a copy i have all the history for that project if you have a copy you have all the history of that project so the entire version control repository is distributed throughout all its users and that's a pretty cool thing because it means that you've got great concurrency you can have many people working in their own type of workflows on their own kind of computers until they ready and say yep this bit of stuff that i work on is now ready to contribute back and so you can do that so it's incredibly flexible from the workflow perspective because it's got its own distributed nature these sort of this distributed nature is simply not possible in svn like if you're on the plane flying somewhere you've got a 10 hour flight and you go well i've got some time to kill hey i'll work on this this bug because you haven't got access to like svn centralized server there's nothing you can do you can sort of like do your changes and then copy those changes to another file and eventually when you connect up you can do some kind of manual thing to go and fix it up but and and get us just simple tasking it's just that simple so branching is the idea of of that any development track can have branches that spawn off it so if you if you think of a of a tree and this is actually how get documentation explains this themselves is that you've got the tree trunk which is a stable branch and then you have these branches that shoot out from the trunk that describe a development track or it could be a feature track or a bug fix track or any kinds of those and even off those tracks you can branch off them so you've got quite a bit of of flexibility when it comes to branching and because how get handles its branching it's cheap it's quite easy to go and drupal and say oh well i want to try this idea i have and css that you don't know it's going to work so if you just create a branch you try those ideas out and if it works you just merge it back into the development track and you're done but it's it's it's a very simple and easy task to do so workflows um um this is where things start getting a little bit interesting in terms of the options that you have pretty much it means that with get you can do any kind of crazy workflow you can have a deed simple workflow where if you're a developer by yourself that you just have one development trade one one branch that you work on and you just do commits against that branch and that's it you're done you can move on some bigger spaces if you like start working on larger projects that has a testing team or security team or one of those kind of things or or have some more more critical business needs where you know these are business critical functions then maybe you've got some some requirement we have got a junior developer that creates a feature branch because they're working on some kind of some kind of feature that needs to be implemented and they merge that up to the development track where maybe there's some kind of peer review system and so another developer can check over the work and if that's happy they can move that into um and this slide is called the release branch but it's quite often to call the testing branch where they can have a testing go and review those changes and then I can eventually move up into the green area which is master so master is just not Drupal I mean gets default naming convention for what's considered the production branch and so you'll see that a lot you you can change these branch names it's it's you just go sort of like green name branch and there you go you can call it live or production or stage or whatever whatever you like and you can also apply tags to the different release points that you have so you can see you've got you know 0.1 0.2 and this is essentially how Drupal does this as well this this is the point releases that you get on Drupal.org when you get you know 7.3 or 7.33 those are just something called get tags and it's a particular point in time where a commit is that got tagged as as a stable release so the the thing that makes get a little bit unique is the idea of staging stuff and truth be told I've never really understand why they called it staging because it really doesn't make any sense to the idea that before you can contribute a change to version control you have to stage change and really I think a better description is it's a pre-commit area so if you change the file you first have to change it as ready to be committed so it's like saying here's some changes I would like to make a snapshot of to go into version control so that will become clear when I go through the file process but it's like if I draw an analogy to your general gestop working environment you have a file and you delete it the file is not deleted it gets put in your trash can until you clear trash can that is essentially what it is you have a file that you're putting someone say hey I would like to potentially commit this and of course it's open source right and we all like open source I mean most of our stuff that we use in Drupalus open source the operating systems are open source the databases are open source so that's really a good thing so the inner workings I'm not going to get too geeky about this because it's an introduction and we won't get too technical but essentially when you add a file to version control and get you're creating an index file that says this is the state of the file right now and this is everything that's in that file from that point on into the future the only thing you keep track of is changes to that file so if you change one line of cse's the entire file doesn't get committed to version control again it's just like line number 18 change and it is now this and when you make another commit against that same file that same file it says line number 28 change and it's now this and because of this idea of having this linear pattern every change that you have is based on the previous commit that happened and so since every change is also checksummed and hashed you're never ever going to have a corrupt file it simply doesn't exist so it's incredibly secure from that perspective if someone goes on fiddles in there the entire repository would go something is not right and so that's quite useful if you look at some vulnerabilities last year Drupal Gettin that came out if you had your entire Drupal code base in in version control it would have been a simple command and you would have instantly seen what someone had changed in the file system and it would have been a simple task to roll back it's also worth mentioning at this point that Gett does not track changes to the database and so this is where the where the big pushes in Drupal 8 to try and move all that stuff into configuration management because like views are stored in the database content types are stored in the base everything's in the database and it's very difficult to version control data because if you export the entire database from Drupal it's this massive file and you can add it to version control all you want it's text base so that's fine that's not an issue but then when you do the new dump six months later you know you've got all the content tables in there and the way it relates it just doesn't work so version control database short answer is forget about it's not going to happen anytime soon there are some workarounds that you can can do and at the end of the the presentation i've got some some research you can look at where someone has worked on this a lot but it's not an amazing solution and this is where the features module for Drupal 7 certainly comes into place because you can take a lot of this configuration views content types and sort of like exported and it's some kind of of manageable code version of what your Drupal site is like so when you initially initiate a a empty repository in a project what happens in the in sort of like behind the scenes that you can't see there's this folder that shows up you can't see this folder it's hidden unless you've got show hidden files turned on it's called dot get and everything lives in there so if you ever wanted to delete the repository for whatever reason your local machine you just delete that folder and it's gone and inside that folder there's a whole bunch of configuration stuff and for each commit that it makes it creates an object with a hash value that's checksum'd like i mentioned before so git only has three states and those states refer to the state in which a file can be i know there's four on there but the one is in an dashed lines for a reason so you've got your working directory this is quite commonly called it will refer to as the working tree this is where all your files are this is typically Drupal root if that's what your version controlling everything that goes in that folder and it's children gets vision control unless you add an ignore file which makes which makes sense an example of why you'd want to ignore something like the files folder in Drupal you don't vision control that because that's user content and it's it's not really vision controls job to know about that vision control keys about the code base so you you know your vision control your themes your modules your custom modules libraries things like that that you add to the project a bit of argument can go into that it's sort of like what works for you some developers is vision control the entire Drupal and Drupal core and all the contributed modules other developers will say why vision control that's already why vision control something that's already vision control i mean all the modules in Drupal they're all because already under vision control so do you really have to revision control that i think it's a choice for your own workflow for us at communica we use multi sites for even a single site in the store so we don't vision control anything but what we know is is different so we only vision control custom modules custom libraries and custom themes nothing else i don't care about as far as i'm concerned views as vision control the radio i don't need to revision control that again so in your working tree you'll have your files and so when you change a file it will show up in the working tree and you'll see that soon in the next few slides that come up so once you're ready and you're ready to make a change you're ready to to record that change and to the get repository you move that file into the staging area like i said this is your pre-committer area you're saying is hey here's a change so i would like to record once just in the staging area you can then contribute that or commit that that change into the history and and that is just a log file that's all it is once you've done that you're working your working tree returns back to blank not as in blank as in these no files as in blank there's no changes to those files anymore so as soon as you edit a file again the working tree will show that hey here's a file that's changed and you change that file and you go okay i'm happy i want to now commit that you stage the file and then you commit then it returns back so in the file left you've got this stashing thing so the way get works as as soon as you try and pull changes from a developer let's say you've got a colleague working on the same project and the colleague says hey i fixed this bug and you know i would like to have that bug fix in in my code base too and you go i want to pull those changes into my working tree get it's going to tell you know you can't do that because guess going to go you have changes to your files and he has changes to his file i don't know how to merge those things together so the the solution to that is one you can create your own branch where you can commit those changes to and then bring it back into the working tree at the end or you can simply like do a stash and that's just like temporary save these changes outside of version control so i can bring them back in later it's not something you use a lot but it can come up so if you look at the the lifecycle of a file for an individual file for an individual workflow the process is always the same it doesn't ever change first the file gets created even when you go new file and sublime or php storm or whatever it's you're using you're creating a balanc file then the next stage change the next stage is to change that file in some way and that could be i'm adding code to that file it could even be um if it's some php stuff maybe you want to change the permissions and who can execute commands on that file any kind of state change to that file get will pick that up so you change the file then you have to add the file and that get add is literally the command you'll fire so you'll get add to the staging area and then you'll commit that change and then it's inversion control so at this point you're working in a tree you're working tree returns back to blank there's no more changes and then the process just starts again and that happens for every single file in your project change a file you add it you commit it change a file add it commit it and that does not change ever so if you blow this up to a team because so often so often we work by ourselves lots of times we have a team of people so we've got a son or a person here john which has exactly the same flow grads file changes it adds it commits it until some until until such a point that john goes okay i'm happy to now contribute that to the rest of the team so at that point he files a get push command which pushes his changes into it into a hosted repository this could be get bucket a bit bucket it could be github it could be drupal.org it could be git labs these plenty of solutions out there that offer us hosted service you can even run your own hosted service if you want to do some projects like geto light or get osis well can do that for you but you have to install that in the server and it sort of like becomes admin thing some businesses find that important that they say hey we don't want to share our code in any kind of hosted service for security reasons especially if you start working like i'm banking stuff and like you know serious financial stuff then they can get a bit of effe about that so suffice it to say you push that up to some kind of shed seed centralized place this is not to be confused with the same as a centralized server like version control because each version of your repository is distributed so what john has is an exact copy of what's in the hosted server and so you could technically log on to the hosted server and do whatever you like there and it's its own unique copy until that changed as pull downstream somewhere this is something you'll hear or read up a lot about push this upstream push that downstream and all that means is push something up towards someone or pull something down towards yourself so upstream is away from you so if you push it up to a hosted server that's upstream and if you do a pull you're pulling it downstream then jane comes along and she wants to work on the on the same code base as john did maybe there's a new feature maybe it's it's just collaborative and so what she has to do is she first has to clone it and cloning is is virtually the same as going to drupper.org and downloading the zip file the difference is with drupper.org when you download the zip file they don't include the version control references so you don't get that with but if you fire the appropriate uh get cloned drupper.org whatever the URL is then it will pull on all those references so in order for jane to realistically contribute to the project she has to clone the get repository so she clones it down and then she has exactly the same process as john she changes the file she adds and she commits it and she does that process until it reaches a state where she's happy and she can do that process in any kind of way that she likes she might choose to create another branch and do those changes in another branch until she feels she's reached some kind of stable state that she wants to contribute that back even if she did that on another branch and she pushed back let's assume she did that changes on on a bugfix branch and she decided to push that bugfix branch up and john didn't have that as soon as john pulled the changes he'll automatically get that branch but it just it just works it's just there so jane on this case will go okay i'm done with my feature i'm going to push it back i'm going to contribute this back so she pushes the changes upstream to the hosted repository and now john has the ability to bring those changes into his because the moment he tries and does a push the server is going to say hey look something changed in the server that i don't know about please commit your changes that you have right now if if john hadn't done that and do a pull so in this case he's going to do a feature and then do a merge and so that's quite commonly referred to as pull and there's an actual get command that's called get pull which is the one you'll probably use but it's just firing those two commands for you and concurrency for you so it'll first do a feature and then i'll do a pull for you automatically and yep yep correct that's right because version control doesn't know how to run that task on the server right it's not it's not the service job to know how to how to merge those changes for that we know uh jane and john edited exactly the same file and most likely they did and even worse they might have edited exactly the same line numbers so it'll then be up to john to take those changes from jane which is on the hosted server and go these are how i resolve these conflicts and it sounds incredibly complicated it's not really it's just going to tell you hey that the things don't match up please do a pull so you do a pull and then it's going to say either it's going to work successfully which is what happens 90% of the time and then sometimes it'll go look there's some conflict and then you have to go in and resolve that conflict and it's not incredibly difficult to do it it quite marks it out and and the code i don't have an example of it here if there's time i'm more than happy to show that uh but i will show that hey this is what it's before this is what it's now i don't know how to merge that and quite often it's not like like it'll be like a hundred lines of code it's like five or six and it's just like usually just go oh yeah that makes sense i'll just move this over here move that over there and then you're done yeah so get fetch sounds it's a little bit confusing it's not get fetch it says go to the hosted repository and this up there and there's a little round dot and it says fetch the changes and tell me what those changes are don't do anything with the changes just tell me if they are changes okay completely get status show you the current status of a repository where get fetches it says download the references that's changed in the repository and so we okay so get pool will attempt to fetch the changes remember it's not fetch it's it's just fetching it's just saying is what is different on your copy of their mind it doesn't do anything with that information just says tell me what's different do you have some commits that i don't know about and if you do then you can act on that where get pool will do a fetch that will go to the server and say fetch the changes tell me what they are and then try and take those changes and merge it into my into my working tree so get pool is just a shorthand for doing good fetch and then get merge manually yeah well get clone is just the process of getting the repository on a computer if she's done if she's done the first but she's done a get clone she can instantly do a get fetch right there and then good right now she can yeah yeah she has to first clone it to get it and then she can do a fetch and so because john gets that bit to fetch the changes and merge it so does Jane and so that process just continue and so whether there's two people working it or 100 or 1000 the process is the same it doesn't change at all so when the when we blow this up to the flow of how a project works like i mentioned earlier on gets very flexible with your workflow and i'm going to show three examples here these are the three commons ones out there this is typically what you have in a very very small webshop or just a developer by himself and you know we throw this term out there developers this is for themas this is for anyone who makes any kind of text based change okay it's not just for for developers who are hardcore people um so in this case the person has a development track which is the main branch that they're working on and and rolling out new new new features or scope or whatever they get asked to do and then the person might have a crazy idea and say hey i heard about this new awesome css compiler called libsats and i'm going to change my grid system to something else and so they'll go and try it out they don't know if that idea is going to work out they sort of like an a prototype being discovery phase and go is this going to work so a good way to do that is to create a separate branch and try that out because there's actually an arrow missing there as soon as the person wants to create another branch they'll create it from an existing branch so when you're working you always have one checked out branch which is what you're working on that could be your master branch which is production or it could be your development if the person is developing it's most likely the development branch which means at the point that they create a new branch they create a branch with all the history from the branch that they're creating it on so if i go get branch create and i've got development checked out i get all of developments copy and to my feature branch or if i was in the production branch i'd get all the code that's in the production branch and to my feature copy no it's required yep if there's a way to create a blank one i've not seen it because the whole idea is for this to work when you try and merge this changes up let's say this this feature worked out in this case it did because that change then gets merged back into the development track so whatever the developer did here work there was a great idea sometimes there was a crap idea you just deleted and so that never happened so in this case you get merged into the development branch and at some point it gets merged back up to up into production and so all those branches know about these changes you can see the feature branch got deleted because it got merged into the main development cycle there's no longer any need to have that branch there you have to do this manually you have to go and delete branch you could leave it there but eventually you end up having a lot of branches and then as people we're usually quite crap at naming things and you call it feature one something like that and so six months down the track you go what did this mean again so you typically delete it just just to keep yourself a little bit sane so if you work in a bigger organization that's probably the kind of flow that you'll have this is officially known as the get flow process i don't personally use it myself i don't find it all that flexible but it is very very well documented and is used by a lot of shops so the idea is that you have your main development track at which bug fixes and whatever happens happens right this is do this do that and then you'll get another person on board and they'll work in a feature that it could be considered unstable or it's just a new feature and so that person or that developer will work in that feature branch until such stage that they feel it's reached the stage where they can contribute that to the development branch at that point they merge it up into the development branch and since they're happy with it they can either choose to delete the branch which they probably will do in this workflow or they can choose to keep it and then right at that same point a testing branch gets created now they're quite often referred to this as a release branch as well and so from the testing branch they'll they'll get an independent tester or they have a test team or maybe it's just a project manager that does a bit of use the testing or whatever let's say they kind of find some kind of issue so the fix will then be applied on the testing branch because if you look at how the commit dots has worked that the feature branch no longer exists because it was considered stable and it moved into a development into the development cycle so they fixed the change on the testing branch and that's why there's a second dot so there was another commit maybe it would have gone straight up to the to the master branch it didn't doesn't need to be a second commit there it's just in this example there is so the idea with git flow is the moment it's moved to the testing branch all the changes happen on the testing branch and nowhere else because you're now in a state of well the code is semi-stable but we found a small issue and we need to deal with that so always happens on that once that has reached a sign-off point by whoever the the official is that makes that kind of decision it gets moved up into the production branch and it now lives in the production branch at the same time it gets merged down to the development branch again if you look at how that's worked clearly if it didn't move down to the development branch there would be a commit in the system that development branch doesn't know about so it has to move down once that happens the testing branch gets deleted if another bug is found depending on how critical the bug is there will either be another branch created to resolve that issue or some other kind of workflow will happen but of course you know as as as developers or or as the the the principle of that all software is broken is sometimes we screw up and we have mistakes so sometimes with this kind of process which is typically and mid to enterprise level level businesses that use it is that the process of getting anything deployed into production is usually too long because you have development cycle and then you know some peer review system usually and then a testing cycle and so if there's some critical bug and it needs to be fixed right now we need to account for that or need we need to account for that and so a great example would that be what was the Drupal get-and-hack so i don't know if anyone was familiar with that but that was pretty decent one right so you don't have the time luxury to deal with a whole development cycle to fix that so you need to allow a way to deal with that so what would happen is this would typically happen directly on the server because these are business critical issues that you would have to deal with so you create something called the hot fix branch you'll do this directly on the server you'll take you'll clone that directly from the production branch because that's your stable code base that you know and trust and you do your fix so in the example of Drupal get-and-hack you replace the database dot inc file which is where the vulnerability was moment you've done that you merge it back straight into production again so now your Drupal core or your your production version of that site is stable again and you merge that same information down to your development track so that the development development track has that change too you have to do it manually so if you have got continuous integration set up you can do that obviously not the bug fix thing because it wouldn't know about it and so but if you've got full continuous integration set up you can you can solve even that bit with continuous integration but doing continuous integration is really really hard and takes a long time to do very well so you'll find that most places just do this mean and go get-poorish login to the server get-poor or get-merge or whatever the commands are that need to fire what do you mean by that okay so so checkout doesn't mean um check out means return my code to a stable state so if you had a file that you changed and you go get checkout index.php what it will do it will revert whatever changes you made to the index.php to whatever version control knows that it should be does that make sense okay so so checkout is not it's not about I guess it is in the sense that you're saying is return my code to a stable state so the commands that's fired to revert changes or checkout changes is literally get checkout get revert and get reset those are the three you need to do and I'll talk a bit about them a little bit later so this is the process we actually use and this is not that dissimilar from from the get flow previous example but I guess it abstracts out the idea of independent deployability a little bit better so you know you scope out a job or you have an existing job and the client come back they never come back and say we want this one little change right it's always like 10 things and so you're going as well gosh these 10 things is 100 hours worth of work as you go well how do I independently deploy each feature on its own so because one of the task might be five hours worth of work and one of mine might be 30 hours worth of work you're obviously not going to finish them at the same time so the idea is that you clone directly down from from the green dots from the master branch the only reason I didn't include the arrows in theirs because it would have made the graph insane so you clone down from not clone down this wrong term you create a new branch from the development track from the sorry the production branch master branch and then you make the changes to the branch that you're working on so in this case we're working on a feature called related content and so you make all the changes just relevant to related content on the related content branch and only that branch if you mark up there are some things you can do to resolve it but it's really painful it just my suggestion would be it's just people disciplined enough not to do that because it's difficult to fix you might also have another developer working on the geo fencing thing which is a much bigger job to do so that developer is working on that branch and that branch only like you know your your front end people might be working on the infamous ie bug or you know someone might be working on some other bug and so the idea is that any point once it once one of these features reach a stable state you can merge that into stage so stage copy is typically the copy you show your client to get sign off on or for us it is anyway so the client usually gets accidentally go hey we've deployed this awesome geo fencing functionality go give it a test and the client comes back that's amazing and that means we can deploy just that change to production without having completed related content the ie bug or the um the other one the notice the notice error so it gives us independent deploy which is very very helpful i mean we've all had that and go well we can't really push this up because too much code change we have to do it on one big chunk and it just makes the project lag on so it's really cool to independently deploy these things if you can so gets is unfortunately a command line tool um at some point the reality is is you're going to have to suck it up and learn it um guis can take you a long way and in fact my my workflow is about 50 50 split about using a gui i am not a die hard person that sees no command line i can do all the commands and uh command line and if you don't have something like continuous integration set up the reality is at some point you're going to have to shell command into your server and run one of these commands in order to get it and at some point something is not going to work and you're going to have to fix something so you're going to have to learn it at some point that's it from a from a gui perspective there are some great applications out there uh there's not enough time and there's talk to go through them but some of the big ones out there is uh github desktop version there's one you can download directly from github there's uh one from atlasian called source tree that's pretty good tower is amazing i don't know who makes that however if you get tower i urge you to get version one version two sucks and it's just really cool right it takes this idea of creating another branch really easy it's drag and drop you take the branch you drag it up and it says hey would you like to create a new branch you go boy yes i do and it's done and you make your changes you commit it and you go hey i want to merge this and you just drag and drop the branches on top of each other and it goes hey would you like to merge it and you go boy yes i do and if it's if there's a conflict it'll put a nice big red dot there and say there's an issue in this file you can open that file and fix it and so i find those things really useful where from the command line perspective those things are a little bit harder to deal with but still very possible tower tower it's a mac only app so if you're on windows no luck yep uh there's some other ones these git box uh that's quite popular there's smart git or is this market i think it's called smart kit i don't like that one because they've decided that they'll change the terminology of git so it's difficult to relate that information into um into command plane when you have to do it and you go what the hell this is me so i'm not a big fan of that the the best one i've used so far is definitely tower but i hate tower two which is the one that currently selling so i don't know if you can still purchase version one uh sorcery is not bad either i've not really significantly used the github one yeah absolutely absolutely um if there's time come see me because i we're running pretty tight in time so um i can show that if everyone wants to stay a little bit there's no no no actually so the process of of doing that this is actually a real live example of the process that you do so i've got some kind of project it's just some pseudocode that i wrote and so the first thing you'd have to do is you first have to initialise an empty repository and so that's literally the command um it's the git anith command so i'll just go back one slide because i didn't explain this if you look at the top the git syntax is always the git keyword followed by a sub command it's the same for every single command those are the main ones you're going to use a net add commit log status so on and so forth those are the main the main ones and then quite often you can pass additional flags that's like additional little operators to the command for example if you do get log you might not want to see the entire log you might only want to show a short little log message then what you can do is you can strip out a lot of that content by passing additional flags to the command the first thing you'll do is you'll do a git anith which initialises an empty repository that just says hey i want to track the stuff in this folder and all its children and it's it's at this point that it creates that hidden folder that i talked about the dot git folder then the next but i'll show you here is the git status command and so that just says hey show me what's happening in my working tree has any files changed and so in this case gets quite good at giving you a little hints about what needs to do it sees on there if you see the little bit purple which is not all that readable it's going to say hey right below that here are some untracked files and you're probably going to use the git add command next because you've already edited the file you're at the point where you say is hey i want to contribute something back to my repository so next you're probably going to fire the git add command it also shows you the files if you've got git colors turned on a command line it will show you the the files and read which is untracked at the moment so the next bit is to add it to the staging area like i mentioned before you're going to get to this little pre-commit area so you're going to fire the git add command which just says hey i'm going to add it to the staging area so there are a few little different ways you can do it you can do git add dot so the dot and command line just means my current location so in that case it says git add everything where i'm at right now so if there's one file or 500th or 5000th file this is going to add the lot to your git repository you can also pass some additional parameters in this is most likely what you'll do you'll probably go git add the file name that you want or the folder that you want to add if you don't want to add everything you can go a bit crazy and you can throw some wild card characters on these here you can go git add star dot css which will only add the css files to the git repository so um here i fired the git add dot because this is the very first time i'm adding content into the repository because it's just still an empty repository until i commit it so it would make sense to add absolutely everything the first time this is very common so you do git add and if you then do a git status what you're going to see is that your file status are now to be committed so changes to be committed down the bottom and it will typically show it in a different colour for you and list all the files it will only list like the folder level it won't literally go into the includes file and show all those for you but they're there from the working tree so everything that's in the same level of where git gets installed it will try and do track all those files the whole lot unless you tell it not to which you will do in Drupal for example on Drupal you would exclude the files folder like i say that that's content managed areas you don't want to track all the pictures that people upload it doesn't wouldn't make sense to do that so that gets excluded quite often you would exclude your like your settings.php file in Drupal that's not something you really want to stick out on version control and say hey here's my username and password especially if you're sticking that on a public hosted service like github and you don't have a private repository probably not something you want to advertise out on the world so usually Drupal 7 is pretty good with including some reasonable defaults for ignoring files it will automatically ignore the settings.php file for you and the files folder but it's quite reasonable that you might want to add a little bit more in our own workflow we're at a local.settings file which is something we change dynamically based on the environment that it runs on so in our local development environment for example in our settings file we'll turn on all error reporting where in our production environment we'll make sure that that flag is set to false so that we don't manually have to go into Drupal for every production site and go turn error reporting off you can just simply turn that on and configuration files in Drupal so the next bit is to record the change to version control so we've now created a file we've added those files we stage them the whole bit so the next bit is to record those changes into the history so we'll do that with the get commit command I'm passing a flag there hyphen m just to make to make the the process a little bit shorter if you don't it's going to open up another little window where you can be a lot more descriptive about your message I always use the sort hand because I feel personally that commit messages should directly relate to what you did and so usually the short messages enough to explain what you did I'm not a huge fan of having big massive commits but your first commit will always be huge because you're adding all your files to the get index so very often you'll see the first commit is called first commit or initial commit or initialised get or something like that because you're not really interested in what change you're just really establishing that you're adding stuff to version control and it's only after that point that you care about change it's going to do a whole bunch of stuff there it's going to tell you how many files you're adding to a version control obviously in the case of Drupal it would be fairly a few more than two how many insertions there was and a whole bunch of stuff the only thing really worth mentioning it will all tell tell you what branch you've made the commit on in this case master and it'll give you this hash number that's the short hash and that is a unique identifier for that commit and you'll get one of those for each commit you don't really need to know it unless you want to look in what happened at a commit at which point you need to hash but you just do like git log and it will show you all the hashes and you then go and show the hash or show the show the changes against that hash so after we've committed it if you do the git log command it will show you exactly what it is you see the full commit hash which is I forget how many characters many and that's the 250th it's a it's a show a one hash for anyone who cares and it's checksummed and so it will show who the committer is and what date it happened and this is a great way I don't want to say to assign blame but if something happened in a project at some point there's another command you can fire git blame it was literally called git blame and you can see who edited what line of code when and so sometimes when you know you're working with someone to go I didn't change it for you oh we'll just check about that right so now you're going to this whole process of editing your files right you want to you know you write more css you add tpl files you do whatever you need to do in the project so I've edited my files if I now fire the git status command you'll see that no longer does it say new files to be added and now says hey these are files that change these are modified files and so it will again give you a little hinty you probably want to use git add to add this to the staging area once you're happy so what I'm going to do in this case is I'm just going to add the first one because I only really want to commit the index file changes here so I'll go git add index.php and if you then fire a git status you'll now see that you've got two states of files you have one that's to be staged or one sorry one that is staged and one that's still just known as modified but it's not staged when you get a little bit more advanced you can have the index file in both states so you can you can say I only want to commit this section of what was changed but that's that's that gets a little bit further on but it is possible so I'll then commit that change and if you do a git status then you'll see that the working tree from what I've just committed has returned back to blank except for what for my unstaged file because I get doesn't know what to do with that until I tell it to do that finally if you do a git log you now see you've got two log messages both describing those things and obviously they're both made by me so it can be quite useful when you want to see well what did I actually change in this file right you I mean you add you add spaces and maybe you indent stuff more so if you fire the git to git diff command which is what I did over here this happens on one line I just made a two columns for readability sake because I couldn't fit it it'll show you what changed and anyone has ever downloaded a patch of group of the org that's exactly what it looks like in fact that is exactly the command your file you'll just read it into a text file that is a patch file right there and then it says hey when you want to run this that's exactly what's going to change the bits and blue there the at at sign refers to the line numbers that changed like I said git only tracks what's changed it doesn't care about the rest of the file and only gets added once and then it just tracks the changes so we know that from those lines and exactly how they're related to the line numbers can be a little bit confusing but that's what it means those are line numbers that changed and then any of the little minus bits and read is what got removed from the file and the bits and green is what got added to the file then you can use the git show command to show what's changed at any given commit so since um you know you you might have a commit that's that's three weeks old and you want to go damn what did I change again I can't remember you can use the git show command and you can pass the hash to it you don't have to pass the entire full hash which is a lot of characters like usually five or six is enough and it will return that resolve here and that's exactly it again it's the same syntax as get diff in terms of what it's showing what got removed what got added so a few more commands is get reset so if you've done some crazy thing and you just want to revert the entire change that you've made um you can do get reset head and that head keyword is written just like that in uppercase and version control and that just refers to the current active branch that you're on so if I'm working in a feature branch and I go get reset head it means get reset the feature branch I'm on if I'm on master branch it will refer to the master branch and so it's just a an easy way to to call the branch that you are and otherwise you you explicitly have to say this is the branch I want to run this command on and if you've got 10 or 15 of these things that come become a little bit painful get push push is any changes upstream to a hosted server somewhere get hub get bucket one of those things get fetch we already talked about that literally just download the object references that changed from the repository it doesn't do anything with that information get merge takes those history that changes that's come in and merges it into your current working tree get pull just do those two things together for you so that's probably the one you're going to use and then finally there's some really good resources there obviously it's a bit of a boring read really as gets direct documentation I find but buckets documentation amazing that's a great place to go to wiki pedia has some got some good information on it as well I really like learning by video content so there's one um from nettoots it is a paid service but it's not all that expensive that will show a lot of demos of these commands and how they work and how to resolve conflicts and those kind of things and then there's there's an absolute great series by Chris Chattick from Brawl the module which is a Drupal specialist and he specifically talked about vision controlling Drupal changes and he all goes through a lot of stuff like features and what can you do to try and do some changes in the database and try and version control that and some good practices and how to go about vision controlling Drupal specifically are there any questions I create I create a branch for every task that I have so if I have a task that sees um build a new view and Drupal I'll create a branch for that because I'll most likely take that view and export it into features I'll commit that features to version control and then I'll merge it into a staging branch I'll get sign off from the client from that staging branch so if we go never ever not on my workflow this this is my own preferred workflow this is not an established standard I will never ever ever ever ever merge stage upstream ever it will never ever happen that's why you don't see an arrow going from stage to production because developers can be lazy and they'll contribute something to in stage that's not been tested and hasn't got sign off so for me an hour workflow you have to push it from the staging you have to push it from your feature branch my staging branches my client sign off branch they happy with the feature we've tested our deployment we know that it works we'll move just that change up into production yep what it does is it adds some code to your document so it'll go you're always on a particular branch when you're going to do a merge so let's say you want to move changes into stage so what you're going to do is you're going to switch to your stage branch and you're going to fire a command let's say we're committing that first change related content into it so the command is going to be get merge feature forward slash related content and so gets going to come back either it worked or it's going to say whoa there's been an issue and it's going to say the issue was let's say it's on index.php when you open that file up there'll be a whole bunch of arrows and stuff that shows this is what it was this is what it's going to be and you can just manually resolve that it's that simple it's it's it's quite clear it looks scary as hell but when you actually look at the lines of code it's not a big deal if you use something like tower you might know intrinsically that hey my new version that I've just committed is right I don't care what's in the other version it's really convenient you can right click and say resolve using my copy as opposed to the known copy and so from that perspective it's really good but it's not always the case I think these guys are going to kick me out you guys will have to talk to me after yeah I have no idea I've never seen anything of Drush and Get work together oh right okay okay that's because you can do updates to Drupal in two ways you can do it by just replacing the module which is typically what Drush does or you can use version control to do it it's a lot harder so you can say hey no no I'd run these updates by pulling the references from version control but that really requires you to install Drupal in a very specific manner rather than downloading the zip files or using Drush DL to download those files you would specifically have to download the the get clone versions of those modules for that to work


Wow, that's amazing. So welcome, thank you so much. You've been hearing about open source and contribution and stuff. By being here, you are not only becoming part of our community, but you're making our community better and stronger. And we've learned stuff from you that our community never knew before. So thank you so much. Who here has been to five or fewer? So like one to five, well, two to five Drupal cons. Cool. And who's been to 10 Drupal cons? I'm gonna stop counting now. My first Drupal con was in 2006 and registration was we walked in this little cute mini conference center in Brussels and we handed Dries a 20-year-old note and somebody standing next to him handed us a T-shirt, that was registration. We paid cash to Dries. Yeah, and there's still photos from that one. So just killing the tongue here. Three minutes to go. All right, so I wanna know, because of the nature of this talk, I'd really like to know who we're talking with. Who here is a developer and or does, essentially purely technical work? Very, well, okay, no, okay, all right. That's, you don't have to be, it's okay. It's okay, you can admit it. And who engages with clients and hopes to make their lives better and happier? Great. Who's in marketing? Yeah. So Tracy's people. My people. When we started our company, Tracy was our marketing persona. We just, she was marketing Mary, Meg? Something like that. All right, okay. And who owns or runs an agency or product business? What do you do? An agency for higher education? SU agency. SEO. I'm sorry. Cool, okay. An SEO agency for university, that's super cool. And you see, now I'm going to say why I've been eating this cookie and drinking this coffee. Jack leg is hitting me today. So I'm going to artificially enhance my performance with chocolate chip cookie and caffeine. One minute. One minute, okay. All right, I'm going to caffeinate for a second. And we'll be right with you. I think I've been to all the Drupal cons, but like four or five, so 20 something. So Tracy, do you remember the Jedi hand gesture for next slide? I suppose the last warmup question is, whose work does not involve building or maintaining or designing websites? Hollis, you're a recruiter, so welcome. Right, target rich environment, right? And someone else's hand went up there for a second? No? Okay, so most of us have something to do with building websites. And we're going to talk about the big why of Content Manager, right? And we're going to talk about how we think about creating content to fulfill the purpose of the things that everyone here but Hollis does for a living, presumably. So, the why of Content Management. We are the founders of Open Strategy Partners. Very briefly, we are, this is SEO optimized. I don't describe us as a content marketing agency, but it makes it easier for people to find us. We do strategy content and communications for agencies, technical product companies, and open source projects. We've got several clients here. It's incredibly fun and interesting. I come from an open source technical and community background and communications. Tracy has a business background and we've put together a team of technologist communicators to help our peers like my friends, people who we've been hanging out with since 2005 to do better business, to communicate the value of what they do better. And it's super, super, super fun. And we, coming from open source then, we try and share a lot of how we work. We have templates, we have enablement workshops, and so on. And we love questions and we love excuses to connect with people and give away more of the how we work along the way. Tracy has three business degrees, including an MBA. She has international management experience. She has actual education and structure in leadership and management and business. I have been in Drupal and open source since 2005. I was the 18th employee at a place called Acquia. And I have had a few thousand beers with developers and agency owners. So I know, so I have a very limited skillset which falls apart without structure and guidance. We come from a common group of friends and we decided to start this business together. So essentially, we take a now a structured and strategic view of how to like, where's your business, where would you like it to be? How can we support that with communication and what sort of insights can we gather from how you're working and how things might be better? That's us. So team communication and team strategy and what I think you'll see today in this presentation is that what we're trying to show you is a kind of a perfect blend of the writing stuff and the strategies, the thinking stuff. Oh, the other thing that I have to say, I know, go back one side. Yeah, yeah, yeah, right. So I know it's perfectly obvious but completely seriously for a second, Tracy is a genius and it's a real privilege to work with her and a lot of the systems and all the ways we work are her brain children and they're amazing. I am the pretty one, so I get to go on the road a lot and that's my job. So we build websites because we want to tell people something, we want to connect with them about something and we want to motivate them to do something, right? That doing something could be joining your club or downloading Drupal or buying your product or whatever. So when we communicate and connect with someone, we're producing this audience experience which we thought would be a fun fancy name for good content. Six or eight months ago when we submitted this proposal we thought that audience experience would be a good way to describe this. We don't use this term internally but let's understand that for the purpose of this presentation we're talking about writing good content. Good content is true strategically relevant and connects with people and connection is based on empathy, clarity and trust, right? So OSP and how we're talking about this, you help, this is to help you communicate the value of what you do to connect with people and help you grow. That's what we're going over today. This is what I already said in the introduction actually but it's a much more fun slide. You have a website to connect like connection is this audience experience, audience experience is good content that connects. Oh, that is why we're doing it, cool. We're gonna be through these in like seven minutes, right? Yeah. So when we're thinking about communicating we don't just sit down and blog for people. We want a strategic picture. We wanna make sure that what we're writing has a purpose and it fulfills that purpose. So we have to be very clear about what the point is we're trying to get across. You need to think about who your target audience is, what ruins their day, how does your product or open source project or what have you make it better? You need to make it interesting to read. It needs to be technically accurate. Use appropriate language to connect with your audience, et cetera, et cetera. That is good messaging and communication that goes in there. On the website side of things and on the preparing the page whoever publishes your stuff, it has to be well structured. We have to have semantic stuff in there. We need to make the pages look nice. That's a presentation and structure. And then when we write well, when we make sure it's accessible, when we don't waste people's time, when we use again appropriate language, we get a good reader experience somewhere in there is good content. So I think that it's not an emotional definition. It's an empirical why are we doing content to connect, to motivate, to convert? It's gotta be good to do that. And the things that we're talking about are relatively objective and actionable. We're going to go through three pillars to create communication that connects and we're very happy to take questions probably at the end about any of the aspects of this stuff. You need to have a foundation of technical truth that communicates the business value, whatever that is to whomever your audience is. You need to know what you're about as an organization, where your strengths and weaknesses are, where you want to improve, who you're not reaching, who you're reaching. Make sure that you're creating content that is supporting whatever your priority is currently and maybe your future plans. We've got clients where we're putting wording in to content that we're creating because we know it's coming in their next campaign and we want to see the field with that stuff suddenly. So, there's fun stuff to do like that. And we worked with an executive coach when we founded the company and he helped us find our company motto which is communicate, connect, grow. But we also have this concept that we call authentic communication and I'm gonna talk about how to operationally and creatively apply empathy and clarity to build trust. So, I'm not sure, is that our mission, it's our vision, it's our, what are those three? Values. Oh, those are our values. Those are our values. We totally believe in this. Empathy, clarity, trust. All right, I'm up. You wanna do that? Yeah. So, the first pillar is foundation of technical truth and it's based on what we call the OSP value map and the value map came out of a personal experience that I was having with one of our first clients which was also an open source CMS and I was trying to understand as a business persona and a marketing persona, I was trying to understand the value that it delivered me and a lot of the communication that I was coming across was extremely technical and it was only talking about very technical features and I was wondering to myself why does this matter to me? Why should I care about these technical things and I was obviously looking out to all of the competitors and I was looking at some of the Drupal communications and other open source CMSs and they were all very technically focused and all of the communications, they were missing that connection to the value of why we should care about those technical things or the resulting business value of what those technical capabilities were. So we started implementing what we call the OSP value map and it's basically to make the point, when we start with a strong foundation of technical truth that articulates your value, this translates into better strategy and better communication which then in turn translates into clear, compelling and accurate content that connects your value to your audience. So this is a diagram of the value map. So as you can see, it's quite complex but it's highly structured and the purpose of putting this together is to create a living library of accurate, agreed upon product features, the challenges that they solve and the benefits they bring to your audience. The way that we go about producing this value map is through interviews with the team members, the experts on your team, all of the various stakeholders and also sifting through all of your materials, whether they're polished or not. And what we do is collect all of the features and it's a lot of data. So we put it all in there and what we start to do then is once we identify the features, we start grouping them into what we call feature areas and we identify the challenges that those particular features solve and the benefits that they provide. And in these clusters, so we create these one layer of organization called the feature areas and then we do another layer of organization on top called the feature categories. And then what we do is we draw what we call a value case out of that and a value case is made up of three statements about the benefit, the challenge and the solution of that particular group of features. So that's the very technical side of it and what we're able to do is then when we have these clusters and these groups going up into the pyramid, what we can do then is build a positioning out of that and so that's what you see. That's basically the value map where we go from the features into a fact-based product positioning and all of this work results in a comprehensive inventory of communication components or micro statements and it helps to give you a structured, predictable way of working. So what happens when you have a foundation of technical truth? Well, you get this unified fact-based positioning based on substance and technical truth that actually resonates with your audience. It's gonna help you create clear product messaging, enable all the stakeholders to communicate consistently, accurately and compellingly. It's your turn. It's also the furthest I've walked since getting off the plane. So I mentioned, as Tracy said, we need to be structured and we need to be repeatable. If we as service providers to technology organizations don't present a systematic approach to how we work, nobody's gonna take it seriously. We need to assure a quality of our assets, a level of technical understanding and so and we also need to be able to do better and not make the same mistake more than twice. So we have to have systems, we have to have documentation and I mentioned never staring at a blank page. Every kind of... It wasn't time. Every kind of content asset that we produce, we have a sort of a formula, right? And everything starts with, hey, the thesis of this piece of content, what is it about and what does it say it's about? We have a brand message which is sort of the subliminal read between the lines message, like as a company, we care about this and we're smart people and know Drupal super well. Whatever you want people to think about you. Who's it for? What are their pain points? Business goals and so on. Now from the value map and the research we've already collected as much of that information as possible so when we go to write content we can pull these things over and it doesn't, you need to do an investor brief, you need to do a blog post, you need to plan a whole campaign. You've got all of these, you've got the challenges, you've got the personas that are related to them and so on so you can fill this out and it's a super handy way to get rolling. And then when we put it together, this is a real web page that we were part of creating and this is a very straightforward, direct application of this system. Not yet. So this is applying a systematic approach to creating product landing pages. This is for the typo three CMS. It's another PHP based open source CMS that solves the web publishing problem in a really interesting different way to Drupal with essentially the same components. Also a fantastic open source community. So communication components are just units of communication and we give them names so that we understand how to use them and on this page then they are then applied thus. You have our tagline positioning these feature statements and value cases and the value case you touched on that and if anyone's familiar with writing case studies where you have a challenge solution benefit sort of a thing, our concept of the value cases those components and generally we wanna communicate, we wanna see if you're interested really early. We don't wanna waste your time, we don't want you to read a whole blog post if it's not relevant to you. So we try and write a value case right at the top of a blog post and it says benefit. This is what you're gonna, this is the beautiful feature that you could have if you adopt our, if you adopt Drupal, right? And then we say the challenge, right? And the challenge is not to, not to, I don't know, raise your anger or remind you about how frustrating something is. It's so that you can identify, oh wait, I have that problem too. Whoa, okay, this article is for me and then you have a solution statement which says with Drupal we solve this, this way, right? And then all of those things get re-expanded and re-used throughout the concept and but you have a very structured way to help people understand how self-qualified and read something and then know what they're getting and then you also are helped to create a better asset. Here is another example at a different level of the value map and this is very placative. It's really easy in this case but you know, connect your digital marketing funnel directly through the back end without repeatedly switching between systems, right? Integrate all your digital marketing stuff into the single CMS back end. Well, that's, if anybody's done like marketing ops and had four or five tools open and you have to copy paste and remember what you've updated like wouldn't it be great to have it in one place? Yes, so when you think of marketing campaign management you think of switching between boom, boom, boom, it's time consuming, right? Oh, who knows that? I know that. I've been in that marketing department. Yes, thank you for your support. So how do we solve that? Tightly integrate different marketing services directly into typo three for hassle free digital marketing. Now, how do we do that? We said we can create content based on technical truth in the value map, the very lowest layer, the features, right? They are things that do a thing. Avoid, create and manage fine-grained user rights in the back end and front end to reduce management overhead. Integrate with third party marketing tools and services. So the way that we do marketing and positioning and create content based on this value map structure is based on the truth. And the further down you go, the further you understand how your system delivers the promises that you make. So the top of the value map, you're making big promises in business language, right? But if somebody comes and does due diligence based on business content, you look down and you get to the base layer where there is a feature. And if you go look in the code, of course it supports it, right? By the same token, when we write developer-focused content, we start at the technical level, right? Because we like the details and we talk about APIs and whatever. And we can give information about the business values of having the APIs to the developers while explaining how to use them. So the developers say, boss, boss, boss, I have to use typo three. It's so amazing. I have to use Drupal, I have to use whatever. You give the developers the idea of the connection to the positioning, right? You talk about the benefit. They can have a more valuable conversation with budget holders, right? And act as more effective influencers. It's super nice. And it's all true. So going down in the value map is how and going up in the value map is why. Thank you. Thank you. Was it you? Huh? Thank you. I'm allowed to. So very powerful and it lets us, it lets us focus on, you know, choosing pretty words and putting them in a good order. All right, I'm back. You're back? I'm back. All right. So the second pillar that we wanna take you through is a strong content and communication strategy. So reflecting back on the value map and the strategy that grows from it, we wanna emphasize why strategy is so important and worth the time and energy to invest in it. So there's a lot of benefits to having a strong strategy and I think it's often a practice that maybe, you know, people don't understand why you should spend the time on it or what the value of having a good strategy is. And it's really important to provide vision and direction. I think this is the top benefit. All of the communication that you do needs to be focused through the lens of having vision and direction. And this obviously helps guide your content down a very focused path. The other things that a good content and communication strategy help you with is really understanding your audience, knowing what their needs and their problems are because you did all the work to research, to interview, to speak with your audience and you have these things collected in a document somewhere and the people who are writing the content can refer to this and put it through that lens. The strategy work also helps you understand how you fit in the competitive landscape and so this can help develop your product development choices as well as choosing how to focus your communications on your unique value proposition. And it strategy also helps you create plans so that you can focus your resources and energy on the narratives that connect with your audience. It's still me. So the third pillar that we wanna take you through is communication that connects. So we have a practice and a framework called, that Jan mentioned earlier, called the authentic communication framework and it's based on three values of communicating with empathy, with clarity and with trust. We'd like to take you through these three values and identify both the operational practices of the value and the writing practices of the value. In our own writing practice, we've developed a set of codes that encapsulate good writing and editing practices and help us learn and improve together and these codes were another, were sort of born out of another one of my own experiences as a non-writer. So I'm in our working relationship, I'm the strategist and that's my main focus is strategy and I'm not a writer by nature. And but obviously when companies are small, everybody has to chip in everywhere and so I was trying to write and obviously trying to do my very best and I was very frustrated by the feedback and the changes to my work that I had poured so much love and energy into. I really wanted to learn why Jam was making these changes that he made. Like my whole paper would come back like with the equivalent of red marker all over it. And as upset as you were, you said, okay, but it's better, why is it better? I did. And so we basically, we spent the next two years trying to siphon these writing principles out of Jam's brain and I also looked up a few other industry experts and we put them into a system and we'll share a few samples of those codes and principles with you. So first value, empathy.  Oh yeah, maybe that's better, here we go. So operational empathy is really trying to put yourself into your audience's shoes, really trying to understand them and their problems and the things that they experience in a day. Also what sources they trust and things like that. And so these are a few of the operational things that you can do to have empathy for your audience. So interviews I think are the most important, actually speaking with your target audience or the subject matter experts, client advocates, devs, tech leads, all the people have conversations. Audience research is also really helpful to go out and see what else is being said in the industry not necessarily with your direct contacts with your clients or your audience but finding the articles that they read and maybe there's some studies being done and finding some kind of aggregate statistics and data about their challenges and needs. Surveys are another great way similar to interviews but a little bit more structured on the questions and being able to identify patterns of their challenges and needs. Quoting the subject matter experts. As it says, we cannot be experts in everything and the way that we do that and best be accurate and authentic is by speaking with the subject matter experts and quoting them directly in our materials. Talking with the stakeholders, definitely important and also desiloing and so collecting various perspectives helps a lot. So these are the codes that I was talking about earlier that we siphoned out of the brain. So the first code that we have is withum which stands for what's in it for me. Make sure that you lead with the benefit showing your audience why they should care in the opening section. I think Jan mentioned this earlier as well. The next one stands for connect. So using language that will connect with your target audience. Referring back to my earlier experience when I was reading all the technical materials and they were only talking about the technical features that's not speaking the business language or the marketers language. So here's a perfect example. Marketers care about product market fit and open source developers are turned off by audience segmentation, words like that. Product market fit and audience segmentation simply means are you building something that other people care about and who exactly can you help with it? That's an example of two different ways you can write exactly the same thing with empathy. Yeah. Thank you. The next one stands for criticism and it's really important to avoid hidden or implied criticism and specifically never tell people that they're doing it wrong. And this is actually an easier trap to fall into than you might think. Oh, right. He's the performer. Not me. The next code is FUD, which is a little bit similar to criticism. Avoid negative copy and FUD marketing which stands for fear, uncertainty, and doubt. We always wanna talk about things in the positive. So, and talk about the actual thing that you do do. The next code is for inclusive language. Basically wanna help readers feel respected and welcome and avoid any language of prejudice, bias, discrimination, or lacking sensitivity. That's pretty clear. The last one is PACS, which is never using a violent language. And this is also another trap that's kinda easy to fall into. So what we wanna use peaceful inclusive metaphors like art or carpentry or gardening and avoid things like war or violence or even sports tends to fall in that category as well. And the sports, leave it on the slides for a minute. The sports one is really interesting because it turns out that we are native English speakers but we have clients who are not native English speakers and we have audiences who are not native English speakers. And if I use a baseball metaphor in the UK that is not respectful or inclusive, right? Much less with someone from a different country with different practices. So keep things plain and simple. I wanna just talk quickly about this process and where the codes fall into it. We divide our, once we've got a brief, written a draft, done basic, going over that, we hand it off to another team member who does an editing pass and we do five passes on the work. The first thing is what we call the positivity pass and we can read the article and notice anything that is just great. And we take a code and we put plus plus in the code and we might even give them a compliment or thank them or some expression of gratitude. As an editor, this also reminds me not to change that and not to lose it, because it's great, right? Don't lose it in the shuffle. Then we look at the overall narrative and logical structure of the piece, the flow and the sense of the individual units and we go down and down in this kind of matryoshka doll until we get to the choice of individual words. And at any point we can write, hey, in the comment we'll write connect in all caps, I don't think that using this word for developers is gonna hit write, why don't you try this? We don't say, or maybe I use suggesting mode in Google Docs and I say, hey, I changed this to this other thing for this reason. Now we never say to each other, that was wrong and I fixed it for you, that was incorrect and this is correct, except for factual issues, right? But any of these editorial issues, when we have the time and are replying our full process, we are having a conversation between peers and we're learning from each other since it's a flat structure where we're having an exchange and the author who goes back after the editing pass is fully within her rights to say, your suggestion is so awesome, it makes the piece better, done. Or they say, hmm, no, I chose that word because of A, B and C and I really wanna keep that and then it's done but both people have thought about it and agreed on the outcome so that's also okay and often I will see a third option that I'm inspired by the conversation that we're having, right? I was very frustrated by editing in my past as a writer where some senior editor would find time in their day to edit 30% of my thing, they would make changes that I didn't understand, my stuff would disappear, would have my name on it but it wasn't my words and so on and so on and this gives us an opportunity to learn and teach and be structured and very clear and also psychologically putting it in a code removes the you are wrong, you know, you always, none of those negative psychological things we're talking about this codex of documented principles we have full documentation for all of these so if somebody really disagrees like we can go have a proper conversation about it and figure it out or create a new code or change the rules and it's fun and it's really nice they're all on our website super happy to talk about these all day as well so moving right along to clarity we've got 17 minutes, right Mike? Okay so empathy, now clarity we need clarity in two ways as we were talking about before operationally and in our presentation all of these flow in and out of each other and a lot of codes have similar cousins because there might be one cousin in the structure and narrative section and there might be one in the choice of word section that are slightly different applications of a similar concept so anyway, we write for technology organizations we want to tell the truth and we want to remember the difference between Java and JavaScript, right? We also, once we do our writing we pass everything back to the client however many review milestones they want you know, we usually plan a campaign review the titles and the audience maybe give them the briefs before we start writing depends on the client but before anybody publishes everything this is a lot of times this is going out under someone else's name if it's not one of our guest posts so they don't want nonsense going out under their name and they want to be proud of what they're putting their name under, right? So, we're accurate we like make sense, okay? I don't know now and then sort of moving into the other side of this like we just have to be focused we shouldn't be wasting people's time we should be efficient with our communication and it should be clear and easy to consume there's a code coming on the very next slide which is wall a wall of text is super, super hard to parse and if you have four or five headers in a blog post that also tell the story and a couple of bulleted lists that attract the eye you can really, on the one hand you can really help people scan and parse and get through what you've done quicker if they need to on the other hand, hot tip whatever you put in a bulleted list people are going to notice it and read it no matter where it is they're going to consume that so wall means make your headers tell the story put important stuff in a list instead of in the giant paragraph write shorter paragraphs, et cetera so here we're telling the same story over again start with the point of what the thing is about let people decide whether they want to read further do it with a value case do it another way doesn't matter but tell me the point in a case study I don't like seeing the history of the such and so company found it in whenever and blah, blah, blah, blah, blah I know they're important tell me later tell me what their problem was because then I know if I care, right? right, spock right? use logic the common application of this when we're working is somebody will make a claim that something is the best or the most efficient or the fastest or something we need to say according to section so testing page old times with this thing are 30% faster or whatever at least link to something make a small quote, what have you and don't, you know make sense, please do make sense don't talk nonsense crisp hey it's really beautiful but this is not a creative writing exercise let's like let's tighten it up if any word is not building any word or any sentence is not building towards the point of what you're doing cut it out writing it's better and better with more and more reviews up to a point and explain technical terms we have several different codes that touch on this but if you're targeting your audience at a particular level of developers okay fine you can assume a certain level of knowledge but I bet you also want to help less knowledgeable people who want to learn or want to become more senior or are moving into the industry give them enough context to also know what you're talking about so explain like such a technology brackets, a technology for parsing something or other removing dangerous whatever it is just a little bracket maybe a link to a Wikipedia entry a website, whatever because other people can then educate themselves and find the context to learn and come with you and you're benefiting more people that way super nice and we have a couple of others explain acronyms is also in that group so right so that's writing for clarity and now we move to trust the first thing that we have to say about trust is that if we operate and create with empathy it builds trust right and trust is a common outcome of acting in this way um we talk about trust signals I'm going to give some examples of these in a minute um but you need to be showing your potential clients your potential new hires your whoever it is that you're trying to attract that you know what you're doing that you have experience um this is a great place to be writing blogs about how you did x y with the last triple upgrade and so on it shows that you know what you're doing it's the same reason why you'd put your certification on the website right you're broadcasting the signal that you're trustworthy um and you know by sharing the information you're showing that you're a good open source citizen and so on um in your communication in general um don't just talk about yourself celebrate the people around you congratulate other communities whatever it is it's really nice this especially applies I think to social media but it's totally okay to acknowledge that other people are doing well too and it it's genuine and it's a gratitude practice um that should also make you feel better honestly um be your authentic self um operate with integrity please um you know that this is a really really interesting one I've um one of the reasons one of the many reasons we founded the agencies because I saw technology marketing in the past that I really didn't appreciate um and sales teams that were selling things that didn't exist and marketers who were writing nonsense because they were too afraid to ask questions right go ask the questions and quote your subject matter expert right and and like be honest that your product doesn't we don't have a chat function if that's essential to you like let's talk about what you really need to do and if that's essential cool go on it's cool it's fine be honest about that it's okay because you know if your product isn't centered on chatting and you don't have a chat it's fine and be clear about that right um so talking about these trust signals broadcast the signals that build trust the next two slides are relatively actionable um we will I'm very very happy to share the slides with people there's also more oh no right I'm one slide ahead of myself yes and we only got 10 minutes left do we want to have room for questions right so there's like three slides left right yep okay cool so look speed this is the same thing link to something that shows what you're saying is true um use facts um give examples of what you're talking about thank you Mike 10 minutes give examples that helps um people like um you know have a picture in their mind um same with metaphors right that's enough whatever's to fill something or other you know that sort of stuff that they do in reporting um quote subject matter experts directly I can write expert level content about most things because I'm not afraid to ask questions and I quote and I run through the review process quote the people in the age of AI human generated content remains valuable and important and interesting and one of the big differentiators is you're creating new content in the world when you're quoting the person who knows about her thing more than anybody in the world right so quote your experts avoid exaggeration um be simple to the point now trust signals because they're fun um and we have some more resources on our website about this this is an example of if you're trying to choose an open source project what are you looking at right what makes you think maybe that open source project would be good it seems to solve the problem that I want but do they have a code of conduct what are their release notes look like how long are their issue cues right the origin story of this is it came out of like how do I choose between the five triple modules that seem to do the same thing right um do they have a visible license how many people are using it and so on and so forth right and this all I think you all have a like a gut feeling that like yeah this is true um helps me choose something right um so we can do a sort of assessment of this with with some of our clients and then and then in theory say hey you don't have that and we can show you where to get one or where to how to create one and you know you're doing well over here some some of these are indirect most of them are direct but you can't exactly increase the number of your downloads in any honest way right but you can make sure that your release notes are good and structured and you you know you read me about it there whatever um if you're an agency it's a completely different set of signals you need to uh show people that we build a cell services team of experts sharing our knowledge qualified and experience and using set of tools process with proven track record of success that is a content structure show whatever it is you do as a product like grouping of functionalities and solutions as open source practitioners talk that show the tools and processes that you were specialized in agile and CDNs and Drupal right have a quick explanation on your website of the tools that you use blog about the tools to show that you know what you're doing so that it's credible that your products make a positive difference right that they work have team profiles people's interest and expertise on them the senior designer should uh a blog about adobe xd and css and i don't know which is the right color blue for corporations right and the head lead dev and the front and then so on everybody should have their favorite tools all this stuff that shows that credibly they work in the space their name goes on those blog posts there's a link there there's a link between these google sees that or search machines see that you build authority and and and reputation so you have a team it is qualified an experience in using tools to deliver your products the last piece you've done it successfully someone choosing you isn't the first your solutions work and your team is good to work with case studies and testimonials those are trust signals for an agent services shaped business please go to our website we have a writing and editing guide we have the full edit editing codes and we have an editing code starter page which is fun uh... we have a whole page about the value map we have a content writing guide for tech products which is fun and talks about all those components and so on we blog not as often as we want to we blog every damn day we blog every day mostly for other people and we have a podcast that sometimes we get out regularly sometimes we don't but we've done a bunch of episodes about how we write and edit and work together and they're fun and relatively short and please get in touch with us we talked about why you have a website how to make good content and why you should make good content hopefully we showed you some principles actionable ways to create communication that connects with people and helps you grow in whatever you're doing thank you very much have a nice day and we have uh... i believe we have six official minutes if there are any questions i know it was a lot everybody take a deep breath these are atoms zero zero ones they are carbon neutral recyclable machine washable the second most comfortable pair of shoes i have and they're from um... brooklyn manufactured in korea companies in brooklyn next question university seo man ai ai's impact on process uh... having too much content in the world etc etc my favorite perspective currently about the state of ai now is that it's like a very enthusiastic intern so you can get a lot of you can get a lot of information some of which will be useful uh... and some won't we are experimenting with doing basic research or saying what is the internet say are the most ten important ten most important points about something but we're backing all of that up with our own uh... with our own work the next generation of a i is going to be able to combine private data sets with public data and we believe that with the value map and the content libraries from our clients will be able to draw some smart conclusions and probably write some smarter out lines and so on so plus we truly believe that working with people who want to communicate in their own voice and creating new content in the world is going to be meaningful for some amount of time also i'm no expert but i've heard that the search engines are pretty much already hip to when a i is generating content and they're giving it quite happy penalties which is i mean for me that's great news and i think for most of us yes man we do those too yeah yeah yeah yeah so did you say commend at the beginning so i'll just repeat it for the recording um... she's uh... she's a journalist that works in healthcare writing and seo and um... finds it interesting and unusual that we have this solution to the blank page problem and not just a style guide so on our website um... there's a blog post the images like um... some uh... a carnation in a series of photos a time lapse of it blooming and in that blog post about how we work there is the content template that we use and please download it please get in touch let's talk about it it's fun we have them for many many other formats matias no i really don't want to repeat you yeah i was just thinking i also do development i also do development and i also work with writing and i've been using this and if you've ever worked in a software project that is well well structured you know how past it is to write the real code at the end and then having a really good review process afterwards how good it makes your code how much you learn from it this is kind of it okay nice thank you i'll take that as a compliment uh... matias is many one more thing the magical thing that actually happened once is that suddenly discover a feature you didn't know you had oh yeah oh yeah so the value map is really interesting because uh... we're moving it into a proper database now and um... you can say hey this thing is sitting off by its own so like if it's not connected to the ring value why are you spending money on it or you say you do this thing but there's no how right it's pretty fascinating uh... matias is many things he among them he is a team member to open strategy partners he's also a typo three association board member typo three is one of the many uh... open source projects that we are professionally and personally involved along with drupal and a bunch of others any other question


The Order of the Fang is an ancient order of Crocatopians, led by El Hazret, the Balanced Professor. They were responsible for putting the now reawakened tuts to sleep. This was done through the Book of Rituals, also known as the Croconomicon. This book is the most powerful knowledge of life and death magic in the spiral, and funnily enough is what Malastir is seeking in Crocatopia. Unfortunately, none of the Malabonian archaeologists know where this book is. In order to figure out where the book is, we assemble the order. We begin our search for Crocopatra, Queen of the Tuts. She is brought back to life when Malastir came, searching for the Croconomicon, thus causing all the tuts to rise again. After her defeat, the tuts fall back to a slumber. She says she locked the Croconomicon in the sarcophagus of souls long ago, which happened to no longer be in Crocatopia, and is headed to a museum in Malibu.