Rebooting the Web of Trust (RWOT) is a design workshop whose goal is the production of five or more outputs related to the decentralized digital identity space known as the Web of Trust. Traditionally, the majority of our output has taken the form of white papers that are 5-15 pages long and which discuss rubrics, use cases, specifications, or thought exercises related to the Web of Trust. However, we have also produced commentary on existing specifications and even proof-of-concept code.
So how does it work? What should you expect in your four days at Rebooting the Web of Trust, and how will you get to a paper at the end?
You should not expect to write a paper on the first day of RWOT. Instead, that's the day where we lay the foundation for our work. We'll spend much of the day engaging in group exercises that will get you talking with your colleagues about the topics that interest you.
This day establishes everything that follows. It serves several purposes:
-
It introduces you to your fellows. You'll meet people that you may be working with later in the workshop, and you'll learn what interests them. This helps to put you into a cooperative and collaborative mindset.
-
It introduces you to the topics. Over the course of various "topic" and "weak signal" discussions, you'll learn what's on peoples' minds, and thus what are the most pressing issues for the Web of Trust at the moment.
-
It stokes the fires of your creativity. Over the course of the day, you'll go from your workday mindset where you're focused on fulfilling tasks to a more creative mindset where you're thinking about the future and what may be possible. (At some workshops, such as RWOT2 in New York and RWOT8 in Barcelona, we've further stoked this creativity with purely imaginative exercises about the future; if we roll something like that out, this is why.)
-
It helps us to focus our collaborative power. Over the course of the first day, we'll bring up topics that interest people and also ones that no one was considering much in advance of the event. This is all in service to our final goal: figuring out which topics have sufficient critical mass to actually produce papers over the course of the workshop.
Toward the end of the first day, we'll facilitate people breaking up into the collaborative teams that they'll spend much of the next three days with. Remember that RWOT is all about multiplying our creativity by bringing together ideas from different people; that's what happens when you gather your group.
The ideal RWOT group size is somewhere between three and seven members. With a smaller group size, you'll need people who are entirely committed, both at the workshop and afterward; with a larger group size, you'll have more leeway if some people have more limited availability after the workshop, but you'll need to be more careful about organizing and focusing your time at the workshop.
If you end up in a group with more than seven people, start thinking about whether your group can be split into two or more smaller groups. Usually in a group this size, there will be people with different interests related to your topic. Try and split apart along those lines. If you end up with two groups working on somewhat similar papers, that's OK: you'll have different points of view and will bring different perspectives and thoughts to the topic, which is the purpose of this workshop.
Although less than ideal, we will support groups of two people, provided they are from different, unaligned organizations. This is the bare minimum for producing an RWOT paper: your team must be at least two people. This could be two partners, or it could be one primary author with a collaborator to consider and suggest ideas. However, if you can increase your group to three or more, that's something we will encourage.
The final goal of day one, after all of our setup, is to figure out the focus of your paper enough that you can write an abstract, which should be a one paragraph-or-so overview of the problem your paper is addressing and how you're going to approach it.
If you're having problems figuring out the focus of your paper, you should ask questions like:
- What is the problem we're trying to solve?
- Or: what is the gap we're trying to fill?
- Or: What do we want to say?
- How are we going to approach that topic?
- What major elements (sections) will we touch upon in our paper?
- Is there any research we want to do to for our paper?
At the end of the first day, we ask everyone to upload their abstract to GitHub. This is an important milestone for several reasons. First, it acts as a personal touchstone for you, a goal to help your group on its way to completing a paper; second, it helps the rest of the community know what you're working on, which could lead to new members joining your group or to colleagues offering expertise; and third, it helps our Editor-in-Chief make sure that he knows what all we're producing at this workshop.
After each day of the workshop, we're scheduling a non-sponsored dinner for participants. Some of you may be introverts who need to rest and relax back in your hotel rooms (or wandering the beautiful streets of our locale!), but for the rest of you, we hope you'll attend.
This is one of the activities that occurs "in the margins" of the workshop, a category that also includes our morning breakfasts, our noontime lunches, and our afternoon breaks. It's a time that you can meet with your colleagues and make connections outside your working group, but it's also an opportunity to spontaneously generate ideas that might be useful to your paper, to your fellows' papers, or even to the digital-identity space in general. We've had great questions and thoughts come out of past activities "in the margins" that have influenced the DID specification and more.
Ultimately, any creative work is the product of both perspiration and inspiration. The workshop days will provide you with plenty of opportunity to contribute your perspiration, but look to the margins for your inspiration.
The rest of the workshop days will primarily be spent writing your paper (or your code or whatever). The bulk of that will occur on the second day, but you'll have time on the afternoon of day three and the morning of day four.
There's no right or wrong way to produce your paper. We find that the majority of groups talk for a while, sharing their ideas, while someone records the most notable ones. At some point they tend to move into a collaborative document system like Google Docs and start outlining, then begin recording specific ideas for each section. Finally, they split up the writing tasks and begin to actually put words to paper.
But we've also had groups where a few people talked, then one knocked out a complete paper that the others commented on. We've had groups that broke a topic into several sections, and they each then went off to write their own section and merged them later. We've had groups focused on commenting on an official specification, who essentially wrote a letter to the specification authors as they went. We've had groups sitting around a table who confined all of their conversation to electronic chatrooms, which they engaged in as they wrote.
Our prime suggestion is that you bring a computer for the later days of the workshop, so that you can contribute as much or as little to any electronic environment as you see fit.
Our other prime suggestion is this: make sure that you're getting to the text by the end of day two. Often, we want to keep talking about the great ideas that are occurring to us, and to keep expanding the possibilities of our papers. But groups ultimately need to put a cap on what a paper will cover. If there are contentious topics, put a pin in them and/or give the writing of those topics to the people most emotionally invested.
By the end of day two you'll be about halfway through the time allotted for producing your paper, so try to be into the actual writing phase or you're going to be overwhelmed during the smaller amounts of time available during our last two days.
When you're talking in group, try to make sure that everyone gets time to express their views. Actively listen to your colleagues and give their ideas full consideration. If it's something that they're invested in, do your best to incorporate it as an aspect of the paper. It's best to practice rough consensus, where you address everyone's problems and come to a group agreement to move on.
If you have any problems that you feel aren't being addressed by the group: if someone is steamrolling the consensus, if someone is harassing, or if there are other problems with behavior, let the RWOT staff know and we'll help out.
Day Two breaks a little early, at 4pm, when we've scheduled a "nap time" ahead of dinner. We encourage you to step away from your paper and take advantage of this break, because we've got demos scheduled for the evening, beginning at 8pm.
Demo night is optional. As with the events in the margins, you may opt out if you need some time to yourself. But it's also a great time to see what everyone else is working on and what the rapidly evolving state-of-the-art is in the Web of Trust. So, if you're up to coming back, we encourage you to do so.
The third day of RWOT begins with mandatory fun, an "in the margins" event where we're going to send groups out to enjoy the sights of our locale. This is a new event at RWOT9 (though we've previously had mandatory fun on the evening before the conference). We highly encourage you to sign up and attend.
Obviously, this is an opportunity to generate more inspiration and to network more with your colleagues. But, it's also a time to recharge your batteries. You'll just have spent a grueling day discussing, outlining, and beginning the writing on your paper, potentially followed by a night of demos. Relax and see something totally new, and you'll find that you feel that much more powerful when you return in the afternoon.
Much of the final day of RWOT will be spent on the business of the Web of Trust, talking about the future of RWOT and how we can improve, as well as doing our final report outs.
This is also the day you finish your papers.
For many first-time participants, this is the intimidating part: you produce a final draft of your paper and upload it to the GitHub archive. And, we definitely want you to upload the final state of your paper to GitHub, whatever it might be. To do so, upload an MD version of your paper using a Pull Request (PR). If you've been using Google Docs, you can convert your file to MD using pandoc or certain programs that you can link into your Google Docs files. Please do this even if you are planning to continue work in Google Docs later; the object is to upload your paper's status at the end of the workshop.
We don't expect your final-day commit to be a fully polished paper, and it may not even be fully written. (In fact, as much as we talk about finalizing papers at the workshop, the truth is that a minority have had complete text by the final day of our workshop, and almost none have had complete and polished text.) Think of your paper as being "feature-complete" by the end of the workshop, but not necessarily even an "alpha" release. You definitely should know what the paper is going to say and how it's going to say it. You should have a complete outline of the paper. Most importantly, you should have everyone's collaborative contributions in place, recording all the creativity and inspiration from the workshop. That's the minimum state that we suggest for your paper by "pencils down" on Day Four.
Obviously, the more actual words you've got, the better: because that's much of the hard work and it'll ensure that you've captured all the great ideas at the workshop. But most papers over the years have probably ended up somewhere between a quarter and three quarters written by the end of the workshop, with the groups having a clear idea of what needed to be done to finish them.
(If you can do better, great; and we're hopeful that our expansion of the workshop from three days to four days with RWOT9 may give you the time for that last bit of perspiration, allowing you to finish a rough draft of your work.)
By the end of the third day or so you should have picked a Lead Author as well; definitely you have to know before submitting your paper on day four. The Lead Author is the responsible party after the workshop, organizing any final work needed to bring the paper to completion. They're one part editor, one part cat-herder, and one part nose-to-the-grindstone author, filling in whatever needs to be done.
The Rebooting Web of Trust Editor-in-Chief will keep in touch with the Lead Author, to see how the project is going, while hopefully the Lead Author will stay in touch with the team, coordinating final work and filling in the gaps as needed.
At the end of Day Four of RWOT, we've done weeks' worth of work in four short days. Everyone should take a moment to congratulate themselves and their colleagues on their investment in time and effort to improve our community!
It's easy to work on a paper during four days at an isolated location, surrounded by some of the best brains in the identity field. It's a lot harder to do so in the weeks and months afterward, even if there's a relatively small amount of work still to be done.
Traditionally, somewhere between two-thirds and three-quarters of papers that were considered viable at the end of the conference actually come to completion afterward. Following are some of our top suggestions for ensuring that you can finish up, and so bring your ideas to the awareness of our larger community through a published paper:
-
Limit Your Scope. Some papers fail to complete because they get too big. They might have chosen too big a scope at the workshop, or they might have allowed it to get out of hand afterward. Do your best to avoid this: definitely limit yourself to the topic as you conceived of it at the workshop, but ideally limit yourself to the concepts that were fully explored, outlined, and written there. If you ended the workshop with a section that would elucidate the rest of your paper, but which was never fully discussed, that might be something for the next RWOT, not this one. Often, you can look at what you actually have, and see there's great value there, even if it doesn't include other things you thought about. So, don't be afraid to cut your scope back.
-
Specifically Allocate Tasks. Try to specifically allocate remaining tasks before you leave the workshop. Choose who's going to do any remaining research. Select people to write unfinished sections. Layer tasks atop each other: assign people to write, then someone else to edit, then someone else to polish the whole paper by making the style consistent. This is the sort of thing that happens naturally when we're gathered together at a workshop, but when we separate it becomes easy for these tasks to drop between the cracks.
-
Set Deadlines. Hand-in-hand with that, we suggest setting deadlines for the completion of each task. This will help your team members to prioritize the work, and it'll help the team to keep the project moving forward. Alternatively, you could do something like set a weekly phone (or video) call. This gives you a way to extend the workshop experience back into real life. It also makes sure things keep moving forward, as members can give status reports and assign new tasks until things are completed.
-
Move Onward. Generally, you want to constantly move forward, without getting stuck. One of the biggest gotchas we've seen is papers that stall out because someone had a great idea, said they wanted to write it, but then didn't. Set Deadlines for these expansions, and if they don't occur, move past them.
-
Let People Know If You're Busy. We know: life happens. Sometimes people know they're not going to be able to continue the work after the workshop, and sometimes they find out in the weeks afterward, as real-life asserts itself and as new crises arise. If this happens to you, let your team know. They'll understand, and it'll give them an opportunity to react. If you're a small team, perhaps they'll decided it's time to end the project; if you're a large team, they may be able to assign your tasks to other members. In either case, giving everyone the information lets them make the best choices.
If you decide not to finish your project, don't feel bad about it. It's happens to as many as 1 in 3 projects. Perhaps the topic wasn't strong enough to support a paper; perhaps it was scoped too big; perhaps the team members didn't have the time outside the event; or perhaps there were irreconcilable differences. Do, however, consider if there's a way to share your work to date: perhaps as a truncated paper covering fewer topics; perhaps as a topic paper for a future RWOT; or perhaps just as an updated draft that you upload as a PR and which someone might stumble across in the future.
If you have a completed paper, the Lead Author has one final duty: to make sure that the paper has the consensus of the team members. The Lead will make the final decision about what's in the paper, but they also need to provide that paper to the other members, to give them a final opportunity to either remain a listed author or (if they disagree with the paper) to remove their name.
At this stage, the Lead Author also needs to decide how to list each member: as an author (if they contributed notably to the paper) or as a contributor (if they were less active in the group). The majority of our papers tend to just list authors, but if you feel there is a meaningful split among contributions in your group, please address it in the credits.
Rebooting the Web of Trust uses the AMA guidelines for determining authorship: https://www.amamanualofstyle.com/view/10.1093/jama/9780195176339.001.0001/med-9780195176339-div2-120
All authors should have participated sufficiently in the work to take public responsibility for the content, either all of the work or an important part of it. To take public responsibility, an author must be able to defend the content (all or an important part) and conclusions of the article if publicly challenged. Sufficient participation means that substantial contributions have been made in each of the following areas:
- Conception and design of the work; or acquisition, analysis, or interpretation of the data for the work; and
- Drafting the work or revising it critically for important intellectual content; and
- Approval of the version to be published; and
- Agreement to be accountable for all aspects of the work in ensuring that questions related to the accuracy or integrity of any part of the work are appropriately investigated and resolved.
After you've got a paper ready to go, the Leader Author should upload it as an MD file to our Drafts directory in the event's GitHub (using a PR if you don't have commit permissions) and contact our Editor-in-Chief. He'll do a line edit and submit it back to you as a PR with any comments for more extensive revisions. (We'll usually only offer more extensive thoughts on organization and content if you ask us, but feel free to do so!) After getting your OK, or any revisions, our Editor-in-Chief will then lay your paper out as a PDF, and we'll publish it to the "Final" directory.
All outputs are officially released under open licenses. All papers are released under a CC-BY license, while code is released under an appropriate open source license.
At that point, we'll announce it through our social media, and suggest you do the same.
Congratulations, you've completed an RWOT paper!