All to the Universal Code of Conduct Enforcement Guidelines roundtable. My name is Sally and my pronouns are she and her. And I've had the pleasure of working alongside the enforcement drafting committee for the last little while. And I would love to take a moment to introduce you all to your panelists for today. So if we could go through the room and if you could introduce yourself, your pronouns and how you were involved with Wikimedia and the UCOC. Could we please start off with Ruby? And I think we might be having a little bit of technical difficulties with Ruby's connection at the moment. So we'll just pause there for a second and maybe if we can skip to Barkeep if you could introduce yourself and then we'll jump back to Ruby. Sure. Hi. I am an editor who goes by Barkeep or Addison Bryant. My pronouns are he him. I primarily edit English Wikipedia where I serve as an administrator and I'm currently on the English Wikipedia arbitration committee. And I am excited to be on the UCC enforcement guidelines drafting committee and now the revision committee. Thank you so much Barkeep. I'm going to pass it off to MJL next. And I think we may have some connection issues with MJL as well. Ray, would you be able to go next? Sure. Hello. Cool. I am Ray. I don't use the name Vermont. I am a steward admin check user on two projects and I also work on the communications team. I am part of the revisions committee and I was part of the phase two drafting committee as well and I use their pronouns. Thank you so much, Vermont. We're going to try to jump back to Ruby at this moment. And perhaps it could just be myself. Patrick, are you able to hear Ruby? No. I think Ruby must be having some connection issues. Okay. And maybe we could try back MJL if you're able to introduce yourself. MJL is disconnected and is currently waiting to be let back in. Yeah, it looks like Ruby and MJL are having some issues with connection here. So we'll hopefully introduce them when they're back. Alrighty. So Sally, I could jump in and do my short history of the UCC here. Beautiful. Thanks so much, Patrick. No. So Gretchen, if you don't mind just putting the slides back to slide four there. So yeah, I think that most folks are at least aware of the term UCC. They've probably seen it show up in different places, but I think there's probably some viewers who haven't heard about the UCC at all. And so we'd like to just do a quick history of UCC and then we can go back to our panelists for questions. So the origins of UCC were really from the movement strategy process. So we've probably some of you participated in that process maybe, but it took place 2016 to 2018. And really talked to Wikimedians around the world to try and see what programs they'd like to see the movement make in the next 10 to 15 years. And one of the recommendations was to create a code of conduct. And the specific recommendation was create a code of conduct in collaboration with communities to provide a universal baseline of acceptable behavior in the entire movement. Gretchen, are you able to advance the slides for me? Apologies to viewers. We'll go back a few there, Gretchen. Back again. Sorry folks. There we go. Thank you very much. Next slide, please Gretchen. So after that recommendation came out, it was really a matter of sort of trying to talk to communities about what their priorities might be for universal code of conduct. So 19 different communities took place in some initial conversations in their own languages on their own wikis. Talking about what they'd love to see from a code of conduct and what they really didn't want to see from a code of conduct. From there we put together the first drafting committee and we had folks from around the movement from different roles come in and starts throwing around ideas and creating a first draft. We had the community review that first draft, a lot of really, really good constructive input and the drafting committee was able to make some revisions. From there we asked the board to consider this code of conduct and they were quite happy with it and decided to ratify it and that was last year in 2021. Next slide, please Gretchen. I think most of you who have been involved in policies, either enforcing them or writing them know that a good policy isn't quite enough. You do need to have some guidance for the people using the policy about how it should be enforced. And in our movement, we have many different conduct policies across our projects, hundreds of different policies. We have very different ways of enforcing policy in our communities from very large established systems and large wikipedia to more informal, more social systems and some of our smaller wikipedia. So it was important to try and write some guidelines to help our communities mesh together some of those practices in a way that works for the UCMC. So many more consultation surveys discussions with communities we have a second drafting committee come up with some enforcement guidelines. And again, we brought a draft in front of the community and the community had a lot of different feedback on it. So the committee then made some more revisions and we had a full community vote on the guidelines. Next slide please. So we had a fairly good participation in the vote. It was about 56, 57% people supporting about 40%, 41% of people opposing. The vote also allowed people to give some comments about what they liked or didn't like about these enforcement guidelines. So after reviewing these comments and the vote, the Board of Trustees saw that there were some areas of concern in these enforcement guidelines. So they asked a revisions committee to be put in place to hopefully make some changes and improvements to these areas of concern. Next slide please Gretchen. The timeline that we're in the middle of right now, the revisions committee is working on some areas of the guidelines to try and make some changes and some improvements. There's also been a readability and translateability review of the document that was one of the feedback piece of feedback that the committee got. We're just going to outline some areas, specific areas that the committee has been looking at. One aspect is training around the UCFC, how it should work, who should provide it, whether it should be mandatory or not for certain groups. These are concerns that community members had. Next slide please. Another one was trying to make sure that people are aware of the policy and how they should sort of agree to it. And so this is called affirmation. And so the committee is looking at some of the challenges around affirmation. Right now we don't have sort of formal acceptance of policies or improvements. And so with the exception of the terms of use, of course. And so the committee is trying to navigate some ways to increase awareness of the UCFC without making it a divisive issue. Next slide please. The next slide is when cases are reported about violations or potential violations of the UCFC. It's quite difficult to strike a balance between protecting the confidentiality of a person who's making a report and keeping the person who has been reported informed or let them know about what's happening with the process. So the revisions committee is really spending some time trying to figure out that aspect in a way that works within our movements within the limitations of a volunteer system, but also provide some fairness in the process. Next slide please. So the revisions committee is hard at work right now. And they will be presenting their new revisions to the enforcement guidelines in September. And so we'll definitely be letting everyone know about that review in the beginning of September. And we'd love to have folks drop by, give their opinions and some of the changes. The committee will be again going back to incorporate feedback they get from this process. We'd love to hear whether people like the changes, don't like the changes, or would like to see something different. And so we'd love to see you all in September, but I'm going to stop taking up all the time of the committee here. And I'm going to give things back to Sally to open things up for questions. So I see a lot of folks in the chat. Please drop your questions in there. We'll get them in the queue. We've got a few pre submitted questions we're going to start with, but yeah, we'd love to see any questions you have in the queue and we'll get them into the mix here. Sorry, Ruby has indicated that she's trying to get back in. And so I don't know if there's someone technically who can help her rejoin the room. Very good. Gretchen will hopefully help Ruby get in. But I'll give things back over to Sally. Awesome. Thank you so much, Patrick. We'll get started with some of the questions here. And as folks join us, we'll be sure to let them introduce themselves. We have Ruby back. Ruby, can you hear me? Yes, I can hear you. Awesome. Would you be able to introduce yourself in a quick 30 seconds perhaps? Yeah, my name is Ruby Dameshi Brown. So I'm from Ghana. My pronouns are she and her. I'm part of the Open Foundation West Africa Community, and I'm happy to be part of the Traffinal Enforcement Guideline. Yeah, thank you so much. Thank you so much, Ruby. And we'll get started. We'll jump into your questions and MJ, we will give you a chance to introduce yourself when we get to you. And one of the questions are, what are some interesting things you have learned about policy enforcement in Wikimedia communities as part of working on the committee? And I'd love to start off by hearing what you think of that, Ruby. And so the committee is currently working on presenting a new version of the Directive of Application to the United Nations. In the beginning of the month of September, there was a candidacy from across the world. Afflates, jokes, and other jokes. This is not too bad. Yeah. So what are some of the things you have learned about policy enforcement in Wikimedia? One, we have been saying this for seven years that this person doesn't have a certain right for the absence of policy enforcement. It's not enough to have a universal code of conduct. We need an enforcement guidelines. And which is what I've been part of this committee helping to draft this enforcement guidelines. And being a member of this committee, I've learned so much and I see why it's relevant for us to have such an universal code of conduct that all of us can make use of. And one interesting thing about this policy is the fact that the committee itself is made up of different representative of people. And that includes WMS staff, volunteers from different regions, and individuals from minority groups bringing that kind of diversity of views and perspective when we're deliberating on issues. And that is the whole period of this committee because we have that kind of diversified understanding and in dealing with some of these issues or helping to understand and digest some of these community feedbacks that we get whenever we reach out for community. This makes the policy very intriguing and helps us to deliberate and examine issues from different perspectives. Another interesting thing that I think I've learned from this policy was that we didn't do it in isolation of the community itself. We, from every stage of drafting, we engage the community, we digest their feedback and we see how we, we are able to incorporate these feedbacks into drafting this policy. And so I, this is one of the things, these are some of the things that intrigue me about being a member of this community. Yeah. Thank you so much, Ruby. And yes, I really hear what you're saying about the diverse opinions being brought towards not only from the community, but also the members of the committee. Thank you so much for sharing some of those insights there. Barkeep, I would love to hear some of your thoughts to that question. And please let me know if you'd like me to repeat it. No, that's quite all right. You know, I think something that I'm not sure I would say I, I have learned because I knew it, but I've learned a lot of the specifics of just how both how similar enforcement is in a lot of ways across the movement that a lot of policy is very similar. There might be small differences in details across the movement, but policy itself and guidelines and how we kind of handle you see is largely the same. There are some notable differences in that but but pretty similar. But even with kind of similar wording, the way communities actually implement and practice that can be fairly different that there's a little that they can be fairly different outcomes. And so that has been an interesting piece to me. And I would say, kind of learning. I did not know much about how affiliates have handled kind of their use you see type enforcement pieces and so that has been a really for me to learn through this process, because we do have at least we have a couple of people Ruby and another member who are both members of affiliates and speak to that experience. Thank you, Barkeep. And would also love to hear from MJL if you're are you connected at the moment. I believe so. Awesome. Would you also be able to quickly introduce yourself before we jump into your answer. Yes, my name is MJL pronouns they them I am a editor on English Wikipedia, and I do YouTube as well on the side. And Sally, could you please repeat the question for me because it's been a while since I want to make sure I answer right. Of course, what are some interesting things you have learned about policy enforcement in Wikimedia communities as part of working on the committee. I definitely have learned that I going into it I understood that everybody has different opinions about policy enforcement. And then, but being on the committee I were, I learned that people really have different opinions about policy enforcement. Which I learned that it's been a very interesting hearing the community's perspective on a lot of different things. So I that's definitely been probably the most interesting because I thought I understood the community's position I can on policy enforcement pretty well but honestly, no, and it's been a humbling experience. Thank you, MJL for sharing your insights there. We're going to jump into our second question, which is, what kinds of changes have you been working on during the revision process. And I'd like to start off by hearing some of your experiences there, Vermont. Sure. Yeah, so we had, as many will remember that vote and the rather large consultation period and a lot of feedback that we have. Basically, all the changes we've been making has been towards the areas that were highlighted by community discussion in those in the consultation period and working to address concerns and also to update the document with other plans that we had. It was not a finished document. It was a draft. And that includes, as I think people have asked about in the comments here, the information affirmation and training. We put a lot of effort into those weeks of just talking about affirmation and training and making sure that we get it right. Yeah. Thank you, Vermont. And Berkey, do you have some thoughts to add on that? What are some of the changes you have been working on during the revision process? Yeah. For me, I think, you know, Rosie's email was a, or Rosie's statements was a great kind of charge for us. And I was, I really appreciated the board saying, we appreciate that 58% of the participants liked this, but, but we really hear the concerns of that other, you know, 40, 41, 42% and want to see if we can't do better. And so I think there have been some easy fixes such as around training where I mean, we had some changes to make. But, you know, they were fairly easy for us to hammer out. I think that we have had some more difficult pieces such as balancing the rights of people who are being harassed with the kind of more general right to understand what someone, what you're being accused of. And so, right, so that is a tricky piece. And so, so I would say that's there. Something that we have started to do, but I think we have a lot more work to do. And so, and looking forward to community feedback to help us do this is I think, kind of, and the organizational part and making it easier to read and easier to translate, I think, and just easier to understand because we saw during the initial feedback that committee members had one understanding, but a very, but of certain pieces of text, but that the community fairly consistently read something in a different light. And so I think we have some more opportunities to to fix those areas as we kind of get some community feedback and and continue our work after in the kind of second phase of the revisions. Thank you, Barkeep and really appreciate that insight about what you've been working on in this revision process. Ruby, do you have some some other perspective to add. I think he said it all. I think basically what what we've been doing is trying to fix some of these issues, fixing the wording, making sure that phrases like the sentences have that clarity in it. So basically, these are some other things and how we're incorporating community feedback into the text that we dropped them yet. Thank you. Thank you. Thanks, folks. We're going to jump to a question from the audience here. And we can maybe start off with MJL. The question is, beside the board's decision, what are some things that you personally or the community committee felt needed to improve? MJL. I definitely thought the training aspect, the training and the affirmations were probably going into it. I understood could have been a lot better and a lot more had a lot more improvements. So I was honestly kind of excited when the board made that statement because I was like, okay, I'm really glad we can tackle this again because we got, we had a lot of good feedback about that. And it was definitely clear that the committee's intentions, which were one thing versus what we ended up releasing didn't exactly like line up. And so having the ability to actually make it more clear to our original vision was something I was really excited about. Thanks so much. And we'd love to also hear from Vermont. And please let me know if you'd like me to repeat the question. Sure. Yeah. There is a lot that we have worked on improving. And unfortunately, one of the things about doing a big community consultation about a 15 page document is that there are areas of the document that need improvement that don't get much attention because people are only focused on the big stuff, like affirmation, training, and right to be heard. We have done a lot of other changes. We've fixed wording, we've clarified things. We have, what else is there? We've talked about like how we handle different types of cases, how existing enforcement structures handle them and how we want to write our recommendations in line with that. Yeah. Thank you, folks. Okay, we'll jump back into some of these questions here. What are some differences in community practices between different projects that you have observed? I would love to start off with Barkeep and hear your thoughts on that. I think that different communities have pretty different levels of, so I think different communities have different levels of kind of community involvement in enforcement. And so, you know, some of our larger wikis will have multiple places that enforcement will happen. Where some of our wikis have an arbitration committee that our MGL, I think you're, you might want to mute there. So some of our communities have arbitration committees, as I indicated, but even arbitration committees can have different roles there. And then, you know, I think the tolerance for our ability to have kind of private complaints is also a major difference that I see across the movement, and I'll kind of stop there. Thank you. Apologies for that, Barkeep. I think we missed the last part with some feedback there. Are you able to just mention the last part that you were speaking to? The private, the ability to kind of hear complaints privately at any level, you know, and how much ability and or community policy support there is for kind of private complaints is something that is very different across our movements. Awesome. Thank you. We're going to jump into another question from the audience, which is, how does the committee mitigate possible anglo-centrism in the worldview and process? For example, today's expectation for everybody to state their pronouns is incredibly anglo-centric, also posted on movementstrategy.org. Would love to start off by hearing your thoughts on that, Ruby. This is a really hard one. Can someone take the lead? For sure. Barkeep, would you be able to answer some of this question? I mean, I am quite sympathetic to the complaints here, right, that we have three of our four panel members here are in the United States, and so, you know, that is certainly a concern. We do have members from other continents, right, so besides Ruby, there we do have people that are living, working part of communities that are outside of the anglo-world. We have also been reaching out to, you know, groups inside the Wikimedia Foundation as the Wikimedia Foundation has really kind of expanded their workforce to make sure that it is not so anglo-centric to get some feedback on that. You know, in terms of the pronouns, that is tricky, right, because I would say the first phase had, I would say the enforcement has had a slightly, as a percentage, has had slightly more anglo-centric contributors. There, the first phase where like things like where a lot of the kind of gender and pronoun pieces came out did kind of come out of that piece, and so I think that is an interesting part and something for the movement to continue to talk about. And I hope there's a really robust discussion about that when we kind of reach the, let's take a look at the UCOC as a whole and see what revisions need to be made, which the board has indicated. I think there's definitely a lot of work that can be done, and I'm hopeful that after we see the UCOC in action for a little bit, we will be able to evaluate that and see what parts are working and which parts need to be adjusted to be more culturally sensitive for the entire movement. Thank you, Berke, and would also look to hear from Patrick on this question. Hi, yeah, I guess I didn't even introduce myself at the beginning of this. I'm really sorry, folks. My name is Patrick Early. I'm a lead project manager, sorry, policy manager with the trust and safety team, and I've been working closely with the UCOC for a while. But I do want to mention that this is definitely one of the concerns that the Board of Trustees pointed out is that, you know, it's not just sort of this specific area of pronouns and gender, but that the whole document for the enforcement guidelines was difficult to translate into some languages. It has some idioms and some structures that did not translate very well, and readability in general could be improved as well.  But we have been trying to support the committee in having some of our more experienced translators at the Foundation take a look at the documents and review it. We've also had folks with academic experience and education on the general concept of translatability, take a look at the document and make some suggestions. So it's, you know, it's a difficult one. I mean, I think to get a document that is, you know, universal, as in the title of the universal code of conduct, is a challenge and probably an aspirational goal. But we have to try to get close to it. And sorry if I've insulted committee members by saying their work was not readable. It was definitely readable, but it could see some improvements. Thank you, Patrick. And we're going to answer another question from the audience. It is, how are small wiki projects represented in taking decisions in the UCOC? Vermont, are you able to start us off with that question? Sorry, what was that question? How are small wiki projects represented in taking decisions in the UCOC? Well, the difficulty here is that this is, we are writing, or rather rewriting the enforcement guidelines for the universal code of conduct. This is the revisions committee. We have not written the universal code of conduct. We have written the enforcement guidelines. One of the things that we have definitely focused on is how can we best integrate the benefits of the UCOC with existing enforcement structures. So like, how do we create a functional document without accidentally destroying the way that projects do things? And what we have is people from a bunch of different language projects. We have someone from the affiliations committee. We have someone from Arbcom. We have me, I'm a steward.  Yes, we have three people in the US, but all of them have very different histories and enforcement processes and very different understandings of them. We don't have any small wiki admins, but we do have who are people who are familiar with both small and large wiki processes. And we've been able to, I believe it is a document that supports them without disturbing the way they engage with their workflows. Thank you. Appreciate your perspective on that one. And we'll head back into the questions here. In what was the most difficult topic area you faced when working on the guidelines? And would love to hear from all of the panelists on this question. What was the most difficult topic area you faced when working on the guidelines? Ruby, can we start with you? Sure. This is very interesting. I mean, we had difficult instances where we dealt with it. But one of the most difficult faces that I think for me we felt was when we're dealing with some real cases and seeing how these cases will be dealt with in real life. And deliberating on these cases, some of the thoughts that came into mind was how can we ensure that third party reporters or victims are protected while reporting cases, especially when the case has a potential of putting people at risk when reported or putting the victim at risk. We are also like, how do we deal with a third person reporting a case when the parties involved do not see anything wrong with what they're doing? For instance, we have two individuals on Weki abusing themselves or using abusive words, throwing some chats on their top pages and all that. And these two individuals don't see anything wrong with the kind of all the choice of words that they're using. And this is a case, and this case is reported by a third party who sees everything wrong with this. So dealing with this issue, it becomes very complex and very cumbersome because I mean, the Weki space is made up of different communities. What might look like an insult to one community can be a greeting for another community. How do we even differentiate that? So dealing with some of these cases or drafting guidelines for some of these cases becomes very complex. And another instance is how to deal with vandals. Of course, there are many things that we cannot avoid. How do we stop people from vandalizing or abusing this reporting opportunity that we've made for community members? We also want to ensure that staff and volunteer time are not wasted in handling things that are not even real in the first place. So this is also like some of the difficulty that we foresee. And these cases may look very simple when dealing with or maybe when you read about it, it looks very simple.  What's the value going to take in dealing with this issue? Realize the complexity of it. So this is like some of the things that are identified as kind of like a very tricky and difficult area. Yeah, basically. Thank you, Ruby. I really appreciate you bringing contextually how every case can definitely look different in different parts of the world. Thank you so much. We would love to hear from all the panelists on this question. MJL, what was the most difficult part or sorry, difficult topic area you faced when working on the guidelines? The right to be heard definitely for me was that was a lot of difficult stuff because I, I felt like the community was asking us to solve some problems that were extremely, extremely complicated. And that the community itself didn't have answers to so I was more than happy to receive feedback about it. You know, we're still ironing out a lot of the kinks with the right to be heard. I can't, it's definitely dwarfed anything else that we've worked on, even during the first go around of drafting. I can't, because we, I know we had a lot of contentious things that we had to work out in the first round. But this, the revisions committee with the right to be heard is definitely, it's definitely been a very, very, very, very complicated process and contagious. Thank you. And we'll go next Vermont and then Barkeep Vermont. What was the most difficult topic area you faced when working on the guidelines? Honestly, this would be the training bit. We put a lot of effort into training. There was a lot of discussion over. Let's go for this. We had a lot of talks about the specific content that we wanted involved in training and the level of specificity we wanted to give to that content, because at the same time we're kind of rebuilding the U4C policy and how the U4C building committee is going to look and they're going to be the ones who actually make the training. And there were a lot of discussions over, okay, what is the training for? Are we doing levels? Are we doing modules? Who are we recommending take which trainings? It was all really helpful. So, yeah. Thank you, Vermont and Barkeep. We'd love to hear your thoughts. I mean, I think MJL is correct that the balancing of rights has been is one of the trickiest things. But for me, my answers would go back to the phase one pieces. I think the two pieces that I would like to identify that have been hardest for me were first kind of making sure that enforcement processes that are happening across the movement are for universal code of conduct like behavior, even if it wasn't labeled UCOC enforcement, right? A lot of projects are already actively enforcing these areas. And let's make sure that nothing we do will stop that work from happening, right? That we are not going to undermine local processes. And this goes back to the question of how do we counter English centrism? We need if, right, so an important principle that one of our members introduced was the kind of, I can't remember the English phrase, and she talks about it in French. But it's basically the idea that enforcement should happen at the most local level possible in most circumstances. And so kind of respecting that idea and making sure that that played out throughout the documents was super hard. And then I would say everything around the universal code of conduct coordinating committee, commonly known as the U4C was incredibly hard. And it was so hard that essentially towards the end of the process, the committee threw up its hands and said, this is so hard that we need to have a whole separate group that is going to do this themselves after we're done with our work. And I think that reflects just how hard and complicated and involved that what is going to be. Thanks, Barkeep. We're going to pass it off to another audience question here. And perhaps we could start with MJL. And it is, in what areas do you or committee think community input is lacking? That's an interesting question. I think a lot of, I think, I actually don't know, because it's been in general, like most of, I would have loved to see more community input on pretty much everything. Like that's, for me, it's like, I would have, I feel like it's been a very, the community has been very disengaged with the process, despite it probably being one of the more important things happening in the Wikimedia movement at the moment. There's definitely, from the technical code of conduct and the, and their committee, I would have loved to see more media wiki developers, you know, weigh in. That's definitely, I feel like we haven't gotten a lot of feedback on how the technical code of conduct is going to interface with the UCOC. And I feel like that's probably one of the, I would love to see more, you know, feedback from, from folks covered by that. Thank you. And would love to open that space up to other folks on, on who are panelists here. In what areas do you or committee think community input is lacking? Are there any other thoughts? Please feel free to, to, to speak openly right now. And I can then move on to another question. Yes, Bertha, please. Yeah, I have a thought. I think, I think it's a really hard piece, because I think we have, we want to provide lots of opportunities for community feedback. But I am hearing from multiple communities that they are feeling burned out from the amount of the amount of feedback. And so I think we're just having to walk a tough line because we genuinely want community feedback. But we also want to respect that people are feeling like, boy, haven't I already done that? And I think especially that, you know, there were lots of people who were talking about the needs of their, the need to kind of balance rights between people in the first phase and it didn't, and that feedback wasn't listened to until it kind of came out through the comments of the ratification process. I mean, it was listened to that's not quite fair, but it wasn't, it wasn't acted on in a way that really felt good until, until the board statement. And so just kind of want to recognize that, that complexity for the community there. Thank you, Barkeep. Were there any last panelists that would like to speak to that question before we move on? Awesome. Thank you so much. So I do see that we are nearing time here and would love to pass it back to Patrick to, to, yeah, pass it back to Patrick. Yeah, I'll just close out. But I think I just got a message from Vermont who actually had something to add on the Anglo-centric aspect. Vermont, do you want to hop in and just make a comment there? Sure. Yeah, unfortunately, I don't think either I'm jail or I had the opportunity to respond to the Anglo-centric and pronouns related comment. I understand there is a large issue with Anglo-centrism and the way that we have formed a lot of people based in the US we do have a lot of people who are not based in the US but the issue stands there is a balance to be made in every foundation related committee between experiential diversity and geographic diversity. I feel like we have definitely hit the experiential aspect but we have not exactly hit the geographic aspect. What it will also say is that the idea that respecting people's pronouns and how they want other people to refer to them is Anglo-centric. That idea is patently unacceptable in the Wikimedia movement and not something that I'm going to address seriously. Because we have very clear history of maintaining a degree of tolerance and acceptance of other people's identities independent of people's traditional cultural beliefs. And on Wikimedia projects you have the right to be respected for how you want other people to refer to us. Thanks for that, Vermont. It's definitely an issue that is something that our communities are struggling with as well and I'm glad that we have a committee that is willing to tackle that issue. It is incredibly difficult. I'm going to close out our presentation today. I want to really thank Ruby, MJ, all Barkeep and Vermont for joining today. They've put in tremendous amounts of work with their other fellow committee members. And to do this presentation was something extra but they thought it was quite important and I agree it is important to help Wikimedia attendees understand where we are with the process. We saw a question earlier on about how can I give some feedback on these upcoming revisions. I just want to remind folks that we are having a community review of the revisions in the month of September. We have tentatively put September 7th as the opening date. Just be aware we might have to shift that but it looks like we should be good to go on September 7th. We will be working with our movement strategy and governance team to make sure that we get as much messaging out about that consultation as possible so that everyone knows how to take part. Again, if you have something that you really think you want on the table, there's many ways to reach out to the team. But we'll definitely communicate through on Wiki, social media, the new movement strategy forum as well and we'll do as much as we can to make sure that everyone has both the information they need to take part. But the ability to take part in different ways. So we're hoping to have some conversation hours so people can take part verbally as well as on Wiki consultations and gathering information through other channels. So we're trying to make this as accessible as possible. I see my little counter is getting down to 15 seconds. So again, I just want to thank all of our Wikimedia attendees for coming. You know, policy can be a dry topic, but we saw some great engagement and great ideas, great questions. And so I'll just wish everyone happy Thursday and I believe this is one of the last sessions of the day so if you're tired, get off the computer, go for a walk. Have a wonderful day.


Good day, my name is Kate Stewart and I'm a director here at the Linux Foundation and I've been looking at a lot of issues around embedded and Safety critical Applications and working to see how we can get it so that we can be safely using open source projects in these very important and relevant realms that we're seeing a lot of innovation occurring one of the Inspirations for me has been Margaret Hamilton and she was the person that basically Programmed the Apollo Space mission and working with the team there and did the testing to make sure that the astronauts could get to the back safely over 50 years ago And a lot of the things that she was talking about then this slide is from the XE conference in 2019 2018 sorry and You know in there she's pretty much saying You know the challenges you had to build man-made software meaning that astronauts lives were at stake And that's pretty much the definition safety critical when people's lives are at stake We need to make sure that our software works and it has to work the first time it has to be reliable and tested and dependable so You need also to potentially be able to detect errors and recover in real time, you know fast forward to today and We've just finished seeing you know SpaceX's rockets and with a good capsule and go up to the space station and dock and You know those are all being run with Linux and so Making sure that we have you know these applications there and That the right level of safety analysis is important. It's gonna be key because we're still going back to space Other things are even like you know down the daily streets We're gonna be seeing more and more of these self-driving cars emerging and then we're gonna be having to see in the smart cities That have the infrastructure to support them There is IOT that's emerging as a very pervasive field that will be in cars and around us And at the part of it all is going to be the fact that we've got safety and then even to a more recent example obviously we're in the midst of one of the you know worst pandemics of my lifetime and When the first started searching earlier in the summer there was a lot of initial Momentum around making sure that there were open-source solutions for ventilators that were available That could be you know Testing reliability We're able to be manufactured And are able to use the field and so forth and an open source Initiative came up to look at which open source options are there for programming them and building them and you know we've seen these Systems and people are wanting to create people are wanting to help and open source gives them a way to do it so given that Open source is already being used in creative applications. So I guess the challenge is now how do we make it safe? And just a little bit more stats around this You know 99% of the code base is audited last year and had open source components in them And up those audited code bases over 70% we're made up of open source projects so This isn't all the case in safety critical space, but nonetheless It's here as a pervasive influence over technology and it is moving into the safety space This was from black depth report earlier this year and then so the type had a report last year that says they're seeing Double and triple digit growth in open source components and these are the components that make these really cool applications that they're already put together And there's no slowdown in sight. So open source is here and it is the seed for innovation So the challenge is now if we're going to be using open source in these safety critical applications, how can we make it safe? And when we talk about safety and safety critical there's a lot of standards out there and depending on certain domains There is the desire Certain things that they test but they have a lot of underlying common elements 61 508 is pretty much a general standard and a lot of the initiatives are focusing on it initially Because it's a key for automotive railways nuclear machine safety and industrial processes So if we can get the generic standards in place and it's a smaller gap to go the other domain specific ones However, all of these have in common as you know, Margot was saying is you know We need to minimize and mitigate the systemic faults and we need to make sure that it is safe Then it needs to be known tested and managed and needs to work and recover from problems And so these properties are still going to be needed here. Um, the thing is that the open source Has had a different methodology for development than these standards were written in front of and so the question is how can we reconcile the other challenge out here is the fact that Most companies are not able to today to accurately summarize the software that's running on their systems the modern digital infrastructure You know, it's a very sophisticated layering of software and you know, we build on the shelves of giants well in the same way some of the modern applications are building on layers and layers and layers of other information and you know As this XK CD cartoon neatly illustrates is the only the recent project out there that all this stuff is depending on that That's not as sustainable as we'd like and so how do we get these things sustainable? And how do we get this infrastructure to be clear and understood part of that's going to be coming up with some software transparency So These are the gaps that we're looking at with what we want to be going after and what we need to be going after for that matter and what We have Available to us today and so we've got to figure out how we can close these gaps between what the safety standards are looking for And what we have today in this rapid evolving exciting open source ecosystem So the first step is actually being able to Understand what you're actually running on your system and improving the software transparency by using some sort of standardized build materials um In the last couple years has been an excellent effort from NTIA They've basically been acting as a serve a neutral broker To try to bring off a bunch of stakeholders together and come up with a common definition of what a software build material is It should be and what a minimum viable Like what fields are you to really need to keep in a software build materials? and we need to make sure that these um This information is there and the connections between components to components and relationships are articulated and This covers, you know Open source and proprietary free and paid It's just a question of we need to figure out how we can map what's being used And you know when well actually pretty much any point in a software life cycle development There's a use for an s-bomb of software build materials because you need to know what you've got You need to know if you've added a patch to it. How has it been built? Is there any certifications are effective with it? You know, are there you know configs that have been used for the version you're using that might have a relevance in a safety argumentation All of these elements here um Could be you should be able to generate a software build materials at any point in your life cycle Is what it's coming down to and be able to ask for it a software build materials for any time you're taking and consuming In a piece of open source as part of a larger product And quite frankly you've wanted to know what else is in the product in addition to open source too So why is there a lot of people starting to wake up and start caring about this? Well, actually it's because there's money involved Um And the vulnerabilities and the impact of vulnerabilities are in the news, you know Pretty much every couple weeks you're seeing any vulnerability that's impacting someone and some of these are actually impacting people's lives Um, you know when there's a denial of service attack going on at a hospital and people can't get access to machines They need because they're being denied a service Um, that starts to impact people's lives So we there's a large a wide Um interest worldwide pretty much in improving the cyber security um in the supply chain And the initiatives that are happening in the u.s. Are mostly revolving around the software build materials coming out of the nta effort And determining how we make that better but you know What is emerging is you know, these things are true and we are seeing like things like containers emerge And containers um are abstracting and hiding even further all those detailed pieces that are being used in a system and so having that transparency And having that ability to understand exactly what you're looking at is a prerequisite for any type of safety analysis And we need to figure out how to get it there And we're also seeing some of the regulatory authorities The site weighing in on this now, especially in the safety crucial spaces like the FDA has Signaled that they will be looking for one. They have not given a date But it has been signaled. So the medical industry is paying, you know, very close attention to this and then uh, recently the um energy For the federal energy regular drug committee has weighed in and expect saying that they are expecting to see and have that expectation of that software transparency and so A lot of these stakeholders are coming together and working to actually come up with um, this minimum viable that I was chatting about And Here's um, like you say from the NERC SIP 13 Um, you know, it's all about supply chain risk management And it has that expectation that you will have some sort of way of understanding what software you're running So you can do the risk assessment. It's as simple as that So who should be using an SBOM? Well, pretty much anyone that's making a software and Deploying software on their systems. You should be asking for them if you for anything you're buying and you should also be Being able to produce them on the fly so that if there's a vulnerability coming out You'd be able to you should know what exactly is in your system and what you're running Whether you know you need to remediate or not And a lot of the aspects that are coming in could be coming in from the contractual the legal Or the technical from the vulnerability side But it also could be from the dependency side and it could be the analysis side the systemic analysis side To make sure your system is safe in context and then deploy and so All of these things are leading us to this type of presence And at the end of the day, um software build materials just make financial sense. Um, there's been quote. Um, that's come out from You know, it's sending, you know, saving hundreds of thousands of man hours rather than scrambling around fire drill mode If you know that you can just look it up as a query on your system And understand which components you have and where they're being deployed Where these software components are and what systems they've been deployed on Um, you can much more effectively manage our mediations as well as Ensure that the system can stay up and operational and fulfill any safety obligations you have with it So at the links foundation, we're looking at a few projects in this space to help with these efforts. Um There's common processes and norms, um working with open chain and that's now an ISO standard Um, that is able to specify what the obligations and expectations are We're looking and working towards building up common data formats. Uh, software package data exchange or spdx has been around for 10 years It's able to satisfy the minimum viable that's been, um, arrived at from the ntaa process And then we also are starting to work on pulling together all the tooling to make effective workloads for generating and consuming software build materials So you understand what you've got on your systems at any point in time And those workflows and are happening within the automated appliance tooling project your act And if you go actually into the specification, um for open chain, you'll actually see that You know right at the very start like, you know one section. It's a very it's a short specification. It's easy to read It's about 10 pages And it's calling for the material that you're summarizing and passing through the supply chain as the software build materials And it has open source components that are listed. And so this is part of pulling together Having sort of standard ways of exchanging the information and having standard formats that everyone can consume Um, it's going to be part of improving that transparency that we're all going to be looking for especially in the safety cases So next step is well, if there's a functional safety considerations um, how do we Focus on understanding the interface's quality and safety characteristics of the open source projects involved We need to actually, you know up the level of analysis information that's available and is a digestible uh for projects and so that When there are in a safety argumentation someone integrates them in with their value The system can be looked at and studied and determined that yes, there is a safety You know issue or and what are the mitigations we might have played to improve the risk things like that So that hasn't been a consideration to a large extent and a lot of open source projects up till now and that's starting to shift um, here at the links foundation, there's several of our projects that are actively Looking at being able to be used in functional safety Um from zephyr and cell 4 which have smaller footprints to you know acorn and sandwich or hypervisors Automotive grade linux is looking at and then alisa is looking at trying to pull these frameworks together to work with linux And so let me start with the bigger one, which is alisa and then i'll go down to one of the other ones So alisa Started off because it stands for enabling linux and safety critical applications, which is pretty much on spot for this Over the last, you know, 30 years linux has pretty much grown to be the most important open source project in the world And 69 of the embedded systems marketplaces already running linux by estimates that have come up in the last years and from other studies And as a result of that You know, we need to be able to handle linux in because a lot of these applications you were just sort of seeing They're using linux in them right now and the automotive cars And the you know space x rockets so forth These are all systems that have linux in them and we need to make sure that it's staying When it's being used as being safe. So we're trying to figure out how do we actually do? You know, how do we actually get the information and do the right level of analysis? And so at the end of at the heart of it, you know, you need to assess whether system is safe It's not linux itself is safe. It's how are you using linux? It's that safe and you have to understand your system For it to be effective Um, and that is at the key of the argument, you know, the thinking here is okay How do you know, how do we are we able to articulate how linux is being used and can we move that forward? So If understanding how you use it is at the key, you have to understand your system You have to understand the linux interactions. Okay, what apis are you using? You know, what dependencies may there be in your system that have also are working with linux? How are the interactions? How does it be configed? All of these are key elements here and you need to Work with when you're using depending on certain properties in linux like a schedule um, you need to ensure that the quality is there as well as The behaviors are as expected and when errors happen. Can you recover back to the you know the days of? Margaret, you know Hamilton's analysis for rockets same things who are holding true today, but we need we've got a very much more sophisticated code pace And so the safety standards, um You know were Designed with a certain methodology in mind Linux has evolved over 29 years And it's continuously being developed. And so it does have a very high level of quality You know, there's continuous improvement processes in place There's things that a lot of the standards are hinting that they want. They're just being expressed slightly differently in linux And there's a lot of evidence from the testing that goes on That the process quality and the process improvement quality already exists. There's you know, there's developed maintainers get together There's a self-reflection period every year To try to figure out what needs to be done better And we have a lot of testing infrastructures and frameworks that are out there that are working with linux Being able to pull this evidence together and make it accessible for people doing the safety analysis is at the heart of what Alyssa is going for So the mission statement for the project is to define maintain the common set of elements and which on processes and tools that can be incorporated into specific Linux based safety critical systems amenable to safety certification so What we need to do is you figuring out this gap closure that we're talking about There's a lot of information that safety standards are looking for There's a working group inside of Lisa that's looking at how to close those gaps And they're working with the kernel community On you know understanding what's there. We want to try to get you know elements upstream We want to get documentation published. We want to get this information available In the upstream as well as have reference material available for people who are going after safety argumentations drawn and then In the components like the scheduler like the memory management units things like that Well, there's various properties because people are depending on these systems to work And how do we do the right analysis of the interfaces coming into them? as well as Understanding these You know what will happen if a fault happens. Can we recover? And making sure that these components are well analyzed And so that people can build it into the rest of their analysis Part of the Lisa is also working with um, you know, okay You can't just look at Linux as known as we sort of said it has to be in the system So we've been looking for open source Applications that are available out there There's a medical devices working group that's looking at the open APS Which is an artificial pancreas loop system between a glucose monitor and an insulin pump That's a obvious project, but everything is nicely open. It's running on an raspberry pi So it gives us a basis to analyze down to what's linux doing in the system And then there's the automotive working group as well That is looking at various applications It will be in automotives that are using linux for like tail tail apps and so forth And doing the analysis again to figure out what parts of links are being used Um and building from there Um, Alisa is able to spin up any other working groups any it's a lot of interest in industrial and robotics And hopefully we'll get one of some of those going in the next year Key is that any applications we start looking at that will feed into the rest of the analysis need to be not under NDAs And we need to have them on open so we can do the analysis and collaborate Yeah, the heart Lisa is a collaboration. Um, we're not going to be engineering any specific system to be safe Um, you know, we can't ensure that people who are using it actually Read the documentation and understand the processes However, we're going to try to create some so that those who are motivated can And you know, we're not creating a standalone linux distro or anything like that It's just how do you use the upstream kernel and how to be effective At this and you know, we're not going to be able to leave you for any responsibilities under God's conditions But we are going to be trying to provide a path forward and people to collaborate with And so that's what Lisa's there. And so if you've got an interesting case, um, we'd encourage you to kind of look and work with us in the project When we're done, um We should hopefully have You know the assets help ready for um helping people go through safety certification So we want to have you know, here's your process here. So you do your analysis Here's the features you need to look at. Um, here's where evidence is Here's some tools to help you understand do your analysis in your system And we wanted to show that it's feasible to do this in some reference systems that everyone can look at like the key is A lot of this work happens right now in companies today under NDA so no one can see it So what we're trying to do is do things in the open so we can share it with others Um, we want to be able to help educate those system interpreters on the things that they need to look at And with the view that this seems to have to be maintained over industrial life cycles, which can be You know anywhere from you know two years, which is your standard end of life on your you know on a device or five years for your phone or you know 20 years for a piece of infrastructure in your city Or even longer in some cases um But there is um a lot of information and we want to make sure that the information we're putting brought providing Is accepted by the safety community and certification authorities And so that you know, there's multiple people people who are going to be doing these audits who understand the evidence It's there and can help educate slash make sure that the right factors are considered to make sure these systems are safe when this third party audits are happening And um, you know, we also for us to be effective here The latest community needs to be able to understand what we're doing and recognize it and make sure that you know Some of the things we'd like to upstream into the documentation as we do the analysis and you'll be able to share We have a way mostly the current community Is very much motivated to fixing bugs and a lot of these things are just bugs So we need to fix these bugs and we need to make sure that we've documented how you know the information that's out there And eventually we will want to have hardware to liable As well from the various vendors. We need the hardware vendors to be bought in because we're running on their silicon and their boards for that So if you want more information about elisa, um, I encourage you to probably go to our next 2021 virtual workshop We've been doing workshops roughly every quarter. We were doing it in person and then with the latest pandemic We've been having to switch to virtual We've actually had more people attending and we've had a lot more engagement as well So I think we're working on a format that helps encourage discussion and engagement. So You know, feel free to check us out Just lurk or I'll start participating in the discussions and if you want to get more engaged Feel free to sign up for the mail list. It's open to anyone and you can start looking at our sources and the github repos are there Now switching over from Linux and a big abstract system. Let's go and look down at what's happening on those sensors and actuators And um zephyr project is um been designed pretty much to work where Linux is just too big Linux doesn't get much smaller than it makes these days and a lot of The embedded space is you know, very very cost constrained footprint constrained very tight on memory and so Zephyr's been designed to act in this area and When we start the project off four and a half years ago We wanted to make sure that it would be able to be a real-time operating system And we built it right from the start with the view that we're going to be going after safety certifications and security certifications So we built it with safety and security in mind And the community is lined up around the fact that we are going to need to have some discipline in certain areas To be able to go after and work with the standards as they exist today So it's cross architecture has a broad base of hardware platforms is over 200 Boards have imported into it. It has vendor neutral governance. No one company own, you know is in dominant control of it And the checks and balances are in the governance document so that you know, the technical steering committee Determines, you know, which direction the projects are going It's permissively licensed which makes it suitable in certain from certain companies minds And it is, you know, very modular like the least kernel is and highly flexible And like the next kernel, it's also adopted the notion of a long-term support kernel And this is where we're encouraging people to work for for products and A subset of those the next LTS will actually be ready to go through the safety audits And so we're working towards that goal in the project now As you can see it's a rather full architecture These are on modular components that can be enabled as needed So this way you can sort of scale your footprint based on what your functionality you need is and then work from there And it's a wide range of communication technologies because it's iot. We need to obviously communicate off of these and so If you're interested in more details It is they're available from the project and as you can see, it's pre-fully featured OS at this point in time That lets people be let's it be a good RTOS basis for applications And we've actually been seeing our products emerge in the marketplace None of these here listed per se are safety critical, but they're wearables and they're getting into some of the performance So you're sort of seeing this project shift and as the safety critical Certifications emerge where it's expecting to see more of the safety critical applications coming in There it's a couple of products here that are being used in They were spun up very quickly. There's things like the distance or from phytech, which lets you know um You know with when you're coming within a zone of people the six foot zone and then the sentries from their technologies is also um, you know designed for monitoring the distances and the characteristics Including, you know, there's also the safety pods from breaking in the factories and for giving feedback if you're getting too close Or according to who you've been getting close to and things like that for tracking traceability So we're seeing this effort being deployed in situations that are going to be helpful for um us getting through this next few years And they can't they were able to spin up these applications very quickly from the product base So but like I said, we'll be getting after more safety critical We're wearing wearables type of deal right now But I think it's going to be emerging into getting into more of these tight loops and More of the safety critical functionality So we just we established our safety committee for the project in 2019. We are fine mature enough. We're meeting every two weeks and the participants are People who understand safety considerations and the implications in that committee and are working to help educate the rest of the community on that The initial target for the project is going to be 6108 sold level three and We've already been established our coding guidelines and those are being applied through the project right now And we're working on getting the continuous integration enforcement going in And then there's multiple safety activities that are going on to establish the traceability The requirements test covers the tooling and so forth And safety committee is taking the lead on this And then working with the tsc to make sure it goes through the entire ecosystem And we are also engaging with the certification authorities in this project right now Um, we're looking at how do we um You know, how do we basically go through the safety plans and the documentation? So it's a much more traditional safety path Then we're sort of doing a Linux At the heart of it, although um quality is going to be the foundation and high quality code and making sure that we have our Defix under control Um, it's not additional from because of safety But we have to have it there fundamentally for security as well as for safety We need to have that quality level there and What we've been trying to do though is with open source We have a very rapid change where new functionality is added and new features are added and so forth And so we've been working on a um development Repository and that has a release every four months And so it has a fairly frequent cadence and it comes up with Here's what we need to be doing um And here's new features and then we you know sort of make sure we have a release that we keep the squad Keep the squashing the bugs down things like that And then every two years we come up with our long-term support And we agree to maintain that and put security fixes and backports in Over time and then the safety and security process is we taking a subset of that LTS And that's that subset is what we'll be taking through the first certifications So that audible subset is you know, um, it's going to be established from that LTS and our LTS next LTS will be next year in the summer And we'll be keeping the code bases in sync with it and obviously the more rigorous processes We need and the traceability we need for those elements in there Are going to be um what we're focusing on The national processes are being you know developed by the safety and security committees and we coordinate with the technical steering committees And for this for Zephyr, we're basically trying to follow the more of a traditional beam model with Understanding you know the specification the features, you know making sure we've got the documentation the traceability You know the committers are known and information is known about them And then the goal is to improve the evidence That open source development can map So what we're looking at is okay as we understand Um our requirements for a reference system and Zephyr's components in there, you know Do we have um, you know the requirements documented and visible to everyone to provide feedback You know, how is the architecture going to work and then let's test all these steps all the way down And because Zephyr is a very modular framework. Um, we're taking advantage of that to just focus on some initial um elements There was Soon parts of that are stacked have been declared in focus initially and so the apis and then the basically subsets Of some of the devices in the kernel scheduler as well as interrupt handler power management So forth. These are all common elements that most systems need and that'll be the focus of the first You know our first one for 60.508 And then over time we hope to extend out to more and more of Zephyr as resources and interests emerge from our members and from the community as a whole You know some of the things that we've been talking about have been like crypto and the flash and the posix apis these are all elements that will probably be added as resources and Interest emerges in there. We've got this initial base. Um, stabilized So, um, right now we just finished putting out our 2.4 release and we have as part of that There was a project coding guidelines that were made visible We're working on our tooling processes right now And starting to work up the documentation that we're going to be needing for the safety scope And working on the tool evaluation so Engaging the certification authority. So we're working towards making sure we actually have all the evidence necessary For the augmentation and we're working towards having that ready. Um, when we get to the LTS Then we can be able to go through an assessment So if you're interested in learning more about Zephyr, um There's information up on our github repo or check out the website And um, we also have a Slack channel and there's a lot of orientation information out there too So feel free to have a look and subscribe to the mail list and work. Um, all's fine But certainly we welcome anyone's participation and um, obviously patches are welcome So in summary, um I think functional safety standards can coexist with the open source of projects, but we need to become efficient at scale and part of that efficiency at scale is, um Doing some abstraction and summarizing. Okay. Do we actually know all the components that are there? Can we put it our fingertips immediately? Um, and so can we need to look at getting that that part abstracted and getting that part automated And as you can sort of see, um In both Linux and Zephyr and the other projects, we need to make a very strict focus on quality and shrinking down the bugs And you know, we have to focus at that quality at each of those components has to be quality because when they're all put together We have to equality system. So we need to focus at quality at the project level And then we also need to quite frankly manage developer and certification authority expectations You know, we have to have all the fine scopes and we have to focus on our interfaces And then we have to understanding of, you know, the blocks inside those interfaces Um, and if we can get all of that pulled together I think we'll actually start to be in a really good position for doing the analysis and feeling confident that the software we're using in systems And particular for safety critical systems is as safe as we know how to make it With that, I will say thank you and I will be available in the channel for any questions you may have


Hello, everybody, hooded Cobra Commander 788 here, and I'm back with another vintage G.I. Joe toy review. And this time I am looking at the 1983 Jump Jet Pack, and the action figure that came with it, Grand Slam. I'm very excited about doing this review, I've actually wanted to do it for a while, I just needed to make sure I had all of the pieces. And this review is a special request from Plastica from the Yojo.com forum. If you would like me to review a particular G.I. Joe toy, just leave me a comment below this video in YouTube, and if I have the toy, I will review it. If I don't have the toy, if I ever acquire it, I will review it. So let's get started and look at the 1983 Jump Jet Pack and Grand Slam. This is the Jump Jet Pack, and Jump stands for Jet Mobile Propulsion Unit, which does not spell jump, it spells jumpoo. The Jump Jet Pack with Grand Slam is the 1983 version of the toy, but in 1982 the Jump Jet Pack was sold on its own without an action figure. So if you got this toy in 1982, this is what you got. The action figure Grand Slam was also available in 1982 and 1983 with a different toy, the Hal Heavy Artillery Laser. As you can see, there are some differences between the Grand Slam that came with the Hal Laser Cannon and the Grand Slam that came with the Jump Jet Pack. I will take a closer look at the differences between these two versions of Grand Slam a little bit later. So in 1982 you have the Jump Jet Pack, not a very popular toy, not a lot to it. So in 1983 Hasbro re-released the Jump Jet Pack, but they packaged it with this new version of Grand Slam. So the Jump Jet Pack with an action figure, now you've got something interesting. So the Jump was introduced in 1982 and then reintroduced in 1983 with the action figure and after that it was sold until 1985 as a mail away offer in catalogs that you would get with GI Joe vehicles such as this. And you could open it up and right there is an offer for a Jump Jet Pack. It was only three flag points and two dollars. When the Jump was sold in 1982 by itself, it was worth two flag points and when it was sold in 1983 with the action figure, it was still worth two flag points. So you didn't get an extra flag point with the action figure and I think that's kind of a rip off. I'm going to take a closer look at Grand Slam a little bit later so I'm going to set him aside for now. Let's look at the parts of the Jump Jet Pack and the largest part was this launch pad. The launch pad had four legs, they're more like feet. It also included this recharging station and control console and that has a lot of really impressive detail, lots of high tech gadgetry there. And on the bottom of this side of the control console it has these hooks and those hooks just hooked onto this recessed portion here that ran all along the edge of the launch pad and you hook that on there and the control console would stay. There's actually no specific spot along the launch pad to place this control console. You'd really hook it on any side. All four sides would accommodate the hooks on it so you could really put it in any configuration you wanted to. The Jump came with this laser gun and this laser gun, the blueprints say has a range of 100 yards and it has this kind of sight thing on here that's actually a quite narrow and thin piece of plastic. These are often broken off so if you're looking for a Jump Jet Pack and you want to make sure that it's intact, take special note of this sight thing, this kind of attachment on here that breaks off extremely easily. The laser gun fits into the hand of the action figure and it has this C clip here that actually fits over the forearm. So you kind of push the gun into the hand and the clip fits over the arm and it stays on there very securely.  These can be a real pain to find. They were almost always lost on these things. They would fit in this hole in the bottom of the laser gun on one end and the other end which would look identical would fit on the bottom of the Jet Pack like that. And it actually does not stay in very securely. It pops out pretty easily so you can understand how this thing would get lost quite frequently. In fact I've had to do several takes in this video because I keep having the thing pop out on me. That brings us to the Jet Pack itself. And the Jet Pack is loosely based on the real world Bell Textron Rocket Belt and that's a design that's actually been around for a while. The US Army did express an interest in building these things for military use and the program to build Rocket Packs was called the Small Rocket Lift Device or SRLD. So Jet Packs or Rocket Packs are a real thing. They exist in the real world, but they're not very practical for a lot of reasons. For one thing they have a very short flight duration, roughly about 30 seconds. And if you have a flight duration of only 30 seconds you can only spend about 15 seconds going up and you'd better spend the next 15 seconds getting back down because you do not want to be at the top of its arc when this thing runs out of gas. These Jet Packs did not fly very high because of their extremely short flight duration. They didn't get up high enough for the pilot to use a parachute if the device failed. So you're high enough to get injured really badly if you fell, but not high enough to use a parachute. You can see why the military use of Jet Packs would be a little bit problematic. The Jump Jet Pack had some fairly decent detail on both sides and on this side it has a peg and that peg would fit in the hole in the back of the action figure and that would hold the Jet Pack on. So the Jet Pack fit on exactly like any other GI Joe backpack. The legs are adjustable. If you pull them out they can adjust to this notch right there like so or you could just pull them all the way out. Let's look at the features of the Jump Jet Pack and on this side of the control console it has a hole and that hole fit the peg on the Jet Pack. You just put the peg in the hole and it holds the Jet Pack on there for refueling and recharging and it has a slot right there that fit the barrel of the laser gun so you could kind of holster the laser gun and there you go. As far as features goes that's it. The Jump Jet Pack does not do anything else. It has nothing that is spring loaded or battery powered. It's that. There you have it. Let's be very frank about this. The Jump Jet Pack is not really a vehicle. It is an accessory. I mean as far as the Jet Pack itself goes this is it. This is actually what goes on the action figure. This part really isn't necessary. You don't really need a launch pad to launch a Jet Pack so you don't really need this and the console that has the hole for the Jet Pack and the holster for the laser gun you only really use that when you're not using the Jet Pack. It's basically just storage for the toy. And so really what we're talking about here is an accessory with some extra bits. The launch pad did have a foot peg that you could fit in the hole on the bottom of the action figure's feet so you could stand a figure on there. But you don't need it for the actual Jet Pack itself. It's really not very necessary. So you know what this launch pad really is? It's a really big figure stand. You may recall that in my video review of the 1982 FLAC I kind of knocked it a little bit because I thought it was too simple. I think it needed some wheels or some other features to really make the toy be really cool. Well, as far as simple toys go, this Jet Pack is even simpler than the FLAC. But I feel very differently about the Jet Pack than I do the FLAC. I still really love this despite the fact that it really is just an accessory with a completely unnecessary launch pad. I really love this toy. I did have it as a kid and I had it with the Grand Slam with the silver pads like this. And I loved it. And if you think about it, it's a wonderful toy. It allows you to turn a G.I. Joe action figure into Superman. It allows your action figures to fly. Now Grand Slam is an attack aircraft and that is pretty darn cool. Also, as an adult collector, I don't play with these toys anymore, I display them. And the launch pad and the control console actually looks pretty cool as a display. When the Jump Jet Pack was used in the comic book and the cartoon, and probably when you were playing with it as a kid, you would have your figures flying horizontally like this, like Superman. And I'm no physicist, but I don't think that would actually work because if you're flying horizontally and you don't have wings for lift and gravity is pulling you down, then you're just going to arc downward until your face plants in the dirt. To really fly this thing, you would need to be vertical and the pilot would move forward by just leaning forward a little bit, but he would still remain mostly vertical. To illustrate this, check out this video of a real jet pack in flight. Let's take a look at Grand Slam and let's look at Grand Slam's accessories. He came with a helmet that was dark green to match the dark green color on his uniform and a visor that clipped onto the helmet on the holes in the side of the helmet, like that. And this visor was clear plastic. It was very small and these were often lost. You can see how they would get lost very easily. They're tiny and they are clear and if you drop one of these, it's just going to be invisible and it's going to be gone forever. In addition to the helmet and the visor, of course Grand Slam came with the jet pack itself. Let's take a look at the articulation of Grand Slam. He had the typical articulation of 1983 G.I. Joe action figures, which meant that he could turn his head left to right. He could move his arm up at the shoulder about so far and he could swivel it all the way around. He had a hinge at the elbow and he could move his arm at the elbow about 90 degrees and he had a swivel at the bicep so he could swivel his arm all the way around. The figure was held together with a rubber O-ring that looped around the inside that held the figure together and it allowed him to move at the torso a little bit. He could move his legs apart about so far. He could move his leg at the hip about 90 degrees and he could bend at the knee about 90 degrees. Let's take a look at the sculpt of Grand Slam. His face has kind of an older look, sort of a severe expression there and he has brown hair. He has very prominent silver pads on his chest with kind of a checker pattern, also on his thighs and painted pads on his arms. He has black gloves and black boots with these straps here and these are obviously supposed to be boot covers. He was pretty simple on the back. He had silver straps that just continued over to his silver pads on his chest. Now the Grand Slam that came with the Jump Jet Pack was identical to the Grand Slam that came with the HAL laser cannon, also in 1983. But as you can see, the Grand Slam that came with the HAL laser cannon had these red kind of orangeish red pads instead of the silver pads. So when they decided to sell the Jump Jet Pack with Grand Slam, they really just repainted these red portions silver. And I really like this new paint job. I think the silver pads on here just really stand out very well. He looks really cool, it looks very science fiction, but the green gives him sort of an authentic military look even though he has this very futuristic pads on him. These pads on the action figure are apparently to protect him from some kind of adverse effect of the laser that he operates. He did have a laser with the Jump Jet Pack and when he came with the HAL, of course the HAL was a laser cannon. And the only other action figure that had those pads was Flash and he was the laser rifle trooper. So apparently these pads have something to do with protection from lasers. Be very cautious with this silver paint. This silver metallic paint that Hasbro used was not very robust. It would rub off very easily, so just have a care. And if you're going to get a Grand Slam, take careful note of the condition of the silver paint. In the early issues of the GI Joe comic book and in the cartoon, the Jump Jet Pack was not associated with Grand Slam. It was used by Stalker and I really think it looks great on Stalker. It just looks really cool. And before I had the silver pad version of Grand Slam, I always used to display my Jump Jet Pack with Stalker. Let's take a look at the file card. And this is the file card that came with Grand Slam with the Jump Jet Pack. It was printed on the back of the box that the Jump Jet Pack came in. On the other side, there's nothing. It was just the back of the box. And of course that was the second version of Grand Slam's file card. The first version was the version that came with the HAL laser cannon. And this of course, the portrait is different because this is the art that was on the box for the HAL laser cannon. And this was the art that was on the box for the Jump Jet Pack. The text on these two cards are almost identical. In fact, the only difference is that the card with the Jump Jet Pack adds this line Jump Jet Pack, which was missing on his card for the HAL laser cannon. The title up here says Laser Jet Pack Soldier, codenamed Grand Slam. This section says Grand Slam received initial training with conventional artillery and served with a 155mm battery, graduated special weapons school top of class, specialized education, artillery school, advanced tech school, qualified expert M16, M1911A1, HAL Heavy Artillery, and his grade is E5. This section says Grand Slam received initial training with conventional artillery and served with a 155mm battery, majored expert M16, M1911A1, HAL Heavy Artillery Laser, and Jump Jet Pack. This quote down here says he's soft spoken and calm, just a bit shy, intelligent, loves to read escapist fantasy in parentheses, science fiction, and comic books. I kind of like that about Grand Slam. He's a comic book nerd and I can kind of relate to that. That was my review of the 1983 Jump Jet Pack and its pilot Grand Slam and his file card. I hope you enjoyed this video and if you're thinking of getting a Jump Jet Pack, I hope you found this video informative. If you liked this video, go ahead and give it a thumbs up on YouTube and don't forget to subscribe. I've got a lot of great new G.I. Joe toy and comic book reviews coming up and you do not want to miss them. And if there's a vintage G.I. Joe toy that you would like for me to review, go ahead and leave a comment below and I will do my best to get to it. Thanks for watching and I'll catch you all later.


This is Shannon Smith and today I'm going to show you how to prepare and submit a proposal for an EDUCAUS conference. Let's start at the EDUCAUS home page and the first thing you're going to need to do is to find an event for which there's an open call for proposals. So let's float over conferences and events and then go to the EDUCAUS event finder page. On our event finder page, you can search for an event or you can scroll through a list of upcoming events for which you can register or you can have a save the date or reminder email sent for you as well as you can see what events that are still in the open stage of the call for proposals. You'll also be able to see recent events that include the archive proceedings which are a great resource of information on topics important to higher education IT. You can see there are two conferences with open calls for proposals. Let's take a look at the 2013 Mid-Atlantic Regional Conference. EDUCAUS conference web pages will change based upon where we are in the conference cycle. For instance, as we scroll back up to the top, when you look at this call for proposals tab, it will eventually become the conference program schedule tab. For convenience, the submit proposal button is included here on this page so you can click and go straight to the proposal submission form, but in order to adequately prepare your proposal, you need to go to the call for proposals page itself first. Think of the call for proposals page as a blueprint created by the conference program committee to design the conference program. It starts off with a proposal preparation checklist. These five steps will ensure you have the necessary information together in order to submit your proposal and we'll talk about them in more detail in a minute. In addition to encouraging student presentations, the program committee developed a set of program tracks and key topics to help shape the content of the conference. Click on each of the show more links to read how the committee envisions this track and look at some suggested key topics in this area. In addition to defining the desired content through tracks, EDUCAUS helps program committees design creative programs through varying types of session formats. This conference offers six unique session formats from a traditional interactive presentation to a 90-minute workshop. We also constantly look for innovations in conference sessions, so we encourage you to think about suggesting something new. This page also provides a great deal of information on how proposals are reviewed and selected and reminds potential proposers that, if selected, travel and registration costs are the responsibility of the presenter. Let's take a closer look at the proposal preparation checklist and guidelines for proposal submissions. The checklist is a guide to step through in order for you to have collected everything you need to submit the best proposal possible. The first step is to make sure you create or update your EDUCAUS profile, and in particular that you have information in your bio so that reviewers will know a little bit about your background when they review your proposal and score it for possible inclusion in the program. There are a lot of reasons to have an EDUCAUS profile, and we hope you will look at the many tutorial, the power of your EDUCAUS profile, to find out more. But one of the most important reasons is the ability to quickly submit a proposal for one of the many awesome EDUCAUS conferences. The next action item we encourage you to take is to explore steps to writing a successful conference proposal from the EDUCAUS Speaker Concierge. The Speaker Concierge service is designed to help EDUCAUS members navigate the entire conference presentation life cycle. From designing a proposal to writing, delivering and promoting your presentation to leveraging the work you put into your session into other professional development activities such as articles or blog posts. As you can see, the Write a Proposal tab has a more in-depth description of the steps that are outlined in the proposal preparation checklist. This is an easy way to make sure that you've put together the best proposal possible. Going back to the checklist on the CFP page, you will next be advised to review the tracks and key topic descriptions, as well as the session type descriptions, because you'll be asked to select these when you submit your proposal. You are also encouraged to review the submission form by looking at a PDF version of the form. This is so you'll know what to expect when you begin the process of entering your submission. Let's take a quick look at the PDF form. As you review the form, you can see what you will need to write up, and we suggest that you open a Word document and write up your descriptive responses, so you'll have them already typed so that you can easily cut and paste into the text boxes when you're entering your submission. Back at the CFP page is one of the places where you can submit your proposal to go to the live form. If you've done your homework and followed the steps in the checklist, you will be able to go through this very quickly. You can see I'm now logged in, so when I click the Submit Proposal button, I go into the form with my information already filled in for the speaker information. You will be asked to confirm the information that's currently in your EDUCAUSE profile, and then you'll click Next. If you have additional speakers, you will keep adding them, and then you will enter the information that you've carefully thought through and prepared. Once you hit Submit, your work is done for now, as your proposal will be stored for review by the program committee. You will hear whether your proposal has been selected via an email from the EDUCAUSE speaker liaison a few weeks after the call for proposals closes. This mini-tutorial on how to prepare and submit a conference proposal has been brought to you by EDUCAUSE Professional Development. This is Shannon Smith, and be sure to look for other P.D. Byte mini-tutorials to help you get the most out of your relationship with EDUCAUSE.


When you look at the nutrition facts label on soy milk, it says it has the same amount of calcium as cow milk. But is it absorbed as well? Calcium absorption in osteopenic, meaning low bone mineral density, post-menopausal women. An acute comparative study of fortified soy milk to cow's milk. Pretty self-explanatory. What do you think they found? Which works better? Soy milk, calves milk, or the same? And the answer is the same. There is, however, a caveat. When it comes to soy, you've got to shake things up. A prior study found that some of the calcium in soy milk settles to the bottom, so you really only get the amount it says on the label if you give it a good shake before you pour. So when the carton says shake it up, you shouldn't do it just because the carton says so, or do it because I say so. You should do it because the science says so.