Hello, so my name is Matej David. I'm a postdoc here at OICR. I work with Jared Simpson and I've done some prior work on readmappers. I wrote this readmapper called Shrink for solid data which is now kind of gone and these days I'm working on like the novel assembly combining long read technologies with like regular Illumina technologies. And that's me. Okay, so in this module we're going to talk about reference genome assembly and some objectives. I'm going to try to explain the reference genome alignment, how it works. I'll spend some time talking about Illumina technology, sequencing technology and in particular about the types of errors that you will see with this data and like how those errors affect mapping and like the results that you're going to get out of this analysis. We're going to learn some alignment technology and we'll see this regular file formats like FAST, QN, SAM and BAM. We're just going to have a look at those in the lab and we'll actually run an aligner. Like in the lab we actually have two aligners set up so you can run both of them. The lecture is two hours, sorry the lecture, the module is assigned two hours so I'm hoping to finish the lecture in 45 minutes and then we'll just do the lab. So this is the outline what we're going to do and let's start at the top. So we'll talk about Illumina sequencing. There's lots of sequencing platforms out there. Some are trying to address like high throughput things so they produce lots of gigabases per run. Others are trying to produce longer and longer reads and this slide I think it's from, oh it's here, 2014 so it is a bit out of date. In particular Oxford Nanoport is this new technology, it's not here. However so in our module we're just going to be focusing on Illumina data which is one specific type of data so I'm not going to be talking about other things like specific biosciences. Okay so let's just want to talk about Illumina sequencing processing first. It's just one cautionary note whatever. So my background is in computer science and mathematics so I don't really know biology so I'm guessing there are people like in this room who know more biology than I do. I just learned whatever I need as I went through so that's a sign. Okay so Illumina sequencing. So starting with the genomic DNA here at the top, how does it work? So first the genomic DNA is shared into small pieces about 200 to 300, 600 BP fragments. Adapter sequencing or adapters are attached to the end of these pieces like the ends are repaired, the adapters are attached. These sequences are applied to a flow cell. On this flow cell every single one of these pieces is amplified into a cluster of molecules which are hopefully the same which are these ones here and this is done using a solid phase PCR and then this flow cell is placed in like fed into the machine which goes on and reads the various molecules in clusters. So this is done in Illumina. It's done using photography basically. So in more detail so consider like this being the here is the molecule which is being sequenced so the way this process works is that various bases over here there's this T are attached to an existing sequence so this is the existing sequence which we are sequencing the ACGA here. So in cycles in every cycle one base is attached to this thing which is complementary to the one in this molecule and the bases that were attaching they have like a fluorescent dye on it and a laser is shown on all of these things and all these clusters produce like small dots of color and this is what the machine sees so like in the first cycle the machine sees a blue light corresponding to this to the molecule that we're sequencing here so this is this blue in the second cycle it sees a G which is this green which is this color over here and so on and the process repeats. This is the image like the the actual molecule is attached to the flow cell at the bottoms and the sequencing starts here at the top and it goes down in Illumina and just one thing to point out is that it's the the process is repeating for about 100 to 250 300 cycles so starting here at the top one of these Illumina reads will contain maybe 100 or 200 bases going down this molecule could be a bit longer it could be 600 500 so it's you want to read the entire molecule in one line okay the process of base calling so this is this is hidden for me this is done by the machine the machine sees this kind of a picture actually it's massively parallel so it does it's the cycles apply to all these clusters parallel it's the machine sees these kind of dots color dots and out of these color dots the machine tries to make sense saying that okay in this cluster at this cycle there was a light which looked kind of green and in that case are going to put a base representing G over there okay so that's that's the process by which the machines translate this thing into into base calls okay why am I telling you this mainly in order to describe the types of errors that you will see with Illumina data in particular okay so here in figure a you have a cluster so these are identical molecules are PCR amplified and the sequencing here is going just fine so all the all the three molecules are at the same kind of stage right so we are all of them are beating the fourth base from the top and all the the molecules attached they're all shining this red light so then the sequencer sees a solid red light coming out of this cluster and then it's able to call that base with certainty as being the red the base which is corresponding but corresponding to red the various types of errors are like some of them first of all so in in this slide B you have phasing errors so you have even though the molecules are the same the sequencing process it just got out of phase so here this on this molecule the we're reading the fourth base which is this red but on this one on the left for some reason the the cycling the cycle process skip this base and now the light that's shining from here is this blue which corresponds to the next base over here this the again the cycle for some reason stayed behind so this is shining a green light so at this point because of this kind of uncertainty the light which is emitted from these so all of these are emitting like one light corresponding to one of those dots the light coming from that dot will be kind of ambiguous so the sequencer will make some kind of guess as to what base is there and it will in this case it will probably say well i'm not so sure maybe this is a g but i'm going to assign it like a high probability of being wrong just because of the the light is not clear another type of error is just like loss of signal so maybe the molecule just disintegrated or something happened so in this particular cluster the intensity that's coming out of there is not as high as as the sequencer would expect so again that might confuse the sequencer into thinking it's error and finally like the even if they're in cycle there could be errors with like the um uh floor for cross so the the the light that's being emitted might still be somehow misread by the sequencer yeah it's just random what do you mean like how do these things come about are they just processing yeah so they're expecting right so the sequencing contains many of these likes right this is just one cluster which corresponds to one of those dots on that slide so the machine is reading many many of those things at the same time right takes pictures and then there's some software that goes says okay and this dot there's a red at this time and then the blue is and hopefully it's working okay for most of them but these are the types of errors that you're going to see like it's yeah you cannot control like this this will occur just by chance okay so part of the point here is that Illumina sequencing contains mainly um uh substitution errors uh as opposed to like long insertion or deletion errors which is a case without the technologies and the base calling process uh it produces not only just not only the base which is being read like the color but it also produces error estimates for that color which have to do with the intensity and how much differentiation between these between the colors that the sequencer is able to see okay so this is what the error error rates per base positions base position at the bottom this error rate this is what they look like for some Illumina sequencing projects the various lines are so these are different organisms and this slide is taken from some assembled on paper I think I think the light blue is human data and these others they're like various other organisms the message here is that the error increases as you progress down in the read so this is a hundred bases into the read so hundred and fifties over here so at the beginning the process is quite accurate but as you might expect as you go down like in these cycles like you're expecting to have all those molecules go through the cycles in like in in sync and doesn't always happen that way so so as you go down the error in the reads becomes larger and larger but in general it's still quite good so right this is 0.5 percent this line over here right this is one percent so the per base error rate stays well below that thing and in general for for Illumina reads you expect like overall it's about 0.5 percent is the error rate that we see and it's mainly substitutions um this is in stark contrast with other technologies like Pacific bands as the Oxford Nanopore which have higher error rate and they have other types so it's not just substituting they have insertions deletions and so on okay so that's Illumina sequencing another thing I want to talk about is paired reads so what are those this is the normal process which is performed by Illumina like these days so the genomic is shared into these fragments adapters are ligated which are uh different for the two ends so if there's an a1 and a2 and sequencing primers these things are amplified on the flow cell and then every one of those molecules which again are up to let's say 500 dp they are read twice so once that it's the molecule is attached to this end and it's read from from the uh from this end going uh towards the flow cell and then in another in in some other step the molecule is somehow it's actually reversed and cluster is regenerated and so on but the same molecule ends up being read uh second time from the other direction and the machine keeps track of all this and and what at the end what you see are uh paired reads so you get out of the machine you get two reads which are actually sequencing the same genomic fragment which is this guy over here and they're pointing towards each other like this so one is from one end the other is from the other end and if there are more if the fragment is larger than twice the number of cycles you will not end up reading the entire read right so there will be something in the middle which is not okay so this is and this is what's called uh paired and sequencing so that's process then there's another process called mate pair so why would you want that uh if for normal sequencing uh you might be able to use this kind of data this is uh mate pair reads are used more for uh let's say assembly of um like novel like a new organism you don't have a reference you don't assemble this read so assembly makes it's hard to do assembly with fragments which are up to 500 bp basis just because the assembler would be confused by any repeat which is larger than that basically so mate pairs are one way to um apply Illumina sequencing and obtain sequencing data which is further apart than just five six hundred bp okay so the way it works again you have the genomic DNA here and this is fragmented into larger chunks so now you have two to five uh kilobases like sometimes even larger like 40 kilobases um taking take these fragments there's a biotein uh molecule attached to this end and the fragments are then circularized circularized so that they look like this and then these circular molecules are then uh shared into fragments again uh 400 to 600 which look like this but then at this point um the molecules which do not have the biotein are kind of washed away so you you're you're keeping only those fragments which have this biotein marker in the middle okay and then these fragments over here they're fed into the regular sequencing over at this particular step okay and then you go through this process so what you're going to end up is so if the original pair at reads look like this so you have a genome region which is 600 bp and it's being sequenced uh in this so you have the two arrows pointing inwards kind of this is the regular thing for mate pair reads you will have uh the arrows will be pointing the other way so like outward right so remember this the biotein thing is circularizing so that's why um so you'll have two uh you'll have two arrows which are pointing away from each other and they're like much further apart than this other so it is two to four to kilobases okay so that's that's the difference between paired and and mate pairs okay so if you ever encounter these kind of things so that you know what they are okay uh let's talk about the fascue format so this is what the format in which regular like Illumina reads are stored the entries in one of these files they look like this is there any rule there is the number of cycles no so you never yeah so the question was uh not sure so how does the number of cycles relate to yes yes you said you know in the prayer hand number of cycles is lower than the size of pregnant yes the same so the right so in pair hand which is on this on the left side right so the if this molecule over here is 600 bp long and the number of cycles is only 150 you're going to read 150 from one end 150 from the other which is 300 and in the middle you have like a region of 300 bp which is not being read okay the same it's exactly the same thing applies here um it's just that yeah the the uh it's so this particular fragment the one with the biotein molecule in the middle the same statement will apply to this family it's just that because of the process you have to unwind that and put them like on the reference and see what like how much genome is in between them uh so you end up with which yeah with reads that are like this again you have 150 and 150 on either side but in the middle you have like 40 kilobyte up to 40 kilobases okay fast q format okay so in in this in fast q files the reads are stored so if you look at them we're gonna look at them in the lab so you have every read is stored on four lines this is a read name which so it's called a label which sometimes contains in codes the position where that read came from on the flow cell remember the the square picture with the dots so that might be encoded in the read name um this is the read sequence a cgt it's a comment and this is the quality the score the base quality values for that particular read and this is this is a way to encode those errors that i was talking about okay uh in and within this is like a bigger fast q file and you can see this is one read this is the record for another read and then another read then some so they they're like uh sequential within that file that's the sequence data sorry the for the third line yeah so the third line is um the one with a plus so this i initially i thought it's a comment like a few years ago but then i so i think it's it's a bit redundant that line and i think it comes from uh earlier uh file formats where the read seek the read basis and the base qualities were in different files and each one had its own name like so there was a label for the read and the label for the base call the base uh qualities and then the process of putting those together in that process this third line appeared um but yeah usually it's it's either empty or it's equal to the other to the label here and i think many safe to say that many tools just ignore the third line but let's not assume that so in this particular example see it's the label on the first line is equal actually to the label on the side um okay so our base quality scores um so out of the sequencing process you have estimates of errors that this particular uh base call is an error it's only a c with 15 percent certainty or 15 percent probability it's something else um the way this is encoded first of all the probability is transformed into an integer uh within this range and uh i yeah i keep uh i forget to add this formula to my slides um the formula is quite simple it's something like oh quality is something like minus 10 times log base 10 of probability of error so using of uh this standard formula so you take the probability of error and you apply this and you get like an integer um quality value which is in this range and then these uh these integers are encoded as ASCII characters within that file using two schemes like one is fred plus 33 and fred plus 64 the reason is so that you become confused that's why because no like the different companies use different encoding uh schemes uh obviously however the situation is better these days um um so this is uh on the fast q wikipedia page you have this representation of what the various characters what quality is the various characters encode uh so you have here the ASCII character characters starting from number 33 to 126 and so under fred plus 33 encoding scheme you have these characters over here are encoding the qualities between 0 and 40 um so for instance if you see in the quality values if you see numbers ASCII numbers like 0 from 9 you see that these do not belong to this other range which is fred plus 64 so you know that your data is encoded as fred plus 33 if you ever see like smaller case letters like abcdf then that means the encoding scheme for those qualities is fred plus 64 because again fred 33 ends over here so it never makes it work um these days this is better because Illumina uh which is the bulk sequencing ngs sequencing Illumina switched to fred plus 33 so if you have like recent Illumina data it's also encoded as fred plus 33 just like all the other sequencing uh data in the past if you if you ever look at older Illumina data or download it from like some public repository you might have uh the qualities encoded as fred plus 64 okay uh paired and then made pair so how are these encoded uh usually the corresponding reads uh they are given to you in separate fastq files which are kind of in sync so the first the first record in one file corresponds to one read the first record from the second line file corresponds to the second read of the same fragment right and then they go in sync like this and rarely the the the reads from the same fragment are interleaved in the same file but that's that's not usual and oftentimes but not always the read name is ending in slash one or slash two so you might open one file and you see that all the read names end in slash one and if open the other file you see that all the read names end in slash but that that's not always the plan um okay so let's talk about reference alignment it's all about uh Illumina so what's the goal why do we do reference alignment so in general we want to find reads that come from certain uh genomic regions of interest like genes so we have a reference genome and we know where the genes are on that reference we want to find the reads that come from a particular gene in the donor genome so the goal again is to infer variations in the donor genome sometimes we want to reconstruct the donor genome so like to do assembly and uh some assemblers do uh start by mapping the reads to the reference and then processing them from there uh what are the main issues uh with this well first of all who cariotic genomes are large and repetitive and uh mapping to repetitive regions is very error prone there's large amounts of data and then there's all these differences so between the reference and the donor that you're sequencing you have snips in those structural variations and furthermore between the reference and the actual reads that you see you have all these variations plus the sequencing errors on top of that okay so there's all these things so the the alignment process has to allow for all these differences uh the main steps because I'm talking here about the generic alignment process not about any particular aligner um so the the way this works is uh the the aligner constructs some kind of index of the reference sequence so it takes a reference sequence it processes it like once and it creates some kind of structure uh that it uses internally and then for each sequencing read that you give it identifies regions of interest for alignment and this is the most uh important step and various aligners differing how this is done like sometimes they uh some ask for exact matches of a certain minimum length or for several matches in close proximity of again of certain lengths and so if pairing information is available so you have like a read paired and or made pairs this information is used by by the smart assemblers to reduce this list of possible alignment locations the third step conceptual step is to actually align the read to that particular to all the regions where it might go and this is a very costly step right so the speed comes from reducing this list using all sorts of heuristics and then the next various aligners have varying stopping criteria like some give you all the alignments for a read some give you just the best alignment there's all these options um some aligners do again the secondary alignments like maybe they split the read if it's like a long read it 150 maybe it can report the aligner can report a mapping of 70 bp to one location and another 80 bp to like a completely different location that that kind of stuff speed alignments so and these these kind of options differ from alignment to aligner um right this is just a diagram of what I said so this is a read and this is the reference and the aligner finds three locations like one two three in here and here the read aligns with one mismatch here it aligns with two mismatches so probably in this case the aligner will report that the correct mapping locations is here and it will attach a certainty like a a quality value which is a certainty to this assignment it will say this the mapping is correct with a certain probability for the reads okay looking at the first read in the pair let's say it matched to two locations in the genome both in both locations it has one of this mismatch but then looking at the second read of the same fragment it the read is mapped in this location with very with like no mismatches but over here it has lots of mismatches so in this case the read aligner will probably say okay this is on the left is the correct mapping location for this for this paired reads various properties which are relevant to aligners are so accuracy why because misaligning reads to the reference that's a source of false positive variant calls like down like down the pipelines sensitivity you must allow for variation between reference and donor so for humans humans are like pretty the expected difference between a reference of the donor is quite small but for other organisms like that that can be much much larger I was working once with like some Siona data which is this the organism had like seven percent difference between two individuals is huge so the the more the organism like the the more the references donor differ the more you want to allow the the aligner to be sensitive speed is always a factor has two large amounts to data to process and memory because compute nodes have limited resources so first question is which one is the best liner I don't know the ones which we will use in this lab are bwa and bowtie which are good kind of established all around the liners but there are better liners if you're looking for certain things like for speed these are faster these are more accurate sometimes and if you're looking for special functionality like dealing with you know RNA-seq data and you want to align across splice junctions then there are separate aligners that offer those kind of options okay and you can just see a recent survey for comparisons I was going to put one but for some reason the page that the paper pointed to is not available anymore so um okay are we doing on time so sandbound format so this is uh once you run an aligner then you have to the aligner what what it does it produces this kind of description of which read maps where in the reference genome okay and the way this is described is in this standardized SAM format which is a tab delimited text file BAM is just a compressed binary form of that same thing and the way to access both these types of files is this SAM tools toolkit which we'll use in the in the lab and this can be used to convert sort alignments extract alignments from a given location and so on this is what uh so this entire thing over here this is just one line describing one mapping this is part of one of these SAM files okay so this is just on one line it's not you know five lines over here just run out of space um and the main things are so this is the read IDs over here this is a flag uh which is a numerical value and this encodes things such as the on which strand of the reference that read is mapped to like the forward or the reverse the pairing information for that particular read uh and some properties for the alignment this is the main or supplementary or duplicate and so on so these are all encoded in this integral value and we're going to look at this in the lab next two things are this is the chromosome so in this particular uh case the read is mapped to chromosome 19 of the whatever reference uh position within that chromosome a mapping quality again this is a fred encoding of the probability the alignment location is wrong so uh this is one of the important ones so again fred is just this same uh formula so it's an encoding of a probability of something being wrong as an integer okay so in this case 60 a fred value of 60 so uh to get the probability you have to do the reverse of this right so probability of error is uh what is it so it's q divided by minus 10 to the power of 10 yeah so in this case if I have a mapping quality of 60 and you apply that formula you're going to end up with probability of error being about 10 to the minus so the higher of course the higher the number the better the map the more certain the mapping and in this case what this the way to interpret this particular thing is that out of one million mappings that look exactly like this you expect one of them to be wrong okay that's what 60 means um usually like in different analyses if you have a read which is mapped to a repetitive region or you have some kind of artifacts the mapping quality the aligner will report a very low mapping quality so usually when you're doing an analysis like what what you do is to drop all mappings which have mapping quality less than a certain threshold like 10 or 30 or something like that right so that's usually the first few times this is what it means so 30 again 30 means one in a thousand of those mappings that you keep might be wrong yes so uh yeah so that's yeah so the question is what if we have a read which is perfectly mapped to two locations in the genome okay what what do you think the aligner would do in that case so it's in G so uh so the question is like what would the aligner report so you have the same read map to exactly map perfectly to two genome locations so what it does what the aligners will do uh if you're asking for the single best mapping location which is usually the case like sometimes you list all of them like you want to see all of the alignments like especially for some projects you want to uh uh you might want to do that but if you're just asking for the top of the location the mapping the mapper will produce either of those locations and we'll assign it the quality of zero uh technically um if you think about it the probability that the mapping produced by the aligner is wrong is exactly equal to one over two in that case let's say that the read comes from either of those two locations and nowhere else so in that case the the record that the aligner produces is wrong with probably one over two if you apply this formula to to one over two with probability of error one over two you're going to get like something three points something less than four so technically probably the uh mapper should report the quality of three or four but oftentimes in this kind of ambiguous cases just trims that down to zero so it's completely uncertain the mapper is completely uncertain that the alignment record that it reports is is like it is completely uncertain about it yeah yeah okay next is this uh cigar string which is describing so remember we have the read and the reference so this cigar string is uh describing the differences between the reference and donor in this particular mapping so in the in this example over here we have 76 matches so this read sequence is matched verbatim to 76 consecutive basis of the reference unfortunately this m doesn't tell you whether the base is uh equal or it differs from the one that is being mapped to so m uh m might stand for both basis being equal and basis being different okay so you can just like look at this and say that they're all equal um these are some other cigar strings like examples this is the reference of the donor so here you have four matches four by one deletion so this is the cigar is with respect to the reference so this base this t over here is deleted in the donor and then you have another six matches right in this case you have uh oh here you have like one base which is inserted which is this t and you can see in this case that the first four bases they're not all equal so the first four bases are mapped to the first four bases of the read however you have a difference over here between a and t right so and that's not captured by the cigar string okay uh the next fields in this uh uh um entry are the positions like the mapping positions for the mate and this equal means it's mapped to the same chromosome this is position of the mapping for the mate read and this is the fragment size so fragment size remember it's that is that fragment that we saw during the sequencing so this might be larger than the sum of the cycles so this could be up to 600 it depends on the the the way of the the library is prepared okay and then this is the read sequence and these are the base call again qualities so we're going to see we're going to look at some of these files in the lab and the last thing I wanted to talk about in the lecture are some sources of errors like in this whole process uh first of all when you start with sequencing reads the the reads that you get from the machine might be wrong in in all sorts of ways okay so you might have uh base qualities which are lower than what you would like or what you'd expect and those qualities could be low in certain positions in the read or you might have some kind of contamination on the flow so like maybe there's some substance over there which is interfering with the sequencing process or you can have overall base low base qualities you can have contamination either from other organisms or you might have contamination with adapter sequencing sequences uh uh so these days usually the the adapter sequences are being removed by the like from the data that you see but sometimes they're not or maybe in the past if you download again you go download like an older data set that might have contamination with the adapter sequences that are are used by the Illuminal process uh because of that so the first thing we're going to do in the lab is we're going to inspect the input reads with some software which is called FastQC and that produces various types of reports and you can see some some kind of these uh things errors you can they can be captured by these things so we're going to look at those in the lab um so that's about the input data now what about the mapping errors so let's look at these two uh uh situations over here so left and right in both cases you have uh this is the uh the coverage right so this is the amount of reads mapped to a certain base in the reference and if you have a graph that looks like this on the left and here one on the right so now the question is what do you make what do you think this kind of a bump what does this mean so that can it possibly mean that there is a let's say a duplication in the reference like maybe this region occurs twice in the reference so then it's being sequenced more than then the the region around it uh or can be can it be that case in both left and right so i'll i'll just that is the answer so the the problem that you might see with Illumina sequencing which is exemplified in the left is that of duplicate sequencing duplicate right so um during PCR amplification the various molecules which are attached to the flow cell are being amplified uh at different rates so PCR uh so some molecules might be favored by PCR so that they get you get more copies of those molecules than than others okay so in this case after mapping if you look at all these sequences over here so they all map to exactly the same location in the reference okay so that's like a big warning sign that all of these molecules might come from the same fragment before PCR amplification okay so that and that in turn means that this bump over here could be entirely artificial so you might be seeing this bump in coverage just because the fragment at that location was uh somehow favored by the PCR amplification it got overrepresented and you see too many copies of it yeah i thought that there are some recent Illumina technologies that don't have the PCR step anymore they just sequence whatever yes yes so yeah so that depends on the library preparation like some steps they do not have PCR um others do so i'm just telling you yeah if you if you have PCR steps you might have you might have this kind of stuff um it also also from what i understand it's there are two types of duplicates one are come from PCR through this process and i understand that you can still get PCR amplification because the like the way the camera is looking at the slide of dots it might just read the same dot twice so you get optical duplicates that come from the same region on the on the flow cell so those are called optical duplicates as opposed to PCR duplicates those you might have all the time no matter whether you have PCR or not okay so uh the reason for this thing sorry the the way to deal with duplicates is to run some kind of software in this case we'll use Picard which finds and marks this kind of duplicates so that you can remove them so you get better estimate of the of the actual copy number like in your analysis downstream uh indel alignment okay so let's look at this picture at the bottom so forget the top half like look at the bottom half so uh remember i said that uh the primary source of errors for Illumina data are substitution errors as opposed to indels okay so that fact is used by the aligners when they decide how the various bases in the read are mapped to the reference and the specific error that we're going to see in this case is that uh substitutions are much more likely to occur than the there is the insertions like with Illumina bases so okay let's see what happens in here let's look at this bottom part so you can see there are one two three four five so there's an about nine reads over here who's who have the right end of that read like in this same region okay and they're all clipped like this is this is a visualization tool that you're gonna learn about in a different module but basically what it says is the colors are saying that those bases are not mapped to that particular location but what's weird is that all the reads in this region that end here have the same like right see the bases are the same like the colors are the same they're aligned the same thing happens for the reads which end in this region where the left end is in this region so here you have one over here and then another three right let's forget about this read maybe that's erroneous so what happens here is that the the aligner is taking each one of those reads like one at a time and is trying to map it to the reference and it finds these kind of errors and it because of the scores that it's using it says well this is a substitution error and then this is another substitution error and so on okay one thing to keep in mind is that the aligners the aligners are always processing one read at a time and then perhaps we're using with its mate pair but then they never look at two different reads okay so the aligners take one read do it process it map it take another read process it map it and so on so that's why the aligner never sees this kind of bigger picture that you see here okay so what happened in this particular case you can see this read it's like right in the middle over in here so you have a read which is mapped over here and then this is a big deletion and then the read continues over here right so what happened in here is that you actually have a bigger deletion in the donor with respect to the reference okay and because of the scoring seam and the underlying assumptions about Illumina data the aligner is prefers to map all these reads with substitutions rather than deducting that there's like a large deletion like that okay so again this this type of situation can lead to errors like variant called errors downstream so it's one of the things that we clean up like at the right after mapping this is another example of the same it's exactly the same thing you have reads which end whose left end is here they have one error and then reads with the right end over here they have a different error and then if you realign them you observe that this is all resolved by just calling like one deletion over here okay the software which does that which we're going to use is called gtk it's like a standard tool and that software it will be able to it's able to look at all the reads mapped to a certain region of the reference and realign them locally so again this is something that the aligner never sees the aligner only sees one read at the time so it's never able to to do this kind of thing friends okay and then the last thing is novel sequence and this is the hardest kind of to deal with so when you have a reference genome and a donor most of the donor reads will map somewhere in the reference okay but it will always have regions in the donor which are completely not represented in the reference like they're just not there just because because of differences or maybe the reference is wrong so for that reason you might have in this image let's take this example we are this see this red dot over here the red bar that signifies that the region we're looking at is right next to a center mirror in chromosome two in this case this is chromosome two so it's next to the center mirror of chromosome two and you have this kind of coverage map right so this every line here is a read map to this region and you have these bumps and over here you have some really huge bumps and so on so what's happening here is that most probably the donor and the reference they differ in the number of copies of some of those really repetitive regions next to the center mirrors right so maybe the maybe the donor has more copies and what happens if you'd have that you'll have more reads coming from those regions and then the aligner will try to force those reads to be somewhere in the reference but it doesn't have that many possibilities so then it ends up creating these huge bumps in these areas which are a lot of donor reads mapped to the same location okay this is not so bad if you see this kind of picture it's it's very hard to do any kind of variant calling in this in this area so just because yeah so the only thing you can infer here is that there's too much variation between the donor and the reference in this region to say anything smart about it this is so this picture is only showing the situation with some repeats in your center mirror region but in the donor you might have completely novel sequence which is not representing the reference and it doesn't have to be repetitive okay when you're trying to map it to the reference that those reads might end up being mapped to like completely wrong things okay but that's that's something you really cannot do anything about right because you're just trying to map to a reference and you have sequence which is not mapping there so you don't know what to do okay so there's no magic wand to like solve this novel sequence because that's one thing you have to deal with when you're mapping to the reference okay so that's that's that any questions if you don't we are ready to go into the lab yeah one reason so okay so the question is how does this if i understand so how does this picture over here how is this related to gene duplication or kind of for example in our bacterial system if you do random duplication sometimes what happens with the transposones same sequence can get inside to the operand of different position so if i want to identify that the transposon wins in the only one operand or in modern model so if i get something like this should i say that so more than one so no so what i was trying to show with the left and the right panels here was that the left panel is much more suspicious of duplication than the right panel so you might have legitimate copy number variants between a donor and the reference right you might have genes duplicated regions duplicated right so the the donor has two copies there's only one copy in the reference and because of that you will see a bump in coverage right so that's kind of what's the right image is showing the the problem with the the left image is that when you map these fragments they're not just all mapped to the same region but they the exact break point where their map is the exact same right so this is why right see they're all aligned over here so that suggests that the fragment during the luminal sequence is that they can't they come from the fragment is the same and again that that's an inference that it could be of course it could be then you take the genome DNA you share it and you have two copies in the donor and it so happens that the sonication whatever produces the exact same fragment with the exact same break points and you have two copies of that that's that's also possible and but it's more likely in this case that if you have the exact same break points that they come from the same fragment prior to PCR so that's why we call them duplicates so again the difference is that the it's about the break points here like on the on the right you still have some PCR probably PCR duplication over here there's like several molecules which start on the same thing but overall the the increase in depth is like much more gradual than this this kind of steep thing


All right, good morning, cyber traders. Welcome back. Good to see you all on this happy Monday, everyone. Looks like we're having a pretty interesting morning so far, which is ABOS. Good to see you all. Good to see you all. Good morning. Everybody can hear it loud and clear? Just give me a chat back. Let me know. Warren, I have to see if everybody can hear okay. All right, good, good, good. Just want to make sure. All right, good. All right, everybody. So let's just touch upon what's going on that happened last week. Let me tell you, last week was actually a really, really good week. We did a lot of things out of moving in the market last week and there's quite a few stuff that are moving this morning. By the way, I did a post and if anyone's following on YouTube or if anyone's here following on Instagram, on the short reels, I basically did a quick little explanation of this ABOS about what a ladder effect is and how that stock actually made a really big pop. I had it right here actually. It's going to be a little bit, you can probably see it now, but there was a big ladder effect that kicked in here around seven o'clock in the morning and you could see, I'll zoom in a little bit closer and you could see how it was building up right here. What a really, really, really nice move on that stock and you could see how it just literally ran from like $9 all the way to $13.  And if you were here early this morning, I know some of you guys really catch up on it so that's great to hear. But there's so much more that's moving on but it's going on a watch list. So let me get my little legal pad and write this thing down. So we have the ABOS, there you go. All right, early bird gets the money, like we always say, right? Let's talk about what happened last week and then we'll go through the watch list and see how we're prepared going to this week. Now I told you that because we were going in, coming back from the 4th to July weekend, it things got really, really exciting. Probably the big thing everyone's hearing about was all the crypto stock. So with Bitcoin, everything else with the news, the ETF and one of the regulations that were lifted, but Coinbase took off the last week. I mean, this thing was a rocket ship. You could see it here. It went from like $80 up to about 90 and then it's shot a couple of days where from like 85 up to 110. And you know what? Some of you might be like, well, I really can't afford that stock. That's okay. Married did the same thing, 10 to 20. That's almost like a 100% move. You had Riot too. Another big one up here, look at this. Stock will literally went from like 11 all the way up to about 20. So as much as you might not probably could afford or maybe you want to deal with Coinbase because of the price, these things obviously went really, really well with them. But there was so much out there that did move last week. You had this HIV, this one ran from three to seven. That was a nice little mover last week, bit BITF. That one ran from $1 to $2. Nicola was awesome last week too. Nicola was out of nowhere. This thing just literally one day ran from like $1.30 to 225. And the thing almost shot up to $3. That was a good runner up last week. Had this little pop in this RXRX, it was okay. QBT, this one's a 60 cents up to 250. This one was also awesome. AOI, this thing ran, you can see last week. Was on a really good swing trade. And by the way, for some of you here that, and I know we get people that come from options, some people go into swing trading and they're like, well, I'm not really a day trader. Well, if you knew what was happening over the course of the day, you would know what to swing trade. AOI, this thing ran from $1 to $11. It's up almost at 1,000% in less than a month. So even last week, it just kept going up and up. Looks like it's done right now, but these are things that we traded. Cjet was okay. This one, KSCP, this one's going back on the watch list. So it's a 50 cent stock, it's already at 230. It just does not want to back off. Just not want to back off. KSCP. Now, just like Nikola, like we talked about last week, whatever goes up very fast comes down very fast. So we want to be careful when we go out there, we trade stocks like this, especially up being up that much, we're always looking to take that profit. So be careful, but we're putting this one back on the watch list. Also, PRFX, this is another big runner, $5 stock up to 25 that we traded last week. Looks like she's up a little bit right now at 14%. You know what? Big short squeeze on that stock, huge short squeeze. And just like I said, whatever goes up comes down twice as fast. I'll put it on the watch list too. I mean, listen, we trade these stocks and we got in and we got out of them, but they've been pretty good. Grant says the ABO is also a good one in the cybergroup room. ABO, Grant right here in the trade. ABOS, he's talking about ABOS, there we go. So we're going to keep an eye on the ABOS and we're going to watch it. We have the level four going on right here. Just only concern, it's up about 81%. And I know that if you came out from the weekend and you're one of these people that couldn't trade right now because your broker doesn't lie to trade until the market opens up, when we already hired you like, damn it's at 14, I'm at 11, I gotta get out. Trust me, you're going to get that slingshot. And then we'll see the second way that comes in when the market opens up how we'll trade on that one. All right, so anyway, let's look at a couple of the stocks that I'm moving here in the watch list. So you could see ABOS is on the biggest percentage gainer right here. It's also the biggest volume leader at 11 million. Second stock on the list is BBIO. Now, BBIO had a big early move here at seven o'clock in the morning, but she's kind of flat right here, which you gotta see what's going on here in level four, which is not really a big fan of it. You could see the spreads really big, small tier size on level two. Remember that makes it really not that tradable. It starts automatically when I start seeing a lot of ones, I'm thinking category four and five. So I might even consider passing on that one. Remember, it's Monday, come back from the weekend. A lot of people are obviously not a lot of news, but it's going to be a very, very busy week this week with earnings, you know, we've got the bank stocks and all that stuff coming out. And the FY, nice move, 260 went to 360. It's been on a big move right here. We traded the stock last week. Some of you remember it where from $1.90 to about $4, about 50% in that day. That one's not bad. We'll keep that back on the watch list, NVFY. You know, sometimes it's so hard to keep a whole list of stocks that moved last week, but they are trickling in right now. HCTI, this one also, nice little move right here, pre-market, starting to make a move here at $8.30 from $4.50 to $5.50. That's pretty, that's not bad. That's what we're looking for. HCTI, let me go see what's going on here in level four. The stock had a really big gap up you could see here from six to 11 and came really, came right back down right here. See right here, had that big move up right there. So could be a big short squeeze there. Let's see what's happening here in level four. What do we got going on over here? So we got a couple sellers that showed here for $8,000. It's not a lot. This seller got executed, which is a good sign. It had a big pop right there. Something that we're looking for. That one's not bad.  We don't have those great lists, like Tuesdays, Wednesdays and Thursdays when you hear, you see all that stuff. That one's okay. GP, this one's going back on the watch list. GP has a really good move, $4, great pre-market. 1.6 million shares of 24%. Price is right. Nice, cheap. Why not? That one's not bad. This one's kind of slow. A lot of stocks with 15%, but tier size are really small. Not really that much going on in pre-market. Looks a lot more gap-ups. Any good losers? Ouch! This one is not looking too good. Becan, this one's taking a very big hit. Nine o'clock program trading kicked in. You can see it right here.  Took a very big hit. And do we have a old time low? Yep, old time low. Stay away from it. Not even interested. This one, another one that's getting crushed.  I brought that thing down. Another stock down 50%. Just broke old time lows. Not interested. This one had a little bit of a sling shot. $90 stock came down to 50. Went back up to 60.  A little bit faster moving stock. Unless you're one of the advanced traders. This might be up your alley. New York stock exchange. Anything going on here? A $70 stock, not interested. Ooh, chewy. It just ordered from them last week. From my cat. Nice. Looks like it's testing resistance levels though. It's up about 5% of $2. Oops, 5%. We don't have minimum 10% when I'm interested. Man, this NOK is not doing too well. All right, so we got one, two, three, four, five, six and probably only four of them, probably pretty decent. A typical Monday pre-market. That's what I could say. Listen, the big move was the A-V-O-S. If you were here early in the morning, you jumped in here at eight o'clock, got programmed trading at 10, you did pretty well and you're pretty much done for the day. But stock market didn't open up for some of us. Some of us are just showing up right now so we'll see how things work out. Listen, we always find new stocks that do show up once the market opens up. All right, anything I'm missing, I did not call out. Anyone else see anything else out there? Think I pretty much does it what we got, all right? So listen, don't forget, we're gonna be live back here at 2.30 if you wanna catch us on the afternoon. We're live every morning at 9 a.m. at 2.30. We'll find that watch list for you. Make sure you are subscribed to our YouTube channel and also subscribe to our Instagram. We do put these little quick little 30 second, 60 second reels as we see them. We'll share them with you and please like us and share us, okay? Do everyone a favor and sharing is caring. Hate seeing people lose money. All right, everybody, cyber traders in the cyber group room. We'll see you when the market opens up. We'll start commentary in 15 minutes. If you are also watching on social media, you'll see here in the top left hand corner, we got a QR code. You can just take out your phone, just scan it, do a trial, you can join our room for a week and see what it's all about and see what the hell is all these things that we find and where they come from, all right? So we'll see you then. Good luck everyone, happy trading. Let's have an exciting week, okay?


Good morning. Hope everybody was enjoying Miami last night. It looks like we have a good crowd. It looks like everybody's awake, which is great, because sometimes later in the conference we're not quite as awake. I'm here to introduce both my talk as well as an entire track of talks in this room all day today about the Apache way, which has a lot of different meanings, but really what it means to you is effective open source project management. It's not just part of the ASF, it's a good way of doing things. Really, there have been a lot of Apache way talks in the past, and I was trying to think of what you want to learn about the Apache way that makes Apache projects so successful and so long lived. And it's really the behaviors that a community has and works with together to produce a result. It's how they do it that helps our communities be successful, be welcoming, be long lived, encourage new contributors, because really our point is to have long live projects. And bringing in new contributors is the most important thing you can possibly have, because then they will help you continue the project. And for those of you who are committers on an Apache project, these are required behaviors. This is part of what the board expects projects to do. In some cases, some projects have a specific way that's different. If they can explain how that works better, okay, then the board will be fine with that. But you need to explain why you're doing something better and different so that we can evaluate it. And maybe we'll add it to what the ASF considers the Apache way. So today is a whole track of curated talks about the Apache way from different perspectives. In a lot of conferences in the past, we've had a single talk on it, which doesn't, it kind of gives you a little bit of all the pieces, but it doesn't answer your questions about how projects work. And it doesn't answer your questions about how new contributors should do this. And it doesn't really help. So today we have this, right after this will be a coffee break, which I'm looking forward to myself. At 1015 in this room, we have a tale of two developers, which will be a formal dialogue between two employees at a large company that I'm not going to name, one of whom is an experienced Apache contributor, and one of whom is an employee told to go join this project. And the teaching process of how a corporate contributor as an employee can learn how to work with Apache projects. At 1115, we have from dev to user to the Apache way, with Steve Blackman who's here in the room right now. And he's going to tell a story about how an existing project community outside of Apache came to Apache, came to the incubator, and changed how they work together as a community to better work with Apache, and to find ways to draw in new people. Some simple things and some harder things. And of course we save the tough stuff for before lunch. At 1215, we have a panel discussion on software is easy, but people are hard. So all the great coders on GitHub who think the latest technical challenges, like that's the hardest thing I'm going to solve. No, the hardest thing you're always going to solve in an interesting situation is how to get people to work together on that technical challenge, or that voting campaign, or anything really. Lunch is on your own today. And then after lunch, come back please, because we have another panel discussion, the Apache Way for Business with Nick Birch, who's a very engaging speaker, so he will keep you awake after lunch, I guarantee. How your company, who might want to have a project that you want to bring to Apache, how your company needs to think about structuring the project. Not just your employees, but your marketing department, your product manager, how you're going to transfer control and gain the benefits of coming to Apache. And at 330, we have Sharon Foga, who will be talking about how contributions at Apache are not just code. Everything else is important too, documentation. Answering user questions on the user list, or providing helpful bug reports, are all things that are valued.  And of course this evening we have a couple of keynotes. Some talks about IoT from the Apache IoT conference here, some machine learning, and then a great talk about the last keynotes related to this, how Comcast and their developers and some of their projects that were donated to the ASF got some efficiencies from working in our way. And of course at 5.50, after the keynote, stay tuned for the lightning talks that Jim and I will be hosting, which will be guaranteed fun five minutes. You can talk about whatever you want, but no slides. And we time you. So let's talk about our topic here, the Apache way. And I think the important thing is defining the behaviors. But first let's take one pause for Apache way history. I've reviewed most of the past probably ten years of presentations about the Apache way, and they all start with how the ASF was created as a corporation, how PMCs were organized, and we sort of thought through the rules, or we grew the rules as we did things, and the history of the organization or projects in the way. But that's not what I want to talk about. Because what is history matter now? When you come here to learn what you can do, how you can make your project better, how you can get involved. And I think what's important here is learning what the behaviors are, learning the actual actionable information, as we'd say in a corporate speak slide deck. What can I do to help my project gain new contributors, to make it more friendly, to answer the board's question, because they were upset with us for something. So I don't want to talk about the history. I don't want to talk about the past or the rationale here. Now, I do have a question. We're just skipping all that history and all the past information. Do you think that's a completely good thing, or do you think we're missing something if we just skip that? Do you just want the actionable information, or do you want the history, too? So that's something I'm just going to leave you to think about. Throughout the day, I think a lot of our talks later in the day will answer those questions for the points they bring up. Like Steve will talk about, we had a great project community, we came to Apache, and we needed to change things. And after we did it, oh, that's why this is better. We got more people interested because he learned the history. But the history doesn't help you unless you've seen the actual example. So let's move on. And we have a menu of services today. So what behaviors do we want to talk about?  So I have five topics, and then questions to answer is not really a topic, that's just Q&A at the end. Community is a topic over code, which we say we believe in. Merit, recognizing an individual's work, and what comes from that. Open development, which the ASF requires for everything, that's just how we do any of our work. Decision making, how we get consensus and how we use votes. And communication. So today we're lucky because we can communicate in person, we can talk to each other, but usually we write at each other or type at each other. So that's a different aspect.  What topic do you want to talk about first? So is there something that somebody has a particular question for one of their projects, or you're just dying to hear first, or don't make me pick a random topic, because I do some... Decision making. Okay, I should have thought of that. I should have thought that that would be... Good, nice, I like that. Decision making, how do we make decisions for our Apache projects? So one important thing is consensus. We talk about how we want to have consensus-based decision making. There is no perfection in software. Things are never finished. But things can get better step by step. So fundamentally, at Apache Projects, our goal is to serve the public good with software that does stuff. So any new features from you over there or you over there or you in the back, they're probably good things. So we don't all have to agree on some new addition as long as it's good enough, or as long as it doesn't make our tests fail. Because what you might think is really important, I might not care, I might not... Who cares? But okay, you can still add it, because you care. It's valuable to someone. So that's why we want to get consensus enough, like okay, this is good enough, but we really should think about changing the API that way, because this would be better. Okay, we'll discuss it a little bit. So that does make you take a little bit longer to develop things, but you end up with a better product in the end.  So when we do need to have votes, we do have them. So they're here two quotes about voting in the Apache way. So the first one is voting is a shortcut. So sorry, let me pause. Voting is the plus one, minus one, sometimes plus or minus zero, where plus one means yes, that's a good idea, and I'll help you do it. Minus one means no, I don't agree, and here's why I don't agree. You have to say why, and there has to be a reason that people can recognize, not just because you don't like it, or because it doesn't help you. So voting is a shortcut to move consensus forward in a timely manner. So that's one aspect of voting, when we're deciding things. Another aspect is voting is a way to record an official consensus. So one of these quotes is what is good, and we want to see it. In fact, we have to see it. It's required. And the other quote is okay, but it's not really the best way to proceed. Anybody know the obvious answer? Which one is definitely right? Which one is important? So the second one, recording official consensus, that's required. That is a good way of using votes. When a PMC makes a release, we have a formal vote, and that is the PMC as part of the foundation saying as their role of people working for the foundation, this release is appropriate, and it's a good thing to put out to the public. And that, or deciding on new committers or PMC members, you specifically gain a recorded vote that says okay, this is done. That means those actions, you're not doing those as yourself. You're doing those actions on behalf of the ASF, which hopefully will never matter, but if there ever is a lawsuit, that is how we provide a legal shield for everyone. It's also how the board can provide oversight to say, yes, the PMC has decided on this. That's what we're doing. Okay, we can see the list. We can see the vote. You're done. You might change your mind later, but you'll record how you do that. So the first quote, voting is a shortcut. If you really can't decide, then sometimes you need to have a vote to say, okay, do we really have enough people who will agree, and maybe you'll get a lot of plus ones, and you'll get a bunch of plus or minus zeros, people who aren't really happy, but they don't have a veto, they don't have a reason to stop the new action. And there are some projects, let me say, there are some projects that happily use votes for a lot of different things on the new roadmap and a new feature set, and they like using votes. It works for their community, it's documented, and it's expected. And that's okay. That works for your community, great. But if your community can't get consensus repeatedly and turn, falls back to using a vote to force something through, that's not healthy. So we want to speed up the decision-making process with vote sometimes. Well, in the Apache way, there is a timeline for decisions. And our timeline is not, it must be done by the end of the quarter, like in a company. Our timeline is, you can't finish this decision until at least 72 hours have passed. So we all come from around the world. I don't know if there's anybody actually from Australia or down under or the Far East in the room right now who lives there, but we have several little Metapachicon. Ensuring that any vote is open for at least 72 hours means that people can see their vote, have time to respond, even if it's over a weekend or something. Yes? Yes, you should be cautious of major holidays in different geographies that your community has. And it's certainly always good to wait longer than 72 hours if it's a big decision. It's also a good reason why you have a discussion thread. If you want to have this crazy new architecture, well, discuss it for a while. And then once people have kind of said, okay, that's good. We've solidified some things. It's not completely done, but it's close. And people have had time to talk about it. Then have a vote thread, right? Because people have had time to digest. And the people we're talking about are from around the world, from different backgrounds. So this is a complete opposite from the corporate world many of us work in. There are no deadlines, or there are very few deadlines at Apache. Because we as a project don't have any deadlines to get something done by, except those that we agree to do together. So we all volunteer from the Apache perspective. You're all volunteering. You're all being super nice to give us all this great code. We can't ask you to do something on time. So if the community decides, yes, we want to get this release out by X, because our users want it, and we're going to put the effort in, great. But that's up to the community to decide together. So that brings us on to back to the venue. So we've done decision making. So where do we want to go today? I'm not sure if I should use that phrase here, but communication. Okay, communication. How are we right? So as I said, we're lucky today to be able to talk in person, and there's a lot of richness, but almost all the time we're typing, and we're typing from our little offices or our beachside patio if we're here in Miami, or from our bed at night after everybody else has gone to sleep. So it's important to remember that when everybody else is reading their little screen, they're in a very different world.  That's, you know, the really cheap way to say it, and this is the way that many of the early Apache wayslides said it. Avoid the poisonous people. Now we can't always avoid them. We, like I can't, and you maybe can't because they send mails and they're in your list, but we as a community can work to mitigate the damage they can do. We can not feed the trolls, all those things. It's still a good, it's a little bit long, but it's still a good talk by Brian Fitzpatrick and I can't remember his name. How open source projects survive poisonous people, but that is still a talk worth listening to. Whether you're in a Apache project or anywhere else where it's, you know, people choosing to gather together rather than at a company where you're told what to do. So we can't emphasize this one enough. We have a code of conduct at the ASF. Thank you to the CouchDB project that originally drafted one in a very thoughtful way as a community focused on the behaviors, not on the people or the whatever. So it's a good thing. It's not something we want to use. It's not something we want to say, this is a code of conduct violation. It's something we hope that communities can, you know, surface as an expected way that they communicate and that when you communicate, remember to hold that in yourself, even if someone else is not, try to respond politely. I know that's hard, but... And the other one is when someone is regularly abusing or what you feel might be abusing, but you're not sure, in a project community, work with the rest of the project community to address it and ask the question. Whether that happens, that's one of the few things that if you're really not comfortable having it happen on the public development list, ask a few people you know in private. And the great majority of the time, even if you're worried about the feedback, if you ask in private, you'll find, yes, other people are exactly in the same situation you are. They have exactly the same thought and they're like, I just don't have the energy to call on this. And once you find that there are three other people who are like, I don't have the energy. I'm like, that's exactly what I thought. Then one of you can bring it up and you know there are people who are agreeing with you, who are saying we need to be polite and respectful of everyone else and we need to focus on the project work, not on whatever else in the world there is. And language for communication. This is not a slide I'm happy about in terms of what we do, but I think this is the reality. The at Apache, the Apache way the methods can be applied elsewhere, but at Apache, as we practice it at the ASF, the core development activity in a project must be in English. And at the current time there's no way around that. And we've had a couple of real questions where we've had projects in other languages with primary developers there and we can't bring them in for incubation because translation software isn't social. You can't just read a mailing list and put it through Google Translate or Bing Translate and then expect to be able to evaluate what's happening. And the most important thing for a community is that the PMC can provide oversight to the community. That the PMC as a whole knows what's happening, can give feedback on crazy ideas from committers, can make a decision to make a release or wait, can make a decision to add a new committer who's been contributing code. If the PMC as a whole can't understand the process by which that work happens, they can't make an informed decision. And in particular, the board needs to be able to provide oversight for all of our projects. So when we have a project report, projects report quarterly to the board and the board reads all the reports. We have a board meeting today later, actually. When the board, when the director has a question about a project report, we will go into your lists, we'll go into your private list and we'll review the past several months of traffic to see, you know, you said something kind of funny in the report, I want to see if you're going off the rails or if maybe there's a reason for it. And if the board can't provide that oversight, we can't operate. And the board currently, we all share English as a common language. So in terms of development activity, we can certainly support user lists, answering questions for multiple languages. And of course, developing software that has language packs and so on is fine. But the way the project moves its activity forward must be in English. So that was communication. Communication was kind of simple because that's sort of just working online and working in email. And remembering everybody else is looking at a screen like this, right? So we're doing the last two. We've got the first three. Where do we go next? Community. Oh, okay. Well, that's pretty obvious, I suppose. There we go. Well, so that's a really good word, community. So we all have many communities. It's like a gigantic Venn diagram of millions of overlapping circles. So what do we mean by community? So we don't live together. Most of us don't work together. Many of us don't know each other until we've met today. Hi, I'm Shane, by the way. Nice to meet you all. Glad to see you. Except through our project. So this is a different... open source development is in some ways a different human activity than virtually any other activity in human history. And that we can all work constructively in a very, very rich way on realistic tasks completely anonymously online from anywhere in the world at any time in the world. And it's hard to remember that the project community, all the members of it, all have their own communities of communities and that we're coming together for this one software thing. So it's through our projects that we know each other. And that's the community when we're talking about an Apache Way community. And that includes the developers, writers for documentation testers, sysadmins, devops, and users. So the people who are not always obvious in an Apache community are the users who are using it and who might be frustrated but haven't gotten around yet to reporting a bug or who are gonna try and sell their boss on using this for everything. So those are great projects like some of the ones we have really engage users and make it easier for users to get help, have forums, you know, have an ecosystem of developers or consultants who can provide other services to you around the project separately. But we need to think about that whole community and that's what the goal is to serve that whole community with the best software we can. So, yeah, this comes back. But this is a different message than no jerks allowed earlier in that Apache communities value group contributors, not lone wolves. So Apache is different than a number of other foundations or common or popular open source projects in that BDFLs, benevolent dictators, are not allowed. We will not accept projects who act that way.  The board will prevent that because that is not, in our view, a healthy, long-lived community because it doesn't allow, it doesn't make it welcoming for new contributors. If you perceive that this, this is one person you won't be accepted. It's the same way with companies. If it's perceived that one company runs a project, then why would other companies ever have their engineers contribute? Why would they consider using this? Because the other company has a lot of luck. So that's why we need a diverse community. And your primary goal for the really big picture is attract new contributors. That's how you have a long-lived project. So, in the immortal words of Bill and Ted, be excellent to each other. That's... I don't know how to say it. And it's being respectful of everyone else. And it's also focusing on the work of the project. So other discussions, some projects have a social community, too. But that's not necessarily part of how we need to build software. So the other question sometimes is keeping the discussion focused on what the project really needs. So for a community, we all wear different hats. So for those who aren't aware, hats are sort of the symbol for who you're speaking on behalf of. Are you Shane, the Hawaiian shirt guy? Are you Shane, the currently unemployed house husband and father?  Or are you a director of the ASF who is telling a project they shouldn't be doing something? What role are you taking when you are speaking or typing on a list? So that's doubly important for anyone in a corporate setting because Apache does not recognize corporate contributions. We have a sponsorship program with money. That's separate. We recognize actions. You are all you when you're coming to an Apache list and contributing and we recognize you as an individual. So for corporate teams, which we have many of, a side effect is that if your corporation wants to work on a project, each of your individual engineers or managers or product development people, we don't see them as a team. Apache sees them as a bunch of different people. They each need to do their own work to gain merit, which is one thing. And a side effect is that your actions reflect on you throughout your personal career, not just when you're at one company. So it's important, sometimes you do need to speak for your company. You need to say, my company has this really serious bug and we have other customers and we, you know, I'm going to work on this in the project and I hope other people will. But the rest of the time we expect you to be speaking for the benefit of the project as a whole. Which is, I sort of got these slides backwards perhaps, check your affiliations at the door. So when we make decisions at an Apache project, there's not a hierarchy within a project. It's not the chair of the PMC and then the senior members of the PMC and the rest of the PMC and then committers. It's the PMC and it's the committers. That's the decision level of the project. That's the final vote. And every project has a completely separate way of doing things. So the other aspect of this is that your fellow PMC members, when you're interacting on the project list about the project, we don't care what company you work for usually. We don't care what role you have at your company. So we actually have airline pilots and major financial company CTOs and directors who are committers on Apache projects. That doesn't matter on the project. What matters is how they act in the project space and what job they do there. So the upshot of the hats and affiliation and having a flat PMC is that part of the Apache way that is required of all projects is that the project is governed independently of undue commercial influence. The way that we enforce this is that the ASF owns all trademarks on behalf of the projects. And the board of Apache will ensure that if a PMC goes off the rails, or if some company tries to subvert a project, the board can step in unilaterally and fix that. Now, that is not a pretty sight and you don't want it to happen, but it rarely happens. So hopefully we won't have to talk about it. But your project, you own your brand and your how you interact with the world and your code and you own your own governance as long as you are independent, as long as when new contributors to your project show up and do valuable work that they're recognized on their contributions and not on their corporate affiliation.  The project hasn't seen that. The project hasn't seen the things that you've seen as being a co-worker of theirs. So that's one thing to look out for. And the other one is where great committers from this consultancy and this other competitor of the major company in the area put in a lot of work to the project but never get recognized by the PMC. Nobody in the PMC chooses to vote them in as committers. And it's, it's rarely ever planned but there clearly have been cases where many of the PMC members who work for the dominant vendor simply choose not to recognize them. And that is not good because that will then discourage anyone else from contributing. And that is something the board pays attention to. It's not a hierarchy. It's a community. In the context of this project community. Separate from your employers and the rest of the world. So that's what I have on community. So we have Merit and Open Development next. Open Development. Okay. She's been paying attention. Wants to speed things up here. Open Development. So just one quick reminder when you're thinking of this. We all kind of know what open source is. We have an esoteric debate on the legality of the term perhaps. We're talking about Open Development where in the process of creating the software is explicitly open. It's also open source but that's the point here. So yes, we use mailing lists to Apache. And sometimes they're annoying but that's how we do it. Because mailing lists are asynchronous communication. So we're a community about a project. We're a community in this room. And we come from all around the world. We come from day jobs that are nine to five. We come from DevOps people who work on shift off shift. We come from college students and people who are unemployed and do this as a hobby. So ensuring that we don't make decisions today. We're not going to decide a new aspect of the Apache way here in the room. We might talk about one but then we bring it back to the list and let the broader community think about it. So when we only know each other through the project we need to make sure everyone else has a chance to respond to our great new idea. So archiving everything is another big thing in Apache. If it didn't happen on the list then it didn't happen. That's an old adage at the ASF wherein in the big picture if something wasn't surfaced on the list then we don't consider it a proper action of the project. Because the board can't provide oversight or your PMC can't provide oversight if it was a group of committers. Newcomers to your list or newcomers to your project can't learn about what happened.  They don't know where it came from or why. They never had a chance to participate in the development of that thing. So having everything in a public list in particular is important because that allows everyone else to everyone else to see both today as it's happening and in the future when people can come by and say to themselves well I don't want to ask about this stupid question. But if they look in the list archives they can see how you've got some place. So making sure that we have an archive of everything is important for bringing in newcomers and it's important for community members because we have arguments in a year from today about what happened and somebody will say oh, here's what we decided on the list. Or you have a clear reference of what the group decided. So a key part of this is both motivations and decisions. So we need to have transparent decision making. So we each have our own motivations for being here. I'm here because I love Apache. Some of you are here because you work for your employer and it's important to play with Apache projects. Some of you are here because you work on five Apache projects and you want to learn. All those motivations are invisible to the rest of us. I mean even more so than when you're at work, when you're at a company you and all your coworkers and your bosses you all understand the company direction. We all are completely separate individuals. We only see the work through the project. So it's doubly important to make sure that we telegraph what we're thinking about for the project. So I was just talking yesterday and I want to figure out a better way to write this list. A really concise list that we can just post someplace. The best way to work in an Apache project is telegraph your intent. I've got a great new idea. Maybe if we switch from Json to YAML we could make it faster. I don't know. Put that on the list. Crazy idea. Then, wait a little while. Draft a design. Say, hey, here's how the API would work. I'd use this parser. Put that on the list. Let people see the process. Because you're part of a community. Other people are going to have feedback. Sometimes other people are going to say, oh, I've already done that. Just copy this. When you're working on your code check in early. Check in often. Submit work in chunks. Submit. Here's the API level. It's all the thing. It's a basic test, but there's no code in it. Now I'm going to code all the file modules so people can see, oh, here's how you're actually using the format. Doing a giant code dump is not helpful because no one can review 50 code modules that are brand new as a code review. Which some projects do. Some projects don't. That's fine. Doing each of those steps on the list gives the rest of the community time for feedback. Time for new ideas. Time to help you with your work. So that is important for all Apache projects. And this is what we mean by open development. That the process is done on the public dev list. And I wasn't quite sure where to put the license. But I think it kind of falls under open development as Apache is pragmatic about licenses. So we use the Apache license in 2.0. That's period. We have a very specific list of other licenses that are allowed as subsidiary bits, but everything that comes from Apache is under the Apache license. The point of doing that, which sometimes we've, you know, every couple of months we have a project saying, oh, we really want to use this library. It's the best one out there, but it's GPL or it's this or that. No, sorry. And they're like, but it's easier. I'm like, yes, but it does not meet our goals as a foundation, as the ASF, as the Apache brand does not meet our goals of maximum user freedom. When we give out software, we give it out for the public good. And when it push comes to shove, that's a key way to decide things in Apache is does it help the public good? So the benefit of that is that people can then use our software any way they want. And the real benefit is using the Apache license on everything makes it super easy to consume us anywhere, and encourages the maximum inbound contributions. Because that's what we want for a long-lived project, is new contributors. And this makes it easy. Anyone can contribute to us. I suppose if you only use the GPL then you can't, but we want anyone to contribute because then they can simply take the code back. Right? Share it. And part of the reason that the foundation is important is that people have trust in the brand and the they know what to expect from Apache projects. Because we always use this license, we always provide the code, we always do open development. Even one of the things longevity of software projects, we may not care about struts or Wicked anymore, because they're kind of old, there's so many new JavaScript frameworks, whatever. People still run them. People still want them. Even if they serve a need for them. Even if the struts PMC goes away and we move the project to the attic, because they can't actively oversee the project. The ASF will always provide the complete history, all the source code, all the past releases, all the development discussions, all the lists, as long as the ASF is around. Another key part about Apache is that we will always be here. If you compare that to something on GitHub, who knows if some developer is going to disappear or in the left pad case, if some developer is going to get annoyed and simply take their code away. Apache will never take the code away. That is what I have for open decisions. Open development. And merit. We're going to have to do merit quickly, which is kind of funny because we are close to the end, right? Ten minutes. So merit is about recognizing your work. And some communities some people don't like Apache because they think meritocracy and then they think some sort of strange social construct that is inappropriate. Which is not what we really do in Apache. For us, merit is really it's defined by the value that you as an individual bring to a specific project. And it's defined in the context of that project by the rest of the project community.  That's not part of your merit. And it doesn't matter what you talk about what you blog about, what you've done in the past what you've done in other projects. What matters is what you've done in this project community that defines your merit. And it's defined by the peers of that community, not by anyone else. Every project has their own merit structure. So recognition in one project doesn't matter for other projects.  That helps, but it doesn't give you merit to change code changes in their project. A growth in merit is users and contributors who give us stuff. We love them. Thank you. You get voted in as a committer. A committer means that for that project you get voted in by the PMC you have commit rights to that project's repositories. Now they may have a commit then review or review then commit, but you have right access. That's the first important step. The second important step is the PMC may elect you as a PMC member. As a PMC member you can vote on releases and you can propose and vote on new committers or PMC members. Excuse me. There's sort of another level of merit that's really that important is a PMC chair or the vice president of the project. They're not... I made them not bold because they're really sort of a secretary. Their job is to communicate between the PMC as a whole and the board and ensure that the board report is submitted, but they're not meant to be a leader of the project. Everyone helps lead the project. Some people are elected to membership in the ASF corporation. That's nice and it's a good honor, big honor, but it has nothing to do with projects really. It's recognizing your work in many projects, but it doesn't give you any abilities there. And then we have directors who are elected by the membership to serve on the board of the corporation and that provides oversight for the PMCs. So we're still part of a community that's very flat. We're not a hierarchy. So everyone with a commit bit on your project has some say in the code on that project and can add their own new code to it. Everyone with PMC membership can vote on that project's issues. So merit is not authority. You can't say this is what we're going to do. You still need some consensus. But merit does get you privileges. It lets you take actions in the project and it lets you have a binding vote or binding say in some things within a project. So one problem area and I'm just about done is umbrella projects. Which I put in merit because we have several examples. One is Jakarta which is long back in history. Jakarta was an early project at the ASF that had a lot of different Java technologies and then kept growing. It was great because Java was cool beans and it was going to run the world everywhere, right once, run well, hopefully. There were so many different components and modules and sub-projects within Jakarta that the communities of people working on each of them diverge. And that's a problem because the PMC needs to provide oversight and governance for the project. So if the PMC as a whole can't evaluate is this project is this sub-project, this part acting appropriately? Are there any great new committers? Like a release. If the PMC as a whole can't evaluate each of the different bits of software they're making that's too big. They're becoming a board above several projects. And that's just, it's not efficient. It's also difficult to ensure that the Apache way and the corporate responsibilities we have are being held to the same standard. So that is why we tend not to have umbrella projects because each community needs to be focused on a set of tasks that in general the community members, the PMC members and committers all can have some effect on. Or at least can evaluate the work of on going forward. And that way they can provide feedback on things. And when projects get bigger than that we tend to simply say, well, you know, why don't you split up into two projects? No big deal. And that is merit. So if we take a different way we will do a lovely beach scene. And we will go to questions. So these slides are online. I'll tweet them out again later. And indeed the whole of the Apache.org website is online and is open to all committers. Of course only members can actually publish the top of a website. But this is an area where we need you to help out. So anytime that you are reading a piece of documentation on any Apache project that doesn't make sense, please ask about it. And if you can, if you get an answer submit a change for that documentation. That's one thing I think sometimes we fall back whether we're in a hurry or whatever to simply asking a question somebody gives us the answer like, oh, okay, great. And we go off and do our thing. Any time that we can change that and say, great, here's the patch to add that FAQ. Or, hey, I know this step of the install instructions are wrong. Submit the patch. That's just something that we, some projects do a great job of. A lot of projects not as much. The foundation website itself I'm not going to say anything there. And separately I have the Apache website that I've written. It's my perspective on all this kind of thing. That goes into a lot of the history and rationale of all these behaviors. So that also is open source and I'm happy to take full requests. So, questions. So we have, it's the end of the session. Okay. So I'm happy for a quick question and I'm also going to be here for the rest of the conference obviously. So, thank you.