Hi everyone and welcome to our podcast series women's liberation the marxist position brought to you by the marxist voice the podcast of socialist appeal in this episode we will answer the fundamentally important topic on the origins of women's oppression many people claim that it's inherent and part of human nature to oppress one another however this doesn't explain anything we as marxists are only interested in the in the true scientific explanation of our own human history where the depression arises from and how is it linked to class society and therefore how can we bring this to an end this series will help to clarify why marxism provides the only true revolutionary answer to these important questions to introduce myself i'm lubna badi member of socialist appeal and today we will republish a talk by lori on the origins of women's oppression he will explain this question thoroughly and we highly recommend also the book written by engels the origins of the family private property and the state to read with this to fully grasp this topic now let's get started with this week's episode of the marxist voice the podcast of socialist appeal we all know that women still today face unique levels of oppression under capitalism and this is despite kind of capitalism and liberal so-called bourgeois democracy having claimed to produce progress on this point you know looking around us today we can see that the the fact of the matter is that this progress is very thin at home obviously women are still shouldering at the massive majority of domestic labour at work we still see massive gender pay gaps and COVID-19 has turned back the clock even further women are bearing the brunt of redundancies mothers are 1.5 times more likely to have been made redundant or furloughed than fathers and domestic violence has increased massively victoria already gave the the shocking statistic in the first few weeks of lockdown alone 14 women were murdered in the UK so i guess the question that we want to answer here is is why is this the case after all labour under capitalism mostly doesn't rely on physical strength and women even have full legal equality in many countries domestic abuse domestic violence is supposedly illegal there's the right to divorce there's things like maternity pay women have the vote they have the right to work in fact they have more than just the right women are expected to work in order to support their families just like any other worker and why hasn't this done away with the oppression of women well you often hear the argument that this is basically because women's oppression is biological it's rooted in in our nature men are biologically physically stronger than women shouldn't this just allow them to get what they want and this exact this this argument that oppression is somehow natural is popular among some you know evolutionary biologists psychologists is very popular among conservatives who see this gender oppression and put it forward as some kind of evolutionary advantage that's kind of hardwired into us but shockingly enough you know this argument is also quite popular amongst some feminists who argue that a sort of male monopoly on force allowed them to dominate and exploit women basically since the beginning of time and this understanding which sees the oppression of women is something that has always existed is a very depressing one after all what can be done against human nature however it's not correct luckily after all even if men are biophysically stronger if you watch any detective movie you'll you'll know it takes more than just the means to make a crime if you're if you're studying your crime trying to figure out why it was committed you also have to work out a motive and an opportunity uh and the question then is have men always had the motive to oppress women uh and have they had the opportunity to do so well i think to understand this we really have to look back to the past uh and that the origins of women's oppression can't be understood on its own but as part of massive changes in the whole of human society so it's very convenient for the ruling class to encourage people to believe that the way things are now is the way that they have always been that inequality is an eternal fact of existence that selfishness is biological and evolutionary that women's oppression has always existed that we have always been governed by kings and by states but all of this is a convenient lie you know it's a convenient falsehood because in actual fact human beings haven't always lived in a class society where one small group of exploiters are living off the labor of everyone else in fact for the vast majority of the 300 000 years that anatomically modern humans have existed uh we lived in in relatively egalitarian conditions uh the Engels actually described as primitive communism and in these societies uh we can conclude that selfishness was not considered moral or normal that there was no conception of things like private property there were no kings um and in this time period uh what today uh we would call the paleolithic or the lower stone age uh archaeologists have also found little to no evidence of genuine kind of institutional inequality of any kind including women's oppression it's only with the sort of the beginning of the holocene uh or the end of the last ice age that we start to see some evidence of things like differences in wealth but even then this is very minimal and wealth doesn't appear to have been passed down from generation to generation we don't see any class differences um and right up until the bronze age we don't find wealthy burials and we don't find anything resembling money now obviously i want to come on to the specific topic of women's oppression but i think it's important to give kind of concrete examples of what this kind of society would look like so just to talk about one uh there's this place in the UK called in in britain called star car and it's a mesolithic site which is about 11 000 years old and at at this site hunter gatherers lived this quite basic kind of subsistence lifestyle they were fishing on the lake they were hunting birds and deer and they lived in temporary dwellings so no house was bigger than the other there was no intergenerational wealth and in fact the only permanent house we have is this one large round house uh that was a shared building uh that was the central to the community so it's clear that in these kind of primitive communist societies the community was working together to build and share resources um and at root all of this kind of egalitarianism came from the fact that there wasn't any private property and there couldn't be any uh beyond the possession of tools and other small personal items because these were for the mass park relatively small uh mobile hunter gatherer society so they were successful what they did but they lived day to day or year to year they didn't accumulate any significant surplus and in these societies we also have very little evidence of any kind of institutional oppression of women whatsoever in fact we have many results that show the exact opposite uh people might have read about the discovery of hunting gear hunting kit recently in the grave of a young woman in in the Andes and this grave is about 9 000 years old and this discovery led to research that shows that women in the early americas many of them participated in hunting and this basically destroys the idea that I was talking about earlier that in every society men have had this monopoly on force on violence they've been the dominant armed hunters and women have been confined to the camp and actually it's the opposite there was joint participation in economic activity and this strongly suggests a degree of you know real social equality and women weren't locked out of any kind of activity any kind of profession in primitive communist society like men they could likely do anything they put their minds to so long as it served the community now obviously uh there are qualifiers to this this doesn't mean that you know we don't recognize any kind of sex-based differences which obviously existed in prehistory but without the monogamous family and the economic domination of men over women that wasn't patriarchy we didn't have these fixed notions of the role of women or the role of men and in different societies sex-based differences probably would have had more or less impact depending on the particular conditions uh that that society in that community was was working in for example in these early societies it's possible that people might have been chosen to join hunting parties based not on kind of gender but on a physical characteristics such as how fast you could run or how far you could run and this may have meant you know that fewer overall female hunters compared to men but it certainly wouldn't have been an insurmountable obstacle like gender oppression later became and so women kind of occupying this different position in the division of labor uh at this stage in in society didn't result in oppression or exploitation and to go with this you know where when men and women were doing different work the work was regarded equally highly women who couldn't go out on like long hunting parties because they were caring for their children played an important role in either gathering food or playing a role at the central camp uh and this domestic work wasn't just cooking and caring for children not that's not important but it was also things like making tools which have caused vital for the whole community to survive and again you know this isn't just us making this up we have evidence of this if you look at a lot of paleolithic cave art archaeologists have compared like the size of ham prints in the art to skeletons from the same time period we can tell that these ham prints were were made by women and this cave art was obviously of extreme spiritual significance and these you know it would have taken a long time to do and these caves were often very difficult to get to and these women would have had to take a lot of time out of their day and time out of doing work for the for the tribe in order to create these and this is an indication of kind of the high regard that women were held in uh by by society and we can also see this in the actual art itself uh and paleolithic art a lot of it does emphasize the physical differences between the sexes you know we've all seen these like little prehistoric statuettes of women um but there's there's little art that implies this kind of came with any social distinction so one major convention in art is to draw people of higher standing vigor but we don't really see this uh in any art uh for example there are these cave paintings in Burzaham which is in India and these cave paintings are about 8 000 years old and they depict men and women but they're both depicted hunting and we can't see any indication of any difference in higher status or any class um so again this outlines all of these conclusions about the the position of women in prehistoric society and these are conclusions that many archaeologists and anthropologists have finally come to today but Engels actually anticipated them more than a century ago and in his work in the origin of the family private property in the state which I would very strongly recommend to read if there's anyone here who hasn't given it a read already he says one of the most absurd notions taken over from the Enlightenment is that in the beginning of society women was the slave of man uh and he says among all savages and all barbarians the lower and middle stages the position of women is not only free but honorable and alongside this uh you know this isn't just a woman as an individual but alongside this the monogamous family as we know it also didn't exist in fact non-monogamy uh group marriage cooperative parenting was the norm for for most if not all societies in this period of history uh and without marriage without monogamy lineage was traced through the mother's line rather than the father's and this you know it's obvious because the mother would always know who her children were and because there wasn't any way of dividing society by wealth there weren't cities social groups were often divided by kinship and this was most probably determined matrilineally passed down through the mother's line and so on a rare occasion that there was any inheritance that there were any kind of heirlooms to pass down there would be passed to the tribe or the group that were related through maternal lineage and we can actually see traces of this in early societies for example Engels uh he writes about the Germanic tribes uh who were described by Tacitus who was a Roman historian and the Germanic tribes uh just to say they weren't kind of pristine hunter-gatherers in fact they were agriculturalist but their society was significantly less developed compared to the Romans economically speaking and you could still see the the traces of this kind of matrilineality in these German tribes so if a man was sworn to an oath or a promise in such a way that a hostage would need to be taken uh it was far more effective the Romans uh observed to take a man's nephew hostage uh the son of his sister rather than his actual son and this is because it would be you know a personal tragedy for for the man to lose his own child and it would be a sneer on his honor but the loss of the nephew would actually be considered an injury to the entire clan uh and Tacitus also like aside from this even remarked that the Roman soldiers were taken aback by the relative respect for women that the Germans had and they took this as evidence of their barbarism and this is something that we see traces of actually even up to the dark ages in Europe with things like Viking women being able to get a divorce which of course certainly was not a right really afforded to women in medieval Europe later down the line so you know what changed then if women haven't been oppressed forever how did they go from from that position to the position of women in kind of early class societies which is very different well nothing in the world is static as we know and these human societies weren't static either even though they existed for hundreds of thousands of years in very similar forms they were also developing right and over the course of these millennia humans first developed more and more refined stone tools and these tools could be used to harvest well plants more effectively and this allowed us to domesticate crops like wheat and this is a very short summary but effectively all of these millennia of development provided the basis for what we now call the Neolithic revolution the development of agriculture humans settled down we began to live in stationary village communities we began to farm the land uh and as societies adopted agriculture the first time they could produce a consistent and regular surplus product this product could be owned it could be stored and traded with this regular trade people could become full-time craftsmen for example they could sell like the products that they made things like jewelry and and pottery and this could be sold in exchange for this surplus agricultural product objects of wealth heirlooms jewelry they became not just personal belongings but things that could be passed down from generation to generation but this obviously raises the question who has a claim to the surplus produced on that land and so for the first time we see the question of private property basically being put to human society uh because whoever owned that property whoever owned that surplus product would also come to dominate society uh so we'll get back to this in in a minute right because something else that's that's really important is also happening with the origins of agriculture which is that the the biological differentiation which existed between males and females which previously led to certain like tendencies in the division of labour but no institutional exclusion of either sex from positions of power actually under agriculture that was also developing into a much more extreme division of labour this is for a couple reasons uh for the first hunter-gatherer groupings right they tend to be mobile they can't rely on a consistent food supply and so the birth rate is relatively low in these groups and this means the burden of childcare on the mother is smaller women have more time to participate in the rest of society but with agriculture bigger families mean more hands at work on the land and the birth rate massively increased and as a result women are spending more time on childcare and in addition uh many domesticated crops actually require huge amounts of processing time things like wheat and barley right they have to be ground into flour and then baked into bread as these become a staple this work becomes a vital part of the economy and for the first time this resulted in the huge majority of what we would today call domestic labour falling on women in a way that it hadn't in the past and again like this isn't just uh theorizing we have proof of this we can see the evidence in the skeletons of women uh from who are living at the dawn of of these agricultural societies uh there's a settlement called Abu Hurayra which is one of the oldest sedentary farming villages in in the Near East uh and in female skeletons from that site they have arthritis in their toes because basically they're spending hours kneeling uh rocking backwards and forwards using their body weight to grind grains into flour and so this new division of labour you know actually like changes their bodies and when we can see proof of this um and now in primitive communist society of course maybe this wouldn't have resulted in a change in the position of women compared to men because what we would call domestic labour was equally respected to activities such as hunting as as I've already discussed both after all were necessary right to the survival of the community and that was you anything that really mattered but with the origins of private property the work that men were doing uh became connected to the production of a surplus things like farming things like herding cattle and so even if the men were using the tools and eating the food prepared by women they were able to claim the right to that surplus and basically claim power over women and so the male owners of property were becoming the new masters of society uh and an equal measure as families grew people are beginning to live more and more as as families working the land men are starting to own their own property rather than it being owned collectively by the the tribe or the family group and the connection with their gens uh what angles called the tribe uh became thinner and so men who already now were the owners of this new kind of property were also starting to wonder why they should even be passing back this property to their mother's family after their death rather than passing it on to their own children and of course this raises the question of inheritance which is the logical conclusion of this development of private property uh so we can see right with the origins of private property with the origins of male ownership over that property women also lose the right of lineage men want to pass down their property to their children and so for hundreds of thousands of years for 97 percent of the time anatomically modern humans and homo sapiens have existed parentage have been traced through the maternal line but now it had to be passed through the father so that they could pass down the wealth that they have produced and unlike naturalineal parentage of course this is in no way natural because a woman will obviously always know she is the mother of her own child but how can a father know that the child of his wife is his own only by the imposition of strict moral rules and a strict monogamous family in which women are no longer free to do as they pleased they're considered the property of their husbands and they have to be strictly regulated and watched uh and so women essentially become commodities themselves they're reduced from being their own people to just being vessels for inheritance and again Engels talks about this and he was you know one of the first people basing himself on the work of people like LH Morgan who was an anthropologist studying these kind of societies to really challenge the idea that the monogamous family was natural and Engels explains the natural fact monogamy was the first form of the family to be based not on natural but on economic conditions on the victory of private property over primitive natural communal property uh the sole exclusive aims of monogamous marriage were to make the man supreme in the family and to propagate as the future as to his wealth children indisputably his own and he goes on to explain that thus when monogamous marriage first makes its appearance in history it is not as the reconciliation of man and woman still less as the highest form of such a reconciliation monogamous marriage comes onto the scene as the subjugation of one sex by the other and it announces a struggle between the sexes unknown throughout the whole previous prehistoric period this is a pretty big indictment of monogamy right um but but there's a reason for it which is that you know it really degraded the the position of women uh and for women you know it was a real tragedy um and or speaking of tragedy Engels points to the Greeks as a very good example of this not only see ancient Athenian society pretty much typifies how the overthrow of mother right and the origins of the monogamous family degraded the position of women uh so the Greeks have previously held women in very high regards this was shown by their goddesses you know in Greek mythology we can still see the traces of mother right we can see that like for example the goddess here as child Hephaestus is born a god even though his father isn't a god when his youth fathers children with mortals they only become demigods are demigods and this is because like godhood is being passed down through the female line right uh but unlike Greek mythology which in many ways was a sort of holdover from a bygone age in Athenian law and Athenian society the situation is completely reversed and an example I think that's that's really illuminating actually comes from sort of early Athenian legal texts there's this text called on the murder of Eratosthenes which is by an orator called called Lysius and it's not clear obviously whether this is a speech from a genuine trial whether it's more of a kind of advert for for Lysius's services but in it Lysius is defending this this man called Euphilitos Euphilitos catches his wife in bed with another man and murders the other man in a fit of rage and he justifies his actions by explaining the the adultery Moichia is is the greatest of all wrongs in society and he explains that this is the case not just on an individual level but because it's a danger to the whole of society he says to Eratosthenes the guy that was that he caught sleeping with his wife your executioner isn't me it's the law of the city whose violation you thought less important than your pleasures you committed an offense against like this against my wife and against my children so you can see that adultery is presented as this very serious crime in fact more serious even than rape because it calls into question the whole security of the man's bloodline and thus his property and his inheritance and it calls into question his children so it's an offense against the whole bloodline and in this work on the murder of Eratosthenes it's explained the only solution to this the only mistake that Euphilitos makes is not keeping a tighter control on his wife since the very beginning so his fatal mistake isn't committing murder it's trusting his wife enough to allow her liberties and imprivacy and here we can see very clearly right the position of women in Athenian slave society have been completely you know debased and degraded compared to the earlier societies that are still organized based on a sort of tribal structure and on top of this right it's also worth pointing out monogamy in these societies was basically for women only it wasn't for men men were still free to do whatever they wanted well women were strictly regulated every second of their day was watched they were basically locked in houses and we can still see traitors of these attitudes today right in the way that women who have multiple partners still treated very different socially to men who do and with this degradation of women's place in society from being a free equal individual to suddenly becoming the property of the man also came the degradation of women's work Engels explains that household management lost its public character it no longer became a public service it became a private service and the wife became the head server until all this labor was still vital to the maintenance of society was suddenly considered far less important it didn't produce items that could be sold for a profit so by kind of understanding this the rise of patriarchy in this way we can see matrilineal pre-class societies weren't similarly similar in any way to the patriarchy of class societies it wouldn't be accurate to describe these like pre-class societies as matriarchies because they were based on a natural reality a mother being sure who her children were but like and so they didn't require the dominance or the domination of of women over men but by contrast patriarchy involved by nature the subjugation of women to men and it resulted from the dominance of economic factors over natural ones and so women become subordinate to men basically for the sole purpose of amassing wealth and at the same time their labor all of the work that they're doing loses its value in society importantly obviously we can also see this whole situation didn't just emerge out of nowhere men didn't wake up one day and decide that they were going to you know use their power to subjugate women suddenly instead they subjugated women for a material reason and that material reason still exists today it's property it's private property now I don't have a huge amount of time but I do want to quickly talk about the bourgeois family because we can see the family has changed multiple times throughout history from kind of like the patriarchal household of ancient society to the extended family of feudalism to the bourgeois nuclear family and this again proves that it's not a natural form that the family develops as is required by like the economic structures of society and as capitalism developed family relations also developed into this kind of nuclear family a lot of things haven't changed Engels explains that in capitalism marriage according to the bourgeois conception is a contract it's a legal transaction and I would say that that's still true today in many cases it's a legal transaction for the exact same purpose as marriage always has been for defending property for protecting the bloodline for protecting inheritance and in many cases for the woman continuing to be the property of the man and these attitudes persist even in bourgeois law you know in the UK marital rape wasn't made illegal till the 1980s there's still exception for marital rape in many countries which sums up this attitude of basically women being being property in this marriage and this attitude that has existed for thousands of years and under capitalism you know arguably there's this kind of veil of choice arising but it's still a veil of choice in fact going back to Engels he compares the marriage contract to the contract that the worker enters into with the capitalist on the labour market because in theory he says right in theory the worker is completely free to refuse the contract with the capitalist and find another employer or find no employer at all but in actual fact what would happen if he did that if he refused to work he and his family would starve and no matter what capitalist he went to he would still be offered the same exploitation and therefore even though there's this kind of veil of choice over the whole thing the worker still comes out of the transaction poorer and this is unfortunately also true for women who even today when they're marrying out of choice or marrying out of love they still undoubtedly come out of the situation during the vast majority of domestic work come out of the situation with worse wages and even though women legally have the right to divorce many are remaining trapped economically in abusive marriages because they cannot afford to leave so we can see that this veil of choice actually conceals what is still in many cases an incredibly exploitative situation but even with the emergence of the bourgeois family we also have the emergence of the proletariat of course and that actually challenges those family relations just as you know capitalism in itself it contains the seeds of its own destruction also you know the proletariat almost contains the seeds of the destruction of the bourgeois family as well because capitalism is forcing women has forced women into work alongside the domestic labor that they already carry out this undermines the bourgeois family this was true even when Marx and Engels were writing in fact it was very obvious then the time when Engels and Marx were writing women's labor was cheaper than men's and so at various points the men were actually being forced out of work while women were the sole breadwinner and of course for the first time this was giving them power to basically challenge their husbands and of course this was something that absolutely scandalized bourgeois commentators who were used to bourgeois women who didn't work and who were completely relegated to the home and many people kind of felt outraged they felt that polite society was basically being turned upside down with this kind of turning upside down of the family however Engels writes in the condition of the working class in England and he points out he says we must admit that so total reversal of the positions of the sexes can have come to pass only because the sexes have been placed in the false position from the beginning and if the reign of the wife over the husband is inhuman the pristine rule of the husband over the wife must have been inhuman too and if the family of our present society is being thus dissolved this dissolution merely shows that at bottom the binding tie of this family was not family affection but private interest lurking under the cloak of a pretended community of possessions and of a fact he basically exposes that the fact that women are being called into work and thus that position in the family is changing exposes that this position has always been a false one for as long as it has existed now the rise of the working class obviously is playing and has played a very progressive role in the dissolution of the bourgeois family but it hasn't completed the process rather women under capitalism are being left with basically two jobs a dual burden of domestic work to do on top of being brought into the workforce we can see this now today has been exposed even more clearly by Covid right working moms who are already taking on the bulk of the childcare and now taking on education responsibilities too so we can see the bourgeois family structure has never fit the proletariat and that there are changes in the composition of the nuclear family that reflect this but on its own the existence of the proletariat is not sufficient to overthrow the bourgeois family not sufficient to overthrow the nuclear family and not sufficient to overthrow women's oppression after all you know we've had decades of of hard fought battles by women workers who've generally been fighting alongside men and after all that women now have full legal equality as we discussed earlier that's equal payloads right that's maternity leave that's the right to divorce but what does legal equality actually mean it means women at shouldering three four or five more hours of work at home every day on top of an eight nine or ten hour working day it means a couple of women are breaking the glass ceiling well most of them are underpaid even compared to their male colleagues who are also being underpaid and it means 14 women murdered in two weeks in the UK at the start of lockdown so we have genuine uh so we have legal equality but we don't have genuine equality why is this uh well you know Trotsky talks about this in in his writings on the changing role of women in the family after the Russian revolution and he says a deep going plow is needed to turn up heavy clods of earth what does this mean it means the oppression of women is deep seated in society it's based in prejudices based on material conditions dating back millennia the nothing short of the total transformation of society can actually change this despite centuries of change the conditions that first gave rise to women's oppression still exist the existence of private property the existence of class society so of course we can and we should fight for whatever improvements can be made under capitalism but if we aim low you know if we aim that low we limit ourselves to that all we will achieve are temporary or partial measures and those measures will be scaled back when necessary again as we're seeing with COVID so what's the way forward then well I'd argue and I hope you'll agree with me that it's the struggle for a socialist society to completely change all of this um so uh just to sum up uh let's see if I can sum up everything that's been said we can see that far from being a natural development the overturn of mother right and the relegation of women from being a free individual to being a possession basically is one of history's greatest upheavals it's a violation of all of the morality all of the norms of the old primitive communist society but we can also see there was a reason for this those early primitive societies they had ceased to serve their purpose there wasn't any room for development and only with the origins of agriculture only with the growth of the earliest class societies could humanity actually move forward could we further develop the productive forces and with it the whole potential of human civilization uh and that development it required the overthrow of all the old forms of millennia past and this included the tribe included the old forms of the family and its replacement with with new ones and as the saying goes you know there's no use crying over spilt milk it's true the origins of class society was to step forward historically we're in reality a tragedy for for hundreds of thousands of people uh millions of people not in the least women uh but that has also brought us to where we are today and what we are today is that capitalism and in fact all of class society is now just as outdated as paleolithic and mesolithic society was back then and unlike previous classes unlike previous revolutions the working class doesn't have any interest in continuing with private property doesn't have any interest in continuing class society because unlike the past unlike previous class societies like feudalism we now produce everything socially right thousands of workers are working as one to make the economy run even if all the wealth produced from that is then being privately appropriated by a few individuals and so we can see now the very existence of private property is now a contradiction in fact it's private property itself which was you know the motor force of development 10 000 years ago there's now become a fatter to further development and you know if you look around you know everywhere you can see that we can see that capitalism is grinding to a halt and so it's in the interest of the working class actually do away with private property fight with for a socialist society where property is once more collectively owned so capitalism today is now just as defunct as stone axes were all those thousands of years ago and for you know the second time the whole of human society we actually have the chance to build a world where everyone's equal where no one section of society dominates the other and that won't be based on the scarcity of resources that will be based on all the abundance that millennia of development has produced and in other words that won't be primitive communism it will just be socialism and communism and with that the family can and will change too because with the shift under socialism from private property to collective property we can abolish this kind of possession of women we can abolish the idea that the women is property and the family also no longer has to be a private unit with the women as as angles described her as the chief and now the only servant in the household domestic labor can be the collective responsibility of all of society the position of women can be improved not as a temporary or a partial step forward but as a real improvement and women's oppression you know has existed for millennia it's very ancient it's very deep rooted and so are all of these prejudices but despite that it does have an origin and it hasn't existed forever and that means that it can be done away with it can be got rid of and if people take anything away from this i'd say take take that we don't limit ourselves we don't need some of ourselves to fighting for short-term improvements can also fight we can also fight to do away with private property with class society and on that basis we can build a world free from the exploitation of women but also free from exploitation and oppression of any kind listening to this episode of women's liberation the marxist position if you would like to read more on this question i highly recommend visiting our education hub socials.net slash education where we have a range of resources on everything from how to fight oppression to philosophy and more the website of our international the international marxist tendency has also a wealth of material that we highly recommend and if you like the ideas that we have spoken about then you should join us women are involved in social struggles and the question of women's oppression is on the agenda to a degree that we have not seen in decades sexism and the oppression of women is integral part of capitalism and they can only be removed once we do away with the material conditions that allow this to exist this is why we fight for socialism and this is why you should join us in our struggle so stay tuned for next week where we'll discuss the historic examples of women's struggle and the main focus on the russian revolution and what the bolshevik attitude was to the to the woman's question i've been your host lupin abadi and thanks for listening to the marxist voice brought to you by socials appeal


Temperatures are rising this week in eastern Kentucky with some daily highs reaching the mid-90s range. The Pike County Health Department has some helpful information on how to stay hydrated, watch for signs of heat stroke, and how to avoid the heat altogether. Public Health Director Tammy Riley gives us more details. We know it's going to be a hot week, so from a public health perspective what we recommend is, you know, this would not be a good week to go out in the middle of the day and have a vigorous rent. So try to do any necessary activities that must occur outdoors earlier in the morning when the temperatures are cooler. Also wear lighter clothing, lighter color clothing, lighter fabrics to accommodate the high temperatures. We would advise individuals to stay hydrated, drink lots of fluids and water, and then also, you know, as we would always recommend when exposed to direct sunlight, you know, wear and you'd like some walk to protect your skin. So there are some things you can do, avoid those outdoor activities and do our sunblock, stay hydrated, and think about your attire where appropriate clothing helps. Are you ready for a new school year? What better way to start a new school year off-right than with a new device on the network that keeps our students and teachers connected, Appalachian Wireless. Whether you need a new smartphone, wearable, or an iPad, we have your back-to-school solution. On AppalachianWireless.com, we're going to one of our 26 retail locations for our back-to-school deals that will help you show up and show out this school year. We are you. We are Appalachian Wireless. Due to the heat, some local establishments could function as cooling stations later in the week. Local officials will continue to monitor the weather to decide if said cooling stations are necessary at this time. Cooling stations are being considered that only in the event if temperatures get higher than expected, or where they're currently predicted, and the Department of Emergency Management typically manages those cooling stations to the city of Pikeville, typically the fire department through either fiscal court or city hall for the county and the city. But officials that need to manage those cooling stations are monitoring the weather. Reporting for Mountain Top News, I'm Nick Colum.


Members of the public be advised, a dangerous anomaly has breached containment and is in your area. This anomaly, known as SCP-2006, is an entity capable of changing its shape and physical appearance to better complete its objective. The objective of this entity is to spread as much fear as possible among as many humans as possible. Currently, SCP-2006 has a poor understanding of what causes fear in humans. As such you must do your best to pretend to be scared of it. This will help to confuse it, and stop it from developing the knowledge it needs to truly terrorize humans on a large scale. The entity will soon be re-contained by authorities. Until then stay safe, and stay scared. Secure. Contain. Protect.


What's up everyone? It's your girl, Kenty here from Layton Sports Cards and I am ripping a couple personal boxes here for Scott A. We've got a 2021 Leaf Metal Draft Baseball Hobby as well as a 2021 Leaf Flash Baseball Hobby. All right, best of luck here, Scott. Let's start with the draft for six autos. All right, we've got Black Adrian Del Castillo. Auto up first, Adrian Del Castillo. That is six out of seven. State Pride Autograph of Andrew Painter. Like these state prides. Nice one there. Got Cracked Ice of Angel Martinez. Angel Martinez. Not numbered on that one. Another Cracked Ice here of Joshua Baez. Cracked Ice. Not numbered. Blue Border. Andrew Abbott. Andrew Abbott on the blue border. That is eight out of 35. And redemption here for you, Scott. We've got how about 2021 Leaf Metal Draft Baseball, Jason Dominguez. Nice hit, Scott. Again, Leaf does not disclose what level or parallel it is until you go to redeem it. So best of luck on that one. Nice Dominguez. Heck yeah. Solid box here for sure. 2021 Flash Baseball now. Good luck. All right, we've got a Wilman Diaz up first. Wilman Diaz. Not numbered on that one. Up next, Jose Ramos. Nice Ramos auto on the rookie. Not numbered. Up next, we've got a Jose Buto auto. Jose Buto. Not numbered. Photography auto inserts Gabriel Moreno. Gabriel Moreno on the photography. That is 72 out of 99.  Oh, I know you've got a redemption actor. Sorry. Flash forward of Hepburn Perez. Hepburn Perez, 47 out of 50. And another redemption here, Scott. We've got a Jack Leiter autograph card. Nice hit. Again, it is not told what level or parallel this will be until you go to redeem it. So best of luck on that one. Scott, two nice boxes of baseball there for you. Congrats again. We'll get these right out to you.


OK, so I think we'll get started. This session is about the workflow initiative. We've got a URL there for fiddy.o. That's where the plan is. This is going to be a very much an evolving plan. We've tried to put together as much as we can how we want things to work for the next two, three years. And if anyone has any suggestions, any comments, we're going to be changing that plan as we go through. We've already started making changes to it this week, so pull that up and follow along. So I'm Tim Millwood. I've been working on this kind of stuff in Contrib for the last nine months to a year. And I'll be dedicating the next two years, almost full-time, working on this core initiative. Then we've also got Dick. I'm Dickson on d.do. I'm a long-time core and Contrib developer. I'm the author of the Deploy module for Drupal 7, which is kind of related to the topic. So I've been working in this space for many, many years. I'm also the creator and co-maintainer together with Tim and Andre and Tim with these same modules in Drupal 8. And I'm also the initiative coordinator for the new workflow initiative that we'll be talking about here. So really excited. Good to see so many of you here. I'll also give a shout out to Andre. He's sat down the front here. He's working on this core initiative full-time with us as well and been working on the Contrib modules for the last two, three years. So we're going to start off talking about the Contrib modules. And what we've been doing there, it's all based on Deploy. Dick was saying Deploy's been going from Drupal 7 back to Drupal 6, Drupal 5. So we've been working on this stuff for years, for years and years, and trying to sort of perfect the workflow. And I think with Drupal 8 we've got a very good workflow. It's all based on CouchDB. So we're not actually using CouchDB, but we're using the same API protocol. This allows us to replicate content in a very robust way, a way that's been working very well with CouchDB for a number of years. So we start with multiversion. This is kind of the base module for our Contrib stuff. This makes everything revisionable. So every content entity in core and Contrib multiversion changes to be revisionable. It also adds a number of underlying storage changes, things like deleting entities. It doesn't delete them anymore. It just keeps them and archives them. We can then purge them later on. We've got a number of indexes that we store information. So this is a very sort of underlying storage stuff. We've then got the replication module. This, again, is very much sort of underlying stuff for replication. It allows us to see sort of what's changed between different workspaces. I'll come to workspaces later, but different workspaces, different sites. And we can see sort of what content changes have been made, and this allows us to replicate content. So in the workspace module, workspaces you can think of a bit like get branches, but for your content. So you have a live branch with all your live content, and you'd have a stage branch for all your stage content. You can create as many workspaces as you need, so when you're creating a new sort of content feature, whether this includes nodes, blocks, menu links, taxonomy terms, whatever, they all go into a workspace. And then you can deploy them to a different workspace on the same site, or a different workspace on a different site. And because we've based a lot of this on CouchDB, you can also replicate over to CouchDB. You can replicate to CouchDB that runs locally. So there's a lot of sort of power from using these workspaces. So talking about CouchDB, Relax Web Services is the module that we've used to implement the CouchDB API. It works off the core REST API and adds the endpoints needed to work with CouchDB. As I said earlier, this gives us a very robust API for replicating content between sites and between CouchDB and other compatible services, but it doesn't use CouchDB. We've completely sort of written it. And as Tim mentioned, just want to emphasise it. You don't necessarily need this module if you just do staging and previewing on a single site. This module comes into play when you have separate sites for your stage and production, or just want to replicate between different sites over HTTP. Just a note. So then finally, we've got Deploy. Deploy is kind of the overarching thing for all of this. As I said, it's a very old module, so we sort of worked up from the previous modules. And it gives a UI for deployment. And whether you're using relaxed module for cross-site replication or just the workspace module for single site replication, Deploy will give you a UI to deploy between things. And after the session, if we've got time, we can go through a couple of demos just to sort of see visually how the UI works and how Deploy does this. And just one note. As we go through this plan issue by issue, this is a core conversation. So please interrupt at any point if you have any questions. We don't necessarily need to take all the questions at the end. We want to keep the conversation going. It's going to be lots of details, issues, and technical details. So please step in, raise your hand, step up to the mic, and we'll keep the conversation going. OK, so let's get on to the actual initiative. As I said earlier, we've got the plan that you can take a look at and try and follow through, and do step up if you've got any questions. Each of these slides will sort of loosely relate to an issue or sort of a step within the plan. The first one here is enabling revisions by default. This is an issue that I opened last year in Drupalcon LA, and we're basically looking for that checkbox, create a new revision on nodes and blocks to always be checked. And when you create a new content type, it should always be checked. So we get into this idea that revisions are always created, and by default, we should have revisions. So that issue there is currently in needs review status. So if anyone wants to start taking a look at the sprints tomorrow or over the weekend, please review that. Maybe one day. Repeat the question. Yeah, so the question was, are we going to remove the checkbox from the UI? In this patch, it doesn't remove the checkbox. But yeah, maybe one day we can. With the contrib work, so with multi-version, we do enforce revisions. So we keep the checkbox, but you can't uncheck it. So in contrib, if you are using multi-version, everything's revisionable, and you have no choice, it's revisionable. Because we believe that's the way it should work. But in the implementation details for the rest of the initiative, we can discuss that. And a little bit more reasoning behind that. So if you do the same thing with code, if you have a workflow, if you move around, stage your code, it's not like you can turn off revisions on Git. It needs to be there for fundamental reasons to be able to move things around, to be able to merge things and solve conflicts. We sort of deal exactly in the same problem space here, really, with content. Moving content around, merging between stage and production, and needs solve conflicts. So that's why revisions is this core concept that needs to be there. Bya. So the next issue is done. This was committed to core a couple of weeks ago. So this is having base field definitions that inherit from their parents. All content entities extend the content entity base class. And in there, you have base field definitions for things like the ID field, the UUID, the revision ID, the bundle. All these kind of fields are in content entity base. But so many of the core entities weren't inheriting those. They were resetting those base field definitions. So this core patch that's now in, it will go into 8.2. We inherit. And this allows us, potentially in the future, to just kind of turn on revisions for any entity type. And it will get that revision ID field from the parent. The next one that's also been done is the node interface is now implementing the revision log interface. So in 8.1, we added a revision log interface. So you may know that on a node, you can add a revision log message on block content. You can add a revision log message. And this interface adds a number of methods for that revision log. But node interface wasn't using that interface. So we've updated that, deprecated a number of old methods that weren't in the interface and added the new methods that are in the interface. So the next one is for block content. We need to get that interface also working with block content. The issue is that we don't yet have a revision user and a revision created field on block content like we do on nodes. So this patch that's in needs review, again, if you're doing sprints this weekend, please review, it adds those two fields, the revision user and the revision created. And then it changes the block content interface to implement the revision log interface, doing the same as nodes just to keep them all consistent and all working the same. So once we've got all that in, we're going to want a way to migrate entities between entity type schemers. So this is a very complex problem and it's probably the most complex issue that we've got for our phase one. Phase one, we're planning to get it into 8.2, which is out in October. And we'd like to make everything revisionable. So users, menu link content, taxonomy terms, every content entity in core we want to make revisionable. But that means changing the schema. It means adding new tables. It means changing tables. So we need a way to migrate entities from the old schema, the non-revisionable schema to the new schema. We do this already in multiversion, in contrib. The way we do it there is with migrate module. So migrate module is in core. It's still experimental, but we use it with multiversion to basically delete all of your content, change the schema and put all your content back again. So that's probably not the best way of doing it. And the reason here is that it's built into the entity API, a assumption saying that we can change the schema for you if you have content already. Because that's the very core part of the migration problem. This is why we sort of stash away content temporarily, remove storage, create the new storage and then put the content back. But as Tim said, the approach will probably be different for when we get this into core. Yeah, so we're currently discussing ideas like update hooks that will go in and create the tables that aren't there and copy the data that needs to be copied and all these kind of things. But if anyone's got any really good ideas, then please head into the issue and share them. We'll be really interested in hearing them. And one final note on this one. It's going to be tricky depending on my great module since it's experimental, as Tim said. For a crucial part in core, we can't depend on an experimental module, so we probably need to find ways around that. So once we've got that worked out, we can make everything revisionable. I've already started working on this patch, so you've got the issue there. The patch isn't really blocked by the migrate stuff, but it can't get committed until that migrate stuff is done. So at the start of this week, I had about 350 failing tests. I'm now down to about 123, I think. So we're making fairly good progress on making everything revisionable, but as I said earlier, we're looking to make all core content entities revisionable, which I think is sort of a fundamental thing. And every time I tell people that we are looking to do this, they look at me kind of puzzled of why aren't they revisionable anyway, and why are block content revisionable, and nodes revisionable, everything else isn't. So we need to try and get this in. So that's the last part of our phase one. And as I said, phase one, we're going to try and get into a point two in October. So going on to phase two, revisions don't have UUIDs. We added UUIDs for entities in Jublates, but not for revisions. Another thing we're looking at is revision hashes. So in multi-version, in contrib, we add revision hashes. And the reason we do this is because if you add some content on your stage site and you deploy it to live, and then you make changes on live and make changes on stage, if they're the same change, we want them to create the same revision hash. So if you replicate, we know that we've already got that revision and they've got the same hash. They're the same change. We don't want to introduce a conflict when the change is the same. So a UUID won't give us that functionality, but a hash will. So do we add a UUID or a hash or both? What's the best way of doing that? So there's an issue already open here where there is a patch that's adding a UUID, but maybe we need to add another issue that adds the hash or update that patch to also add the hash because that's going to be a very important feature when we start looking at replicating content between workspaces. Yeah, so the question is, are we hashing the entity, and we are hashing the entity. It's not the final rendered entity, and we are excluding a number of fields as well, things like timestamp, because obviously if you make a change on different sites then they're going to have a different timestamp. And what's practically happening is that we're running you through the serializer. It's serialized to a JSON string, and that's what we hash. So the next issue on our phase two is parent revisions. We haven't yet got an issue open for this, and we want to know where a revision comes from. So we want to be able to log somewhere what a revision's parent is. And this makes it really useful for resolving conflicts. So if there is two revisions with the same parent, we know that they both came from the same place, but therefore they are conflicting. And we need to resolve those conflicts. We then resolve a conflict and a revision has two parents. There are two conflicting revisions and we merge or we resolve that conflict in some way and it produces a child stemming from those two parents. Very much like it, really. Every commit has a parent, and a merged commit, i.e. the fix of the conflict, has two parents. So you know what revisions you've fixed to make one. So then once we've got that in, we're going to look at a deleted flag. Again, this is something we've got a multi-version in Contrib where we flag revisions as being deleted. So when you delete any content entities, it creates a new revision and that revision is flagged as deleted. This allows us to do so many things. We can now add a trash bin into Core. There's already the trash module that we've got that works with multi-version that does all this so you can restore content after it's been deleted. This also allows us to do replication of deleted content. So if you delete something on stage and you replicate up to live, then it also deletes on live. If we properly deleted it, if we purged the content, then we'd replicate up to live and live would not really have any idea sort of what the content is, so it wouldn't get deleted. And more importantly, if we did a pull before a push like you wouldn't get, it would actually pull down the content that you deleted from live. So that content would sort of reappear. So we really need to flag things as deleted. Another key aspect here is also you won't be able to solve a conflict involving a delete if there's nothing to compare with. So it's fundamental that once we delete, it actually is not removed from the database. We can present these two new changes if they are conflicting. One might have done a change and one wants to delete the content and then we can resolve that conflict. So it's a very important aspect. Yeah, so now with this deleted flag, you can't delete things because things are just flagged as deleted, they're not actually deleted. So what we need to do is purge revisions. So currently with the trash module, you can purge things and this just runs sort of the old proper sort of core delete and it actually gets rid of and purges revisions. As we said, there's a number of reasons why you shouldn't purge things, but if there are sort of legal reasons of getting rid of content, then we need to have a way in core to sort of actually get rid of content. And so as you can see on the slides, this is phase three and this is something that we're targeting or aiming to get into 8.3. Drupal 8.3, which is sometime next year. This time next year, yeah. So once we've got these in, we can look at adding the trash module into core so you'll be able to, from the UI, restore and purge any content. So this is something that WordPress has had for years. It's something that sort of your desktop OS has had since 1984. So there's a number of reasons why we should get this into core and it's well over to you. And this would be the first point in the initiative where we actually add some significant user interface changes as well or additions, I should say. Introducing this UI that Tim just talked about. It's notated as phase four and as you can see in the plan, it's still targeting 8.3. We split up the phases so that they don't depend on each other. And that's just a target. It's still up for discussion and so on. And yeah. So the next phase, phase five, we're going to start looking at moderation. So almost every site needs some kind of moderation and we've been working a lot with the Workbench Moderation team. So you can kind of see this as an effort to get Workbench Moderation into core. But again, this is still up for discussion. And the way we've been working in contrib with Workbench Moderation is you can moderate entities and you can moderate workspaces. So you can moderate an individual node, for example. Or you can moderate a whole workspace which is nodes, blocks, menu links, everything together and deploy that as sort of published. So this phase, we're just looking at the underlying API that's going to make all of that possible. So a lot of this at this stage will still live in contrib but we'll have this core API for doing moderation. And this is a step that a lot of people seem to get really excited about and really keen to get into core. And we'll talk about more APIs here down the line but I think this is gonna, for many people, for many site owners, this itself, once we add a simple UI on top of this, it's gonna cover a big, big use case that many have. Simply just moderating individual entities, as simple as that. Everyone won't need a full workspace and moderate a whole workspace but the phases and the APIs are set up in a way, as Tim said, that we can do both. So it'll be a very flexible and powerful system where we can moderate both individual entities as well as whole workspaces. So once we've got that, I'm gonna start looking at trying to get workspaces into core. So this is an initial API for workspaces and I mentioned earlier we've got the workspace module. That doesn't actually add workspaces. That's added further down the line in multi-version. So this is kind of what we're looking at doing here. We're gonna add multi-versions workspace API into core at this phase which adds the workspace as a content entity and then all content belongs to a workspace. From the UI, that will be completely invisible. You will have one default sort of live workspace. All your content will belong to there and that's sort of how it will initially work. That's how it works with multi-version at the moment until you add the workspace module that gives you that UI to create and switch workspaces. So the behavior of core would not change at this point. This is just API additions and as Tim said, it's just one default workspace. No behavior changes. Right. So we've got a number of indexes, also a multi-version module and this allows us to do so much stuff. But a UI, a UID index is probably the first place that we're gonna look at for the core work and we've already started an issue on that and just started looking at how this is gonna work. In multi-version we use a key value store and we store all UUIDs and then against that we store the entity type, the entity ID, the revision ID and sort of a load of other information about that UUID. So that given a UUID, you know what it is because at the moment we have unique identifiers, UUIDs for content but given that unique identifier you have no idea what it identifies. You don't know if it's a node or a block or a menu link. You know nothing about it. So this index will give us a place to look up and find out what these things are and this becomes important when we start to look at replicating content because we're gonna have to use UUIDs for everything because local IDs are gonna be different on different workspaces, on different sites. We have to use UUIDs for everything. So once we've got an index for entity UUIDs we can add an index for revision UUIDs or revision hashes or both, whatever we'd go down the road of looking at for them and they're gonna do exactly the same as the entity UUID indexes but just for revision UUIDs. So given a revision UUID you'll know exactly what entity type it is, what entity it is and what revision that points to. So we've then got another index. This is a sequence index and this is a real big index of everything that's going on in your site. Again it's something we do in multi-version and it's a key value store which is ordered by the sequence ID and we know everything that you do on the site. Whether you add, update, delete content, we know what entity type it is, we know what entity idea it is, we know what revision idea it is and they're all ordered so that when we do the replication we can play it back just like when you do a sort of a rebase with git you play back every commit. You could almost compare it to a MySQL binary log or a git commit log almost. A way of replaying changes. It also allows us to compare sites and we can look at what sequence ID one site is compared to another site so when we are replicating you know what needs to be replicated if anything at all. So once we've got that in we can look at replication services. We've got two services, the changes and revision diff services that are part of the replication module and these allow us to know first of all with the changes service we know what has changed on the site and this uses the sequence ID as well so you can know what's changed since a certain sequence ID and then we've got the revisions diff service so once you have a number of changes you can look at those changes compared to another workspace or another site and know what revisions are different on each site so when we come to do the replication we only replicate the revisions that are different between the two sites. So the question is does the revision diff use the UUID in the hash? Yes at the moment we use the hash so we have the entity UUID and then under that a number of revision hashes so we know the entity and the revisions that relate to that entity. So the question is about conflicts do we get a three-way merge for conflicts? We'll come to that in the future. Later on in the plan we do look at conflicts. We are flagging conflicts and as I said with the parent revisions we know that there are conflicts so we can tell if two revisions have the same parent that they are conflicting but there's currently no way to merge or resolve those conflicts even in Contrib there's no way to do that yet. At the moment we just pick one or the two conflicting. We have a Google Summer of Code project so we've got a student who's going to be working on a conflict tool for this and hopefully it's something that we can put out to the wider PHP community and it's not sort of Drupal specific for resolving conflicts. The APIs are structured in a way that a full three-way merge is possible so we can implement the most complicated merge algorithm if we would like. A three-way merge is basically where you have your local change, your remote change and then the common ancestor of the two. You have three revisions that you can compare and a three-way merge is what Git, for instance, is using to perform its conflict solution. Once we've got these replication services we can start looking at replication and put in a replication API so there's no UI currently for this step. This is just an API so the UI will still live in Contrib like it does now. The way we have it currently working in Contrib is using tag services. So the workspace module has a replicator that replicates between local workspaces and the relaxed module has a different replicator so for the catchDB API and replicates to different sites it can also replicate to workspaces on one site but just over a sort of HTTP loop. This is then extendable to any Contrib module. You can build your own replicator and replicate however you like and using those replication services you know sort of what revisions have changed and you can do the replication however you like and just tag it as a tag service and loop around as long as it applies it will run. Just to be clear within the scope of this initiative it's only going to be targeting replication for local workspaces. Again the API we're using tag services so Contrib can swap it in but for the initiative we're targeting the 80% use case which is going to be single site replication between local workspaces. We've got a way to replicate content between workspaces and we can start looking at conflicts. As I said currently in Contrib we just pick one of the conflicting revisions but we'd be looking at adding the full conflict management API into core and there's still so many implementation details to work out on this but I'd like to see it as a pluggable system where you could just sort of pick revision A or revision B or you could have a full three way merge a big sort of four pane screen to sort of choose your revisions your conflicting changes so hopefully we can make this a very extendable API. So now that we've got all these APIs in we can do replication and we can set up new workspaces we'd want to put an experimental API in a UI an experimental UI to create workspaces to switch workspaces to replicate up until this point it's going to still live in Contrib so all of this that we're talking about today is possible now in Contrib it's always going to be possible we're going to try and sort of allocate time throughout our plan to update all of the Contrib modules so they work with all the core changes but at this point we'll start adding an experimental UI in and it's a key part of the plan here and the reason why we're able to lay it out like this is that this is a solution that's been developed over the past two, two and a half years and is being actively used in Contrib and working in Contrib as it's a solution that's been maturing for quite some time already all of these phases in which we can lay them out in fairly good detail so this is the end of phase 7 where we put this experimental UI in and the next phase, phase 8 we'll be looking at updating this UI and making it a lot better we've already started working with some of the UX team we've got a UX guy also on our initiative team Joseph so we're going to be working very closely with him to make sure that the UX is really good and works really easily we've even been saying with the Contrib stuff that it's starting to look a lot easier than it actually is because the UI is quite simple but it's still not sort of know any where we want it to be from a UX point of view so phase 8 is going to be full of UX work first of all the conflict management UI as I mentioned we want this to be pluggable so that there can be different ways of resolving conflicts different UIs maybe different permissions so different users view different UIs for resolving conflicts and then we want a better workspace UI we're looking at things for example a drop down or a slide in bar so you can easily switch between your workspaces and create workspaces and if you've got hundreds of workspaces search them even moderation states on workspaces so you can see a different colour or a different state change on the workspace depending on the moderation states so there's a lot of ideas for that UI and we're welcoming a lot of other ideas so if you do have any suggestions please put them forward we'd be looking at a revision moderation module so as I mentioned earlier on we're looking at adding a moderation API integral so this moderation module would use that API and provide the UI for all of this moderation and a lot of discussions and conversations that we've already had throughout this Drupalcon is that we're probably going to put the UI for the moderation earlier on in the phases because this is again sort of the 80% use case just moderating a single entity is a very common use case so we're looking perhaps to move this to earlier phases because it doesn't depend on... Yay! because it doesn't depend on everything that we've mentioned before so it's possible to move this earlier Phase 8 currently that's I think Drupal 8.5 4 which is still some time away right can we get that earlier I think that will satisfy a lot of people so if we do move this well when we do move this earlier this will just be the moderation of single entities the moderation of workspaces also it's going to have to wait until we have workspaces so this will probably still be later on and this will allow you to moderate a collection of entities as one we'd also be looking at adding a cross-site content staging this is not in our main plan we've put this as phase X a nice to have phase this is currently working in Contrib as we said it will always live in Contrib but if we do have time at the end if we have a lot of sort of consensus that this might be something nice to get in then we can look at this cross-site content staging so this is what we've been talking about using the CouchDB API there's also a lot of discussion about REST APIs in core and sort of how they're going to look evolve so this sort of might be conflicting with those it might work well with those there's still lots of discussion to go on this so that's why it's in phase X another feature that's in our nice to have is autosave this is something that a lot of people have wanted for a long time and there's been so many issues and so many patches open for this already it's such a complex problem to solve one thing that we've sort of been thinking about is whether it could use the REST API and that things autosave to your local storage on your machine and then the content is replicated from your local machine up onto the site at the end but there's so many ideas, so many discussions already and the idea there with autosaving to your local storage is that if you would be working way on your site on your laptop and you would lose an internet connection it would still keep autosaving and then once you get your internet connection back we can replicate that from local storage back to the server using the tools that we already touched on this REST API and something called PouchDB still a lot of the discussions and ideas happening here and it's sort of in the nice to have so it's not a scheduled phase at the moment in the initiative but we're happy to hear everyone's feedback on that Great, so that comes to the end of all of our plan and we're sort of welcome any questions any ideas or any discussion Yeah, go ahead Please step up to the mic and if more of you have questions, line up this is a core conversation so we'd love to have the conversation going Just a quick question about how this, if at all would how you're considering the theming system in all this in terms of moving blocks around and new regions is that something at all that you've considered in terms of tracking those at the revision level? It's not in scope for this yet as Gries mentioned on Tuesday there are other initiatives that are being talked about that might include something like that and one thing to stress with this is we're looking at content entities only so block content is a content entity but the block itself is a config entity so that's something that you'd export out to a YAML file and add into your Git workflow so there are a lot of workflow changes on this because you've got to make sure that all of your config is on the live site before your content is so yeah, there's going to be a lot of changes And just a further clarification there we're not looking at all at making it possible to have different config for different workspaces on a single site, config will remain the same across all workspaces it's only content that we sort of compartment there you go, thank you so no config here so you can't place a block in a workspace that wouldn't exist in another a block position I have two questions so one question the big problem that I've run into with revisions in the past is the way it can bloke the database and obviously if we make everything revisions I mean we've had situations where people have a thousand revisions of a single node have you thought about that? what's the solution for that? so we've started thinking about purging revisions it's nothing we've implemented even in Contribus but maybe something like every third revision gets purged or after a certain time purged all revisions maybe a UI that you can choose these kind of parameters yes, definitely something we need to think about because with both revisions and the indexes that we've talked about we're going to be adding a lot of new data so yeah, we need to really think about that and that's what we've done with update hooks in the past has been anything older than such and such a date and I was discussing with Ken Rickard yesterday and he suggested that if this turns out to be like a performance problem because it is going to be important for conflict resolution and replication of let's say older stale workspaces to have revision data so perhaps the solution could also be to in the entity API introduce like a stash or archive storage so that we move old stuff over to the secondary storage where we still store it but the main queries they like day-to-day queries if you may on the entity API would run on a sort of lighter storage and then you could join on that archive storage if you need the history because then you'd come around the performance problem you wouldn't come around the storage problem but today's storage is cheap and that's not necessarily a problem It's still an issue for some people Yeah it certainly is but it could be sort of a solution and then so my unrelated question is have you talked about scheduling because that's the other editorial thing that comes up over and over is scheduling things right Yes there has been talk about scheduling currently it's not in scope for the initiative but if people want it let's build it we have Ted Ted has been working with us in Contrib and he has built modules around scheduling so there is work ongoing in the community to sort of have scheduling work with all of these bits and pieces because it's certainly something people are asking for and if it's something we think it's a big use case that's added to the initiative if there's consensus and agreement we're all here to plan together put forward more feedback like that and we'll certainly look at it for sure Next question Thanks for the work and thanks for the presentation One of the challenges that we've had in the past with workflow may be a simple answer from you guys and it may be just kind of the ecosystem will continue to evolve but workflow has a lot of assumptions about how people actually work and I wonder if you could speak just briefly to how much control over things like whether workflow assumes people who aren't named in the workflow are excluded from access and just kind of some of those workflow assumptions that especially are in workbench and workflow So we've tried to make this as flexible as possible and when working on the contribs side it's extremely flexible but then we come to implement a UI for this and if we make something so flexible in the UI then it becomes so confusing and complicated to use so we've tried to come up with sort of sensible defaults for the UI but left the the API as flexible as we possibly can so maybe we look at adding different contrib modules that provide different UIs as you saw from earlier on in the presentation we've got quite a lot of contrib modules that make up this and a number of those are optional just because there's different workflows and you need different modules for different things sort of about a year ago we probably had maybe two or three modules that made this up and now we're up to like five or six so that's just to add this flexibility so it's definitely something that we are keeping in mind Just a nitpicky question can I opt out of revisions and new UIDs still for my content entities after these core changes I certainly think that should be an option I can see that there are use cases what we then have to make clear to developers and end users of the API is that you won't be able to move this particular content to other workspaces it'd be something that stays there we'll change it already way in with the inheriting those fields or is there a way to opt out of that so we haven't started making any assumptions around that yet so we certainly should have something and I think something it would be in the annotation of the entity type it would say opt out from replication or something or opt out from revisions it seems a little problematic in terms of backward compatibility since I just wrote a module it doesn't want those so inheriting the base fields at the moment the content entity base class uses a lot of the entity keys so if there's a uuid entity key set then it gets the uuid field and if there's not then it doesn't same with the revision and the bundle fields so it gets the fields if it's got the right annotation any more questions or does everyone want to see a demo of deploy yeah okay so let's so here we're looking at a single site content staging so you'll see up in the top toolbar we've added a number of new things that you don't get in in core and just to kind of note first that this is all contrib stuff so this is stuff that's available now you can use this today on your sites so up in the top toolbar you've got where it says stage on the top right there this is then a drop down that gives you a switcher for workspaces so you can see we've got a live and a stage workspace and down the other side you can add a new workspace then next we've got the update button that allows you to update your current workspace this is a bit like a git pull or a git rebase to pull down any changes and you've got deploy which is to push your changes so let's get playing this where we're going to add an article and so this is just kind of a standard node we're going to add a title, we're going to add a body and then we're also going to add some other entity reference type data so we're adding a menu link so a menu link is actually a separate content entity but it's just attached to this node using an entity reference and we've added three tags there as well which are also entity references taxonomy term entities so we can now switch over to live and back to stage and see that there was no content on live, there is content on stage we can create a deployment so we give each deployment a title so you can look back at a log of your deployments and now switching between live and stage the content is there the menu link is there, all the taxonomy terms are there so they all stay connected and they all get transferred over as one we're now making an edit on the live site so we're editing the node title and also the menu link so when we save that you'll see that the menu link has changed and the title have changed again they're two separate entities and back on stage they haven't changed but you can do an update and that will pull things down from live to stage so that's how it currently works in Contrib and this is kind of ideas that we're looking at when moving to core as well I think it's a quick question I messed with that a couple of months ago and was both excited but then I hit the image field and the file object didn't sync has that been addressed or is that being addressed in relative short order when everything was clearly still marked under development at the time so it wasn't shocking there were pieces missing we have been working quite a lot on file entities and that's working I believe I don't think we've had any issues for a while now and we recently had patches also for media so both file entities and media is working because those are two different entities I think we still need more test coverage here but it's certainly high up in the priority order so it was that so I've got a second demo video here for cross sites so you'll see right up in the top bar there I've got two tabs open Drupal 1 and Drupal 2 I've added a user called replicator so this is a user that we use to authenticate between the two different sites and we've got a special role and special permission to the replicator user so we're going to add that replicator user in as our default replicator user on Drupal 1 so if anyone needs access to Drupal 1 they'll use those credentials we're going to add a remote so this is where we add what Drupal 2 is we add in the URL and also what we call the API root so it's just relaxed by default and we add the replicator user that user also exists over on Drupal 2 so then we can go over to the workspace UI and edit the live workspace and we can set the upstream to the live workspace on Drupal 2 because when we added the remote it knows about all the workspaces on Drupal 2 and adds them as upstreams so we can then add an article exactly the same as in the other demo with menu links and taxonomy terms and push that over to Drupal 2 so this is using the CouchDB API for replication so this is the relaxed module and it doesn't actually use CouchDB you don't need CouchDB installed but it's exactly the same API we've built a CouchDB replicator in PHP as a Google Summer of Code project last year so it's using that PHP replicator so exactly the same UI from deploy give it a title push it over, it takes a little bit longer because it's running over HTTP to a separate site but we can now go over to Drupal 2 and we'll see that the content's there and just the same as the first demo we can make changes on Drupal 2 which is a live site and push them back to Drupal 1 so the question is can you do a pull and that's kind of what we've got with the update button and it pulls down from the upstream so that's currently how we've implemented that but as I said earlier these APIs are very flexible so if you want to build a different UI to select where you want to pull from and what you want to pull to then it's very flexible and the UIs can be very easily built for that so basically having some sort of discovery mechanism so that you wouldn't explicitly have to state a relationship between two sites it's an interesting one let's discuss it more afterwards perhaps to understand everyone want to step up to the mic so the question is about menu links and if there's a different menu structure and yeah it can be tricky the menu links currently attached with NT references I believe we switch all of those to UUID so we can attach them up but then if you've got a different URL there are different sort of node IDs between workspaces because they are in fact two different nodes so the best suggestion there is to use something like path auto and make sure that you've got the same same settings so that it generates the same URL on each workspace in general what we're looking at here conceptually is replication so it will be tricky if you move content between two sites that are different you certainly can it's nothing that stops you but we look at it as replication so we want to replicate what's in one place to the other place so that they are in the end the same if you're looking at content sharing between sites then perhaps you would choose to only replicate certain content entities and not something like menu links that are most likely going to be different between the two sites we have a concept coming of filtered replication so you could do exactly that like replicate only nodes or only terms or terms and nodes and skip the menu links if you do have that sort of use case where you want to share and something might be different between the two sites so deploy module exists for D7 it looks significantly significantly different and it's certainly not as powerful as this and will never be able to be there are some key things that are missing in the entity API for D7 so conflict management and sort of this workspace concept will never be able to be implemented in D7 what you need in D7 is then two different sites you need a dedicated stage site and a dedicated production site and then you can use deploy between the two and just in the past month or two we've actually opened up two major versions of the D7 module with a big number of improvements that Dave Hall has been working on so if you've been using or looking at deploy module for D7 before it has recently got a big overhaul with UI improvements and some stability improvements so it's certainly not anywhere close to what we're looking at here but it's a decent solution for D7 thanks


Colts and the Raiders, uh, go head-to-head in Oakland game. We talk a lot about this, you and I, this week. This is your favorite bet of the week. Which way are you going? Yeah, it is. And, you know, guys, if you're just watching one of these isolated videos, it's difficult. You know, we-we want to talk about every football game, but it doesn't mean that I have a best bet on every game. And if you have a best bet on every NFL game, you probably have a problem and you're not doing it right. Um, but I'll tell you, the last two weeks, that single game that we isolated is our best bet of the week. A couple of weeks ago, it was Seattle against Oakland in London. Last week, it was the Minnesota Vikings against the New York Jets. This is the one. Now, we-we can make a strong case for Carolina as a home underdog, but it's not often, uh, Greg, that we basically have a coach and a franchise and an organization that are openly trying to lose like this. They are telling you, we don't even want to win this game.  Gruden wants the top pick in the NFL draft. He's going to get rid of Derek Carr after this. They are completely rebuilding. So when they get to Vegas, they have a new, fresh team. These-these stars that they had to Cooper's in the cars, they weren't gonna make it to Vegas. The-the room is not a good one right now, uh, with the Raiders. We saw the story about Derek Carr, about a lot of players on the team, really wouldn't be, you know, they were upset that Cooper's gone right now. And I'm all right, Cooper, but they wouldn't be shedding any tears if Derek Carr got traded now as well. A lot of them don't like Gruden.  And, you know, Gruden said, we're not tanking. We're trying to win this year. And clearly they're not. It's not a healthy room.  Andrew Luck is having a great year. Now you got T.Y. Hilton back. You know, people don't realize this, but the Colts, they actually have the 11th Russian attack in the national football league. Marlon Mack providing something for them right now. And if there's one thing about Andrew Luck is he's a competitor, guys. He wants to win. I don't know if you can say the same thing. We know Frank Reich wants to win. They're trying to build something in Indianapolis right now. Meanwhile, John Gruden, you know, you've got a renovation on one sideline and you've got a destruction, you know what I mean on the other. They're tearing down a building with the Raiders. Colts are trying to build a building. I got to take Andrew Luck here. It's my best bet of the week. Give me the Colts minus three. Best bet of the week from Gabe. He says that I'm listening Colts as three point favorites in Oakland. I absolutely love it as well. Let's go with Gabe.


Neo was rebranded from ant shares and is often referred to as the Ethereum of China the Ethereum killer and dog and the one There are a lot of reasons to look into neo But for today we're going to focus on neo's goal to create a smart economy by digitizing assets and automating the management of digital assets using Smart contracts the equation goes something like this digital assets plus digital identity plus smart contracts equals the smart economy Neo wants to bring everyone into this new economy by making it as secure and simple as possible Here's the breakdown digital assets digital assets are programmable assets that exist in the form of electronic data in order to buy and sell digital assets You need to have a verified digital identity digital identity refers to the identity information of individuals organizations and other existing entities in an Electronic form in order to transact with complete trust neo has the neo contract smart contract system Contracts with the main feature being that you can program neo smart contracts using existing programming languages Which is different than a theorem which uses its own programming language solidity This all makes up the neo smart economy which has set out to digitize all assets and allow trustless digitized commerce on a public blockchain So companies will be able to digitize their services and product To build apps on neo in order to safely and transparently transact with one another to understand this let's go back Basically in the beginning if I had a berry and you had a bunny We trade if I reneged on the deal and scarfed up the berry as soon as gave me the bunny Our tribes would war and people would die and the whole scene would descend into chaos Then we became more civilized if I wanted to trade my berry for your bunny We could set up a time and a place and transact and if I reneged our respective legal systems could make sure that you will Compensated for your lost bunny and I was punished for my berry addiction from there the internet grew and now I can trade my Berry in America for your bunny in Japan We make a deal and you send me the bunny and I again reneged in this case depending on how much information you had on me You may never get reparations for my misdeeds and I can sit fat and pretty with berries bunnies and alliteration This is the problem neo hopes to solve with a smart economy with a smart economy My identity is verified even if you cannot see it my berry is digitized and so is your bunny We enter into a smart contract which is made up of code and cannot be bribed or corrupted The contract can track the entire exchange to ensure that I receive my bunny and you receive your berry And we are both happy and neither of us can renege if you like the sound of neo and their smart economy It is currently sitting in the top 10 coins on coin market cap with a price of around $130 it can be found on a number of exchanges tune in next week for our follow-up on gas the currency that fuels Neo's ecosystem as a result of poor time management skills and seasonal depression We are not able to fit in as many jokes or comedy into this video as we would usually like so as a form of apology We will leave you with this