├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE.md ├── README.md ├── assets ├── css │ ├── style-dev.less │ └── style.css ├── images │ ├── nav-selected-indicator.svg │ ├── science-fox.svg │ └── science-lab-logo.svg └── javascript │ ├── less.js │ └── script.js ├── code_of_conduct └── index.html ├── contributing └── index.html ├── data_reuse └── index.html ├── dev_template └── index.html ├── diversity ├── README.md ├── diversity-exercise.pdf ├── diversity-roles.pdf └── diversity-tips.pdf ├── github_for_collaboration └── index.html ├── handouts ├── code_of_conduct.md ├── contributing.md ├── data_reuse_plan.md ├── data_reuse_plan_template.md ├── gitHub_for_collaboration.md ├── image-list.html ├── image-list.md ├── img │ ├── Screen Shot 2016-02-03 at 6.31.04 PM.png │ ├── Screen Shot 2016-02-03 at 6.48.44 PM.png │ ├── badges_open_canvas.jpg │ ├── branching-naming.png │ ├── branching-navigate.png │ ├── coc-commit-message.png │ ├── coc-content-additions.png │ ├── coc-content.png │ ├── coc-submitted.png │ ├── feedbackissue.png │ ├── feedbackissue.psd │ ├── fork-button.png │ ├── fork-initializing.png │ ├── fork-page.png │ ├── fork-where.png │ ├── issue-convo.png │ ├── issue-first-comment.png │ ├── issues-labels.png │ ├── issues-search.png │ ├── merge-pull-request.png │ ├── open_canvas.jpg │ ├── open_canvas_details.jpg │ ├── pull-request-ask.png │ ├── pull-request-button.png │ ├── pull-request-comment.png │ ├── pull-request-message.png │ ├── pull-request-selection.png │ ├── pull-request-specifying-branch-01.png │ ├── pull-request-submitted.png │ ├── repo-issues.png │ ├── repo-labels.png │ ├── repo-learning.png │ ├── repo.png │ ├── respondtoissue.png │ └── reviewrequest.png ├── roadmapping.md ├── sprints_events.md ├── user_person_pathways.md └── writing_readmes.md ├── humans.txt ├── index.html ├── open_canvas └── index.html ├── personas_pathways └── index.html ├── roadmap.md ├── roadmapping └── index.html ├── sprints_events └── index.html ├── template └── index.html ├── wow-schedule.md └── writing_readme └── index.html /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | We value the participation of all contributors. To help maintain a welcoming and safe atmosphere we have a [code of conduct](https://mozillascience.org/code-of-conduct) that applies to all our events and online spaces. 2 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | 2 | ##About this Project 3 | 4 | ![](https://media.giphy.com/media/xGIzWN1IdzIhW/giphy.gif) 5 | 6 | ##Getting Set Up 7 | 8 | ##Good First Bugs 9 | 10 | ##Other Resources to Help 11 | 12 | ##A GIF to get you pumped! 13 | 14 | 15 | Thinking of contributing to the Working Open Workshop? That's great! We'd love to have you. 16 | 17 | We value the participation of all contributors. To help maintain a welcoming and safe atmosphere online and at our events we have a code of conduct in place. Make sure you read it. 18 | 19 | The simplest way you can join in with this repo is to: 20 | 21 | * file new issues or make pull requests if you notice problems, typos or bugs 22 | * read the existing issues and contribute your expertise in whatever way makes sense 23 | 24 | If you're unsure of how to get involved, feel free to ask us directly on twitter: @mozillascience. 25 | 26 | We don't yet have a full contributing guide in place for this repo - if you want to help us improve this please do open an issue. 27 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All content of this repo is released under the CC-BY 4.0 license, with attribution required to **the Mozilla Science Lab and contributors**. 2 | 3 | Read the [full-text of the license](https://creativecommons.org/licenses/by/4.0/legalcode), or a [succinct summary](https://creativecommons.org/licenses/by/4.0/). 4 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Welcome to the Working Open Workshop repo! 2 | 3 | [![Gitter](https://badges.gitter.im/mozillascience/working-open-workshop.svg)](https://gitter.im/mozillascience/working-open-workshop?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge) 4 | 5 | This is a repo to collect all materials and resources related to Mozilla Science Lab's Working Open Workshop. You are invited to fork this repo and use our materials-- please let us know what you do with them and how it goes! 6 | 7 | ![wow](https://mozillascience.org/img/working-open-workshop_1600x800.jpg) 8 | 9 | #### What is the Working Open Workshop? 10 | 11 | The Working Open Workshop (or WOW) is **a set of trainings created by Mozilla Science Lab to help up-and-coming leaders of open science and open research projects make the most effective open projects possible, and build active communities of contributors around them.** Specifically, WOW prepares project leads for a strong launch on Collaborate (our platform for open source work) and a wildly successful local and Global Sprints on their projects. (see the below for more about Open Science and Mozilla Sicence Lab). **Read the summary below, or check out our [Workshop Schedule](https://github.com/mozillascience/working-open-workshop/blob/gh-pages/wow-schedule.md) and [Roadmap](https://github.com/mozillascience/working-open-workshop/blob/gh-pages/roadmap.md) to see what we're working on.** 12 | 13 | #### What happens at WOW? 14 | WOW kicks off with a community event/mixer for project leads, potential contributors, citizen scientists, study group participants, local like-minded organizations, and really anyone who’s curious about open research. 15 | 16 | The core WOW experience is 2 days of small, invite-only workshops and work sessions led by Mozilla staff and Fellows. **In these workshops, we’ll cover the essentials of preparing an open project, bringing on contributors, using collaboration tools such as Git and GitHub, and growing an active community around an open project.** 17 | 18 | **Our approach is hands-on, and project-based.** The WOW agenda includes lots of time for participants to make real, meaningful progresss on their projects, and to network and collaborate across projects and disciplines. 19 | 20 | The first WOW will be held in Berlin in early February 2016. 21 | 22 | #### Life After WOW: The Open Leaders Cohort 23 | WOW was designed as a springboard for a group we're calling the Open Leaders Cohort. Members of the Open Leaders Cohort (with the support, advice, and encouragement of Mozilla Science Lab Staff) work together to create projects, share resources, and build active, regional communities of open source practitioners. 24 | 25 | #### How can I get involved with WOW, or contribute to this repo? 26 | Visit MSL's website for information about upcoming WOW events near you! Check out our contribute.md to learn how to help us with WOW materials. 27 | 28 | #### What is "open" research? 29 | Whether you're studying the human genome, black holes, deep sea ecology, medieval music, or alternative energy sources, research is a practice and process of learning, and creating knowledge. Researchers always build on (or transform) an existing understanding of the world. **A researcher working open shares insights or discoveries freely, makes her data available on the web, or makes the details of a new experimental technique or tool public so others can use and reuse it. By working open, she empowers fellow researchers and furthers our collective knowledge... knowledge that can be used to solve problems, save lives, and inspire and amaze us all.** The more data, knowledge, methods, tools and skills made widely and openly available to all, the better. 30 | 31 | #### Oh, by the way, what's Mozilla Science Lab?? 32 | At [Mozilla Science Lab](https://mozillascience.org/) we help scientists and researchers (anyone from students to established researchers to citizen scientists) to work openly and do better research, more research, and make that research more useful by sharing it widely. 33 | 34 | We provide leadership training (such as this Workshop), learning materials and formats (such as [Mozilla Study Groups](http://mozillascience.github.io/studyGroupHandbook/)), platforms for sharing and showcasing open Science projects (such as [MSL Collaborate](https://mozillascience.org/collaborate)), and support for leaders in open science (through the [Mozilla Fellows for Science](https://mozillascience.org/fellows) and the OLC) 35 | 36 | 37 | 38 | 39 | -------------------------------------------------------------------------------- /assets/css/style-dev.less: -------------------------------------------------------------------------------- 1 | // Main colors 2 | @primary-darkest: #2581B7; // Navigation selected state 3 | @primary-dark: #2F8DBC; // Navigation hover state 4 | @primary: #4F99C4; // Section headings and side-bar background 5 | @primary-light: #CAE8FA; // Borders & horizontal rules 6 | @primary-lightest: #E0F3FF; // Background for Example 7 | 8 | // Neutral Text 9 | @text-dark: #273D44; // Dark headings and bold items 10 | @text-medium: rgba(0,0,0,.45); // Body copy (paragraphs, lists, etc.) 11 | 12 | // Links 13 | @link-color: #089970; // Link text 14 | @link-background: #E4F7F0; // Link background when hovered 15 | 16 | // Layout 17 | @aside-width: 230px; // Width of the navigation side bar 18 | @base-font-size: 16px; // Base font size for body copy 19 | 20 | body { 21 | font-family: "Fira Sans","Helvetica Neue", Helvetica, Arial, sans-serif; 22 | font-size: 16px; 23 | padding: 0; 24 | margin: 0; 25 | 26 | * { 27 | padding: 0; 28 | margin: 0; 29 | font-size: inherit; 30 | font-weight: 400; 31 | } 32 | } 33 | 34 | // Basic content & tags 35 | 36 | h1 { 37 | font-size: 32px; 38 | margin: 0 0 35px 0; 39 | color: @text-dark; 40 | position: relative; 41 | line-height: 120%; 42 | } 43 | 44 | h2 { 45 | font-size: 32px; 46 | font-style: italic; 47 | color: @primary-darkest; 48 | margin: 30px 0 20px 0; 49 | } 50 | 51 | h3 { 52 | color: @primary-darkest; 53 | font-size: 20px; 54 | font-weight: 500; 55 | margin: 20px 0 8px 0; 56 | } 57 | 58 | h4 { 59 | color: @text-dark; 60 | margin: 0 0 10px 0; 61 | font-size: 18px; 62 | } 63 | 64 | p, li { 65 | color: @text-medium; 66 | line-height: 160%; 67 | } 68 | 69 | ul, ol { 70 | margin: 0 0 30px 0; 71 | 72 | li { 73 | margin-bottom: 6px; 74 | } 75 | } 76 | 77 | ul { 78 | li { 79 | list-style-type: none; 80 | position: relative; 81 | 82 | &:before { 83 | content: "."; 84 | position: absolute; 85 | left: -15px; 86 | font-weight: 700; 87 | color: inherit; 88 | font-size: 25px; 89 | top: -6px; 90 | } 91 | } 92 | } 93 | 94 | strong { 95 | font-weight: 500; 96 | color: @text-dark; 97 | } 98 | 99 | p { 100 | margin: 0 0 30px 0; 101 | } 102 | 103 | a { 104 | color: @link-color; 105 | transition: background .05s ease-out; 106 | 107 | &:hover { 108 | background: @link-background; 109 | } 110 | } 111 | 112 | 113 | // The main conent wrapper 114 | 115 | article { 116 | max-width: 750px; 117 | min-width: 500px; 118 | position: relative; 119 | padding: 20px 0 40px @aside-width + 65; 120 | margin-right: 55px; 121 | z-index: 1; 122 | } 123 | 124 | .logo { 125 | position: relative; 126 | left: -12px; 127 | width: 175px; 128 | margin-bottom: 10px; 129 | 130 | a:hover { 131 | background: none; 132 | opacity: .8; 133 | } 134 | } 135 | 136 | // Example callout box 137 | 138 | .example { 139 | display: flex; 140 | margin: 35px 0 40px 0; 141 | background: @primary-lightest; 142 | color: @primary-darkest; 143 | padding: 30px 35px; 144 | 145 | .title { 146 | flex: 1; 147 | color: inherit; 148 | 149 | h1 { 150 | width: 100%; 151 | padding: 0 0 2px 0; 152 | font-size: 20px; 153 | font-style: italic; 154 | position: relative; 155 | top: 3px; 156 | color: inherit; 157 | } 158 | } 159 | 160 | .content { 161 | flex: 2; 162 | color: inherit; 163 | position: relative; 164 | padding-left: 22px; 165 | 166 | &:after { 167 | content: ""; 168 | width: 2px; 169 | left: -2px; 170 | top: 4px; 171 | height: ~"calc(100% - 8px)"; 172 | position: absolute; 173 | background: @primary-light; 174 | } 175 | 176 | p:last-child { 177 | margin: 0; 178 | } 179 | 180 | * { 181 | color: inherit; 182 | } 183 | } 184 | 185 | } 186 | 187 | // Summary, audience and duration 188 | .meta-information { 189 | display: flex; 190 | margin: 0 -20px 50px -20px; 191 | 192 | .summary, .details { 193 | margin: 0 20px; 194 | } 195 | 196 | .summary { 197 | flex: 2; 198 | font-size: 18px; 199 | line-height: 145%; 200 | padding: 0 0 0 28px; 201 | font-style: italic; 202 | position: relative; 203 | 204 | &:after { 205 | content: ""; 206 | width: 3px; 207 | height: ~"calc(100% - 10px)"; 208 | left: 0; 209 | top: 5px; 210 | position: absolute; 211 | background: @primary-light; 212 | } 213 | } 214 | 215 | .details { 216 | flex: 1; 217 | 218 | time, .difficulty { 219 | color: @primary-darkest; 220 | font-weight: 700; 221 | margin-bottom: 3px; 222 | display: block; 223 | } 224 | 225 | time:before { 226 | content: "\f017"; 227 | font-family: FontAwesome; 228 | margin-right: 6px; 229 | } 230 | 231 | .difficulty:before { 232 | content: "\f007"; 233 | font-family: FontAwesome; 234 | margin-right: 6px; 235 | } 236 | } 237 | } 238 | 239 | // Format, target audience & materials 240 | .presentation-details { 241 | display: flex; 242 | margin: 0 -20px 35px -20px; 243 | 244 | section { 245 | flex: 1; 246 | margin: 0 20px; 247 | 248 | :last-child { 249 | margin-bottom: 0; 250 | } 251 | 252 | } 253 | } 254 | 255 | // Side-bar with navigation 256 | aside { 257 | background: @primary; 258 | position:fixed; 259 | height: 100vh; 260 | width: @aside-width; 261 | top: 0; 262 | z-index: 2; 263 | 264 | .image { 265 | position: relative; 266 | 267 | img { 268 | width: ~"calc(100% - 20px)"; 269 | } 270 | } 271 | } 272 | 273 | /* Left-side Navigation */ 274 | 275 | nav { 276 | padding: 0; 277 | margin: 15px 0 80px 0; 278 | list-style-type: none; 279 | position: relative; 280 | 281 | a { 282 | display: block; 283 | position: relative; 284 | text-decoration: none; 285 | color: rgba(255,255,255,.7); 286 | padding: 18px 34px; 287 | transition: background .05s ease-out; 288 | 289 | &.selected, &.selected:hover { 290 | background: @primary-darkest; 291 | color: white; 292 | font-weight: 500; 293 | } 294 | 295 | &:hover { 296 | background: @primary-dark; 297 | color: rgba(255,255,255,1); 298 | } 299 | 300 | &:after { 301 | content: ""; 302 | background: ~"url(../assets/images/nav-selected-indicator.svg)"; 303 | background-position: top left; 304 | background-repeat: no-repeat; 305 | background-size: contain; 306 | height: 100%; 307 | width: 20px; 308 | position: absolute; 309 | top: 0; 310 | right: 0; 311 | opacity: 0; 312 | transition: all .075s ease-out; 313 | } 314 | 315 | &.selected { 316 | color: rgba(255,255,255,1); 317 | 318 | &:after { 319 | opacity: 1; 320 | right: -20px; 321 | } 322 | 323 | } 324 | } 325 | } 326 | 327 | /*The steps to complete list*/ 328 | 329 | .steps { 330 | margin: 30px 0 50px 0; 331 | padding: 0 0 0 60px; 332 | 333 | h1 { 334 | font-weight: 500; 335 | font-size: 22px; 336 | margin: 0 0 6px 0; 337 | padding: 0; 338 | color: @primary-darkest; 339 | } 340 | 341 | time { 342 | margin: 0 0 10px 0; 343 | display: block; 344 | color: @text-medium; 345 | font-weight: 500; 346 | 347 | &:before { 348 | content: "\f017"; 349 | font-family: FontAwesome; 350 | margin-right: 6px; 351 | color: rgba(0,0,0,.25); 352 | } 353 | } 354 | 355 | > ol { 356 | padding: 0; 357 | } 358 | 359 | > li { 360 | list-style-type: none; 361 | position: relative; 362 | padding: 0 0 10px 0; 363 | margin: 0 0 40px 0; 364 | 365 | &:not(:last-child):after { 366 | content: ""; 367 | position: absolute; 368 | bottom: -2px; 369 | height: 2px; 370 | background: @primary-light; 371 | width: 35%; 372 | left: ~"calc(22% + 50px)"; 373 | } 374 | 375 | &:last-child { 376 | border: none; 377 | margin: 0; 378 | 379 | :last-child { 380 | margin: 0; 381 | } 382 | } 383 | 384 | &:before { 385 | position: absolute; 386 | left: -60px; 387 | top: -10px; 388 | font-weight: 400; 389 | font-size: 22px; 390 | color: @primary-darkest; 391 | border: solid 2px @primary-light; 392 | height: 43px; 393 | width: 43px; 394 | text-align: center; 395 | box-sizing: border-box; 396 | padding-top: 9px; 397 | border-radius: 0 50% 50% 50%; 398 | } 399 | 400 | // Creates fancy number elements for the Steps-to-Complete list 401 | .make-steps(@counter) when (@counter > 0) { 402 | .make-steps((@counter - 1)); 403 | &:nth-child(@{counter}):before { 404 | content: ~"'"@counter~"'"; 405 | } 406 | } 407 | .make-steps(10); 408 | } 409 | 410 | // Lists within the steps to complete list 411 | ul, ol { 412 | padding: 0; 413 | 414 | li { 415 | list-style-type: none; 416 | 417 | &:before { 418 | display: none; 419 | } 420 | 421 | h2 { 422 | font-size: 15px; 423 | color: @text-dark; 424 | font-style: normal; 425 | font-weight: 500; 426 | margin: 0; 427 | } 428 | } 429 | } 430 | 431 | } 432 | 433 | .glossary { 434 | -webkit-column-count: 2; 435 | -moz-column-count: 2; 436 | column-count: 2; 437 | -webkit-column-gap: 30px; 438 | -moz-column-gap: 30px; 439 | column-gap: 30px; 440 | 441 | margin: 0 0 40px 0; 442 | 443 | .term { 444 | -webkit-column-break-inside: avoid; 445 | column-break-inside: avoid; 446 | display: table; // Weird hack for Firefox 447 | 448 | h3 { 449 | font-weight: 500; 450 | font-size: @base-font-size; 451 | color: @text-dark; 452 | margin: 0; 453 | } 454 | 455 | p { 456 | margin-bottom: 20px; 457 | margin-left: 15px; 458 | } 459 | } 460 | 461 | } 462 | 463 | .resources { 464 | -webkit-column-count: 2; 465 | -moz-column-count: 2; 466 | column-count: 2; 467 | -webkit-column-gap: 30px; 468 | -moz-column-gap: 30px; 469 | column-gap: 30px; 470 | padding-bottom: 30px; 471 | 472 | .resource { 473 | -webkit-column-break-inside: avoid; 474 | break-inside: avoid; 475 | padding-bottom: 25px; 476 | 477 | h4 { 478 | margin: 0; 479 | padding: 0; 480 | font-size: 15px; 481 | font-weight: 500; 482 | line-height: 17px; 483 | } 484 | 485 | p { 486 | margin: 10px 0 0 0; 487 | } 488 | } 489 | } 490 | 491 | // TODO: Print styles 492 | @media print {} 493 | -------------------------------------------------------------------------------- /assets/css/style.css: -------------------------------------------------------------------------------- 1 | /* 2 | Do not make manual changes to this stylesheet. 3 | To make style changes, edit the "style-dev.less" file while previewing the /dev_template/index.html file. 4 | When you're ready, use http://lesscss.org/less-preview/ to compile the .less file into CSS and 5 | replace the CSS below this message with the output. 6 | Note: for background images from the assets folder.. remove "assets" from the url() delaration 7 | This - background: url(../assets/images/nav-selected-indicator.svg); 8 | Becomes - background: url(../images/nav-selected-indicator.svg); 9 | */ 10 | 11 | body { 12 | font-family: "Fira Sans", "Helvetica Neue", Helvetica, Arial, sans-serif; 13 | font-size: 16px; 14 | padding: 0; 15 | margin: 0; 16 | } 17 | body * { 18 | padding: 0; 19 | margin: 0; 20 | font-size: inherit; 21 | font-weight: 400; 22 | } 23 | h1 { 24 | font-size: 32px; 25 | margin: 0 0 35px 0; 26 | color: #273D44; 27 | position: relative; 28 | line-height: 120%; 29 | } 30 | h2 { 31 | font-size: 32px; 32 | font-style: italic; 33 | color: #2581B7; 34 | margin: 30px 0 20px 0; 35 | } 36 | h3 { 37 | color: #2581B7; 38 | font-size: 20px; 39 | font-weight: 500; 40 | margin: 20px 0 8px 0; 41 | } 42 | h4 { 43 | color: #273D44; 44 | margin: 0 0 10px 0; 45 | font-size: 18px; 46 | } 47 | p, 48 | li { 49 | color: rgba(0, 0, 0, 0.45); 50 | line-height: 160%; 51 | } 52 | ul, 53 | ol { 54 | margin: 0 0 30px 0; 55 | } 56 | ul li, 57 | ol li { 58 | margin-bottom: 6px; 59 | } 60 | ul li { 61 | list-style-type: none; 62 | position: relative; 63 | } 64 | ul li:before { 65 | content: "."; 66 | position: absolute; 67 | left: -15px; 68 | font-weight: 700; 69 | color: inherit; 70 | font-size: 25px; 71 | top: -6px; 72 | } 73 | strong { 74 | font-weight: 500; 75 | color: #273D44; 76 | } 77 | p { 78 | margin: 0 0 30px 0; 79 | } 80 | a { 81 | color: #089970; 82 | transition: background 0.05s ease-out; 83 | } 84 | a:hover { 85 | background: #E4F7F0; 86 | } 87 | article { 88 | max-width: 750px; 89 | min-width: 500px; 90 | position: relative; 91 | padding: 20px 0 40px 295px; 92 | margin-right: 55px; 93 | z-index: 1; 94 | } 95 | .logo { 96 | position: relative; 97 | left: -12px; 98 | width: 175px; 99 | margin-bottom: 10px; 100 | } 101 | .logo a:hover { 102 | background: none; 103 | opacity: .8; 104 | } 105 | .example { 106 | display: flex; 107 | margin: 35px 0 40px 0; 108 | background: #E0F3FF; 109 | color: #2581B7; 110 | padding: 30px 35px; 111 | } 112 | .example .title { 113 | flex: 1; 114 | color: inherit; 115 | } 116 | .example .title h1 { 117 | width: 100%; 118 | padding: 0 0 2px 0; 119 | font-size: 20px; 120 | font-style: italic; 121 | position: relative; 122 | top: 3px; 123 | color: inherit; 124 | } 125 | .example .content { 126 | flex: 2; 127 | color: inherit; 128 | position: relative; 129 | padding-left: 22px; 130 | } 131 | .example .content:after { 132 | content: ""; 133 | width: 2px; 134 | left: -2px; 135 | top: 4px; 136 | height: calc(100% - 8px); 137 | position: absolute; 138 | background: #CAE8FA; 139 | } 140 | .example .content p:last-child { 141 | margin: 0; 142 | } 143 | .example .content * { 144 | color: inherit; 145 | } 146 | .meta-information { 147 | display: flex; 148 | margin: 0 -20px 50px -20px; 149 | } 150 | .meta-information .summary, 151 | .meta-information .details { 152 | margin: 0 20px; 153 | } 154 | .meta-information .summary { 155 | flex: 2; 156 | font-size: 18px; 157 | line-height: 145%; 158 | padding: 0 0 0 28px; 159 | font-style: italic; 160 | position: relative; 161 | } 162 | .meta-information .summary:after { 163 | content: ""; 164 | width: 3px; 165 | height: calc(100% - 10px); 166 | left: 0; 167 | top: 5px; 168 | position: absolute; 169 | background: #CAE8FA; 170 | } 171 | .meta-information .details { 172 | flex: 1; 173 | } 174 | .meta-information .details time, 175 | .meta-information .details .difficulty { 176 | color: #2581B7; 177 | font-weight: 700; 178 | margin-bottom: 3px; 179 | display: block; 180 | } 181 | .meta-information .details time:before { 182 | content: "\f017"; 183 | font-family: FontAwesome; 184 | margin-right: 6px; 185 | } 186 | .meta-information .details .difficulty:before { 187 | content: "\f007"; 188 | font-family: FontAwesome; 189 | margin-right: 6px; 190 | } 191 | .presentation-details { 192 | display: flex; 193 | margin: 0 -20px 35px -20px; 194 | } 195 | .presentation-details section { 196 | flex: 1; 197 | margin: 0 20px; 198 | } 199 | .presentation-details section :last-child { 200 | margin-bottom: 0; 201 | } 202 | aside { 203 | background: #4F99C4; 204 | position: fixed; 205 | height: 100vh; 206 | width: 230px; 207 | top: 0; 208 | z-index: 2; 209 | } 210 | aside .image { 211 | position: relative; 212 | } 213 | aside .image img { 214 | width: calc(100% - 20px); 215 | } 216 | /* Left-side Navigation */ 217 | nav { 218 | padding: 0; 219 | margin: 15px 0 80px 0; 220 | list-style-type: none; 221 | position: relative; 222 | } 223 | nav a { 224 | display: block; 225 | position: relative; 226 | text-decoration: none; 227 | color: rgba(255, 255, 255, 0.7); 228 | padding: 18px 34px; 229 | transition: background 0.05s ease-out; 230 | } 231 | nav a.selected, 232 | nav a.selected:hover { 233 | background: #2581B7; 234 | color: white; 235 | font-weight: 500; 236 | } 237 | nav a:hover { 238 | background: #2F8DBC; 239 | color: #ffffff; 240 | } 241 | nav a:after { 242 | content: ""; 243 | background: url(../images/nav-selected-indicator.svg); 244 | background-position: top left; 245 | background-repeat: no-repeat; 246 | background-size: contain; 247 | height: 100%; 248 | width: 20px; 249 | position: absolute; 250 | top: 0; 251 | right: 0; 252 | opacity: 0; 253 | transition: all 0.075s ease-out; 254 | } 255 | nav a.selected { 256 | color: #ffffff; 257 | } 258 | nav a.selected:after { 259 | opacity: 1; 260 | right: -20px; 261 | } 262 | /*The steps to complete list*/ 263 | .steps { 264 | margin: 30px 0 50px 0; 265 | padding: 0 0 0 60px; 266 | } 267 | .steps h1 { 268 | font-weight: 500; 269 | font-size: 22px; 270 | margin: 0 0 6px 0; 271 | padding: 0; 272 | color: #2581B7; 273 | } 274 | .steps time { 275 | margin: 0 0 10px 0; 276 | display: block; 277 | color: rgba(0, 0, 0, 0.45); 278 | font-weight: 500; 279 | } 280 | .steps time:before { 281 | content: "\f017"; 282 | font-family: FontAwesome; 283 | margin-right: 6px; 284 | color: rgba(0, 0, 0, 0.25); 285 | } 286 | .steps > ol { 287 | padding: 0; 288 | } 289 | .steps > li { 290 | list-style-type: none; 291 | position: relative; 292 | padding: 0 0 10px 0; 293 | margin: 0 0 40px 0; 294 | } 295 | .steps > li:not(:last-child):after { 296 | content: ""; 297 | position: absolute; 298 | bottom: -2px; 299 | height: 2px; 300 | background: #CAE8FA; 301 | width: 35%; 302 | left: calc(22% + 50px); 303 | } 304 | .steps > li:last-child { 305 | border: none; 306 | margin: 0; 307 | } 308 | .steps > li:last-child :last-child { 309 | margin: 0; 310 | } 311 | .steps > li:before { 312 | position: absolute; 313 | left: -60px; 314 | top: -10px; 315 | font-weight: 400; 316 | font-size: 22px; 317 | color: #2581B7; 318 | border: solid 2px #CAE8FA; 319 | height: 43px; 320 | width: 43px; 321 | text-align: center; 322 | box-sizing: border-box; 323 | padding-top: 9px; 324 | border-radius: 0 50% 50% 50%; 325 | } 326 | .steps > li:nth-child(1):before { 327 | content: ' 1 '; 328 | } 329 | .steps > li:nth-child(2):before { 330 | content: ' 2 '; 331 | } 332 | .steps > li:nth-child(3):before { 333 | content: ' 3 '; 334 | } 335 | .steps > li:nth-child(4):before { 336 | content: ' 4 '; 337 | } 338 | .steps > li:nth-child(5):before { 339 | content: ' 5 '; 340 | } 341 | .steps > li:nth-child(6):before { 342 | content: ' 6 '; 343 | } 344 | .steps > li:nth-child(7):before { 345 | content: ' 7 '; 346 | } 347 | .steps > li:nth-child(8):before { 348 | content: ' 8 '; 349 | } 350 | .steps > li:nth-child(9):before { 351 | content: ' 9 '; 352 | } 353 | .steps > li:nth-child(10):before { 354 | content: ' 10 '; 355 | } 356 | .steps ul, 357 | .steps ol { 358 | padding: 0; 359 | } 360 | .steps ul li, 361 | .steps ol li { 362 | list-style-type: none; 363 | } 364 | .steps ul li:before, 365 | .steps ol li:before { 366 | display: none; 367 | } 368 | .steps ul li h2, 369 | .steps ol li h2 { 370 | font-size: 15px; 371 | color: #273D44; 372 | font-style: normal; 373 | font-weight: 500; 374 | margin: 0; 375 | } 376 | .glossary { 377 | -webkit-column-count: 2; 378 | -moz-column-count: 2; 379 | column-count: 2; 380 | -webkit-column-gap: 30px; 381 | -moz-column-gap: 30px; 382 | column-gap: 30px; 383 | margin: 0 0 40px 0; 384 | } 385 | .glossary .term { 386 | -webkit-column-break-inside: avoid; 387 | column-break-inside: avoid; 388 | display: table; 389 | } 390 | .glossary .term h3 { 391 | font-weight: 500; 392 | font-size: 16px; 393 | color: #273D44; 394 | margin: 0; 395 | } 396 | .glossary .term p { 397 | margin-bottom: 20px; 398 | margin-left: 15px; 399 | } 400 | .resources { 401 | -webkit-column-count: 2; 402 | -moz-column-count: 2; 403 | column-count: 2; 404 | -webkit-column-gap: 30px; 405 | -moz-column-gap: 30px; 406 | column-gap: 30px; 407 | padding-bottom: 30px; 408 | } 409 | .resources .resource { 410 | -webkit-column-break-inside: avoid; 411 | break-inside: avoid; 412 | padding-bottom: 25px; 413 | } 414 | .resources .resource h4 { 415 | margin: 0; 416 | padding: 0; 417 | font-size: 15px; 418 | font-weight: 500; 419 | line-height: 17px; 420 | } 421 | .resources .resource p { 422 | margin: 10px 0 0 0; 423 | } -------------------------------------------------------------------------------- /assets/images/nav-selected-indicator.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | nav-selected-indicator 5 | Created with Sketch. 6 | 7 | 8 | 9 | 10 | 11 | 12 | -------------------------------------------------------------------------------- /assets/images/science-lab-logo.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 42 | 43 | 44 | 45 | 46 | 47 | 50 | 51 | 52 | 54 | 55 | 56 | 57 | 58 | 59 | 62 | 63 | 64 | 66 | 67 | 68 | 69 | 70 | 71 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 83 | 84 | 85 | 86 | 87 | 88 | 91 | 92 | 93 | 94 | 98 | 101 | 103 | 106 | 108 | 111 | 114 | 115 | 119 | 123 | 124 | 125 | 126 | 130 | 134 | 135 | 137 | 139 | 141 | 146 | 147 | 148 | 149 | 150 | -------------------------------------------------------------------------------- /assets/javascript/script.js: -------------------------------------------------------------------------------- 1 | // Navigation 1.0 ALPHA 2 | // 3 | // * Highlights the appropriate element in the navigation when scrolling through the page 4 | // * Scrolls to appropriate section of the page when the navigation is clicked 5 | 6 | var sections = []; 7 | var articleSections = $(); 8 | var autoscrolling = false; 9 | 10 | $(document).ready(function(){ 11 | 12 | $("nav").on("click","a",function(){ 13 | $(".selected").removeClass("selected"); 14 | $(this).addClass("selected"); 15 | var section = $(this).attr("href"); 16 | 17 | autoscrolling = true; 18 | 19 | $('html, body').animate({ 20 | scrollTop: $(section).offset().top 21 | }, 500, function(){ 22 | autoscrolling = false; 23 | window.location.hash = section; 24 | }); 25 | 26 | return false; 27 | }); 28 | 29 | $("nav a").each(function(i,el){ 30 | var sectionName = $(el).attr("href"); 31 | if(sectionName.length > 0) { 32 | sectionName = sectionName.replace("#","").toLowerCase(); 33 | sections.push(sectionName); 34 | } 35 | }); 36 | 37 | var jam = $("article *[id]"); 38 | $(jam).each(function(i,el){ 39 | var id = $(el).attr("id"); 40 | id = id.replace("#","").toLowerCase(); 41 | if(sections.indexOf(id) > -1) { 42 | articleSections.push(el); 43 | } 44 | }); 45 | 46 | $(window).on("scroll",function(){ 47 | if(autoscrolling == false) { 48 | scroll(); 49 | } 50 | }); 51 | 52 | }); 53 | 54 | function scroll(){ 55 | articleSections.each(function(i,el){ 56 | var windowTop = $(window).scrollTop(); 57 | var offset = $(el).offset(); 58 | var fromTop = offset.top - windowTop; 59 | if(fromTop > 0 && fromTop < 400) { 60 | var id = $(el).attr('id'); 61 | id = id.toLowerCase().replace("#",""); 62 | $("nav .selected").removeClass("selected"); 63 | $("nav a[href=#"+id+"]").addClass("selected"); 64 | } 65 | }); 66 | } 67 | -------------------------------------------------------------------------------- /data_reuse/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Your Data Can Live Forever: How to Plan for Data Reuse 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 30 | 31 |
32 | 37 | 38 |

Your Data Can Live Forever: How to Plan for Data Reuse

39 | 40 |
41 |

42 | This activity is designed to help you understand what someone outside your research 43 | project (or you in 5-10 years) would need to know about your data in order to build 44 | on your work. 45 |

46 |
47 | 48 |

For beginners

49 |
50 |
51 | 52 |
53 |
54 |

Format

55 |

56 | This is a short writing/thinking exercise. Best done with a partner 57 | or small group, but can also be done alone. 58 |

59 |
60 | 61 |
62 |

Target Audience

63 |

64 | Open science project leads, graduate students, and early-career researchers 65 | looking to make their data reusable. 66 |

67 |
68 | 69 |
70 |

Materials

71 | 77 |
78 |
79 | 80 |

Introduction

81 | 82 |

83 | Data reuse saves time and accelerates the pace of scientific discovery. By making your 84 | data open and available to others, you make it possible for future researchers to answer 85 | questions that haven’t yet been asked. Thinking about data reuse in advance and documenting 86 | it, saves you time by helping you plan research processes and workflow early in the 87 | research project. Finally, this documentation makes it easier for you to defend your 88 | research... remember back to second grade when your teacher told you to “show your work”. 89 |

90 | 91 |

92 | When it comes to making your work reusable, “the devil is in the details”. Upon completion 93 | of this exercise, you will have a detailed data reuse plan which you can save as a README 94 | or text file to store with your data files so others can understand and reuse your data. 95 | Extra bonus feature: it provides an outline for the “Methodology” section of any publications 96 | that arise from this data. 97 |

98 | 99 |

Steps to Complete

100 | 101 |
    102 | 103 |
  1. 104 |

    Identify Roles

    105 | 106 |

    107 | Break into groups of 2-5 people. Identify one volunteer to be the "Researcher" 108 | and describe their research data set for this exercise. This person will need 109 | to be fairly familiar with how and why the data was collected. 110 |

    111 | 112 |

    113 | Identify a note taker to record responses to questions from the group about the 114 | data set. 115 |

    116 |
    2. 117 | 118 | 119 |
  2. 120 |

    Interview

    121 | 122 |

    123 | Using the 124 | Data Reuse Plan Template as a guide, members of the group ask questions 125 | of the "Researcher" about her or his data set while the note taker records responses. 126 | The note taker can (and is encouraged) to ask questions too. As you ask questions, 127 | think about how you would (or if you could) respond to a similar question about your 128 | data set. 129 |

    130 |

    131 | If you have time, upon completion of the worksheet, review your responses and make 132 | sure they would be clear to someone viewing your data set for the first time. You are 133 | writing this for someone you have never met. Avoid jargon and abbreviations where 134 | possible. 135 |

    136 |
    3. 137 | 138 | 139 |
  3. 140 |

    Review & Discuss

    141 | 142 |

    143 | Review the following questions and be prepared to share out your responses with 144 | the larger group. 145 |

      146 |
    1. 147 | Which parts of the template were particularly challenging? Why? What research 148 | best practices could you put into place to make it easier? 149 |
      2. 150 |
    2. 151 | If you weren't able to provide some of the information in the worksheet, is 152 | there a way you can get it? If not, is there something you could have done 153 | differently during your research project to collect that information? 154 |
      3. 155 |
    3. 156 | Are there pieces of information missing from this worksheet that would help 157 | someone understand your data and make it easier to reuse? 158 |
      4. 159 |
    160 |

    161 |
    4. 162 | 163 | 164 |
165 | 166 |

Glossary

167 |
168 |
169 |

Open Data

170 |

171 | Data that is made easily and freely available for anyone to access, use, and 172 | share without restrictions, the possible exception being a requirement of 173 | attribution. 174 |

175 |
176 |
177 |

Metadata

178 |

179 | Information that describes, explains, locates, or in some way makes it easier to 180 | find, access, and use a resource (in this case, data). For example, metadata for 181 | a photograph may include the name of the photographer, when and where it was taken, 182 | as well as the type of camera and settings used to take the photograph. 183 |

184 |
185 |
186 |

Licensing

187 |

188 | A license gives explicit permissions for the use of something. This is particularly 189 | important if you want to make your data open as some jurisdictions assign 190 | copyrights to data sets which limit their use. There are several types of 191 | licenses that are in common use for data. You can read more about them 192 | here: 193 | http://www.dcc.ac.uk/resources/how-guides/license-research-data. 194 |

195 |
196 |
197 |

Naming Conventions

198 |

199 | These are a set of predefined rules for the naming and structure of folders, files, 200 | field names, etc. (E.g. All files begin with a date, location and project name.) 201 | Naming conventions help provide context to a data set, as well as make sure a 202 | standard of data collection and management is being followed by all members of a 203 | team. 204 |

205 |
206 |
207 |

Permanent Identifiers

208 |

209 | A permanent identifier (or PID) is a set of numbers and/or characters, frequently 210 | in the form of a URL, that points to the location of a resource. PIDs are set up 211 | in such a way that even though the storage location of the resource may change 212 | over time (e.g. moving data from one university server to another), the PID will 213 | always point to the correct location. DOI is a commonly known type of PID. 214 |

215 |
216 |
217 | 218 |

Follow-up Resources & Materials

219 |

220 | You may find it useful to review this handout early on in the planning stages 221 | of your project to help design the workflows of your project. 222 |

223 |

224 | The following resources are useful for more information documenting your data 225 | and research best practices to make documenting your data easier. 226 |

236 |

237 | 238 | 247 | 248 |
249 | 250 | 251 | -------------------------------------------------------------------------------- /dev_template/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Personas and Pathways for Growing Communities 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 26 | 27 | 28 | 29 | 30 | 43 | 44 |
45 | 50 | 51 |

Personas and Pathways for Growing Communities

52 | 53 |
54 |

55 | This activity is designed to help you identify potential users and contributors, 56 | understand their goals and motivations, help them find a way into your project, 57 | and grow them into strong, committed community members. 58 |

59 |
60 | 61 |

For beginners

62 |
63 |
64 | 65 |
66 |
67 |

Format

68 |

69 | This is a short writing/thinking exercise. Best done with a partner or small group, 70 | but can also be done alone. 71 |

72 |
73 | 74 |
75 |

Target Audience

76 |

77 | Open science project leads and Mozilla Study Group leads seeking to attract and 78 | grow communities of contributors around their projects 79 |

80 |
81 | 82 |
83 |

Materials

84 |
    85 |
  • A timer
    • 86 |
  • Pen & Paper
    • 87 |
  • A way to take notes
    • 88 |
89 |
90 |
91 | 92 |

Introduction

93 | 94 |

95 | Your open project needs users and contributors, but how can you find them, 96 | get them involved, and keep them engaged and active in your community? 97 | One way is by creating and using "personas" and "pathways" to help you. 98 |

99 | 100 |

101 | A “persona” is a tool commonly used in the design world, to help create products 102 | and experiences that work for real world users (aka “user-centered design”). 103 | The persona is an imaginary user, based on real-world observations and understandings 104 | of actual potential or current users. The persona becomes real to the designer, 105 | and is used as a tool to test ideas and experiences (for example, a designer 106 | might ask “Would our user persona, Rodrigo, who is an avid photographer and 107 | technophile but also an introvert who’s protective of his private information, 108 | like feature x of our social media platform?”). 109 |

110 | 111 |

112 | Personas may be composites of several real-world users. The power of the 113 | persona is in its specificity; a good persona feels real, and helps a designer 114 | (or project lead) put their own perspectives aside and empathize with the needs 115 | and motivations of users. 116 |

117 | 118 |
119 |
120 |

Sample Persona

121 |
122 |
123 |

124 | Rashid is a PhD student in astronomy at a university in Southern England. 125 | He’s outgoing and a snappy dresser, favoring skinny jeans and colorful cardigans. 126 | He lives in on-campus housing and after a long day at the lab he usually rushes home 127 | to see his wife and infant son. 128 |

129 |

130 | Rashid took an intro Java programming course long ago, 131 | as an undergrad, but his research now demands Python skills. He attended a two-day 132 | Software Carpentry workshop at his institution. 133 |

134 |
135 |
136 | 137 |

About Pathways

138 | 139 |

140 | Once we have a persona, we can imagine how they might interact with our project. 141 | Let's imagine that this process has a few phases. 142 |

143 | 144 |
    145 |
  1. Discovery - How they first hear about the project or group.
    2. 146 |
  2. First Contact - How they first engage with the project or group, that intial interaction.
    3. 147 |
  3. Participation - How they first participate or contribute.
    4. 148 |
  4. Sustained Participation - How their contribution or involvement can continue.
    5. 149 |
  5. Networked Participation - How they may network within the community.
    6. 150 |
  6. Leadership - How they may take on some additional responsibility on the project, or begin to lead.
    7. 151 |
152 | 153 |

154 | As you create your pathway, ask yourself, what needs to be in place to move Rashid along this pathway? 155 | What are the potential pitfalls for Rashid-- in terms of his skills, his time, his motivations? 156 | Once you have a sense of this story, you might list solutions to any challenges. 157 | Here are a few examples… 158 |

159 | 160 | 166 | 167 |

Steps to Complete

168 | 169 |
    170 | 171 |
  1. 172 |

    Brainstorm

    173 |

    174 | In groups of two, read through the following questions. Take notes! Each person 175 | should answer the question in caps in the time provided. Use a timer to keep 176 | time for each person. 177 |

    178 | 179 |
      180 |
    • 181 |

      Who is the person you most need in your community or on your project?

      182 | 183 |

      184 | Create a persona for this user. Think of the skill set or attributes you want, 185 | but ALSO give them a name, age, a place to live, life circumstances (single, 186 | married? family? student? mid-career?), what they like and don’t like, etc. 187 | This may seem superfluous, but the more real the persona feels to you, the 188 | more useful they’ll be. Have fun with this! 189 |

      190 |
      • 191 | 192 |
    • 193 |

      What are that person's motivations and needs?

      194 | 195 |

      196 | What’s likely to get your persona engaged and excited? What are their personal 197 | goals? Why might they be drawn to your project? What might be the value for 198 | them — what can they get out of it? 199 |

      200 |
      • 201 |
    202 |
    2. 203 | 204 | 205 |
  2. 206 |

    Write

    207 | 208 |

    209 | Create a short description of your persona. See above "Rashid" for an example. 210 |

    211 |
    3. 212 | 213 | 214 |
  3. 215 |

    Plan a Pathway

    216 | 217 |

    218 | Using the structure above, describe a pathway for your persona. What are the steps through 219 | this project? What could stumbling blocks for user? What skills, info, or resources are 220 | missing that they”ll need to better engage with the project? What kinds of things might 221 | drive them away from your project? 222 |

    223 |
    4. 224 | 225 | 226 |
  4. 227 |

    List your Solutions

    228 |

    229 | For each potential stumbling block or difficulty your user might encoutner, list a solution 230 | that you'll work into your design of your grop or project. 231 |

    232 |
    5. 233 |
234 | 235 |

Glossary

236 |
237 |
238 |

First Term

239 |

240 | A fictional user, based on real-world observations of actual or potential users. personas are used 241 | to test and shape the design of a product or experience, so that the final design responsive 242 | and relevant to user needs. 243 |

244 |
245 |
246 |

Another Term

247 |

248 | A fictional user, based on real-world observations of actual or potential users. personas are used 249 | to test and shape the design of a product or experience, so that the final design responsive 250 | and relevant to user needs. 251 |

252 |
253 |
254 | 255 |

Follow-up Resources & Materials

256 | 265 | 266 | 275 | 276 |
277 | 278 | -------------------------------------------------------------------------------- /diversity/README.md: -------------------------------------------------------------------------------- 1 | Welcome to the diversity exercise readme! 2 | 3 | Here are some brief instructions for deploying your own diversity and inclusion exercise. 4 | 5 | 6 | ### Steps 7 | 8 | * print the documents in this folder 9 | * cut the worksheets such that each person will get a `diversity-tips` sheet, and a `diversity-roles` role. 10 | * cut the `diversity-exercise` so that each group of approximately 7 people (1 person per group with a different role) 11 | * distribute the roles and the tips to each participant, ask them to "hide" their role or be discrete 12 | * instruct participants to play their roles while answering the questions in the `diversity-exercise` within their group 13 | * give participants about 10 minutes to complete the exercise within their group 14 | * regroup all participants and groups to go over the roles and the questions and help draw conclusions about how the enforced roles affected group dynamics 15 | 16 | 17 | Thanks! I hope this helps you run your own diversity exercise. -------------------------------------------------------------------------------- /diversity/diversity-exercise.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/diversity/diversity-exercise.pdf -------------------------------------------------------------------------------- /diversity/diversity-roles.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/diversity/diversity-roles.pdf -------------------------------------------------------------------------------- /diversity/diversity-tips.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/diversity/diversity-tips.pdf -------------------------------------------------------------------------------- /github_for_collaboration/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | GitHub for Collaboration On Open Projects 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 30 |
31 | 36 |

GitHub for Collaboration On Open Projects

37 |
38 |

39 | Get comfortable with a Collaborative workflow in the GitHub interface. Practice adding resources to your repo, working with issues and lables, forking and branching, writing commit messages, making and reviewing pull requests, and merging changes. You'll also practice good communication with contributors. 40 |

41 |
42 | 43 |

Intermediate

44 |
45 |
46 |
47 |
48 |

Format

49 |

50 | This is designed as a in-person, facilitated workshop with pairs of learners working together on each other's repositories. It could also be done online. 51 |

52 |
53 |
54 |

Target Audience

55 |

56 | Project Leads and Contributors 57 |

58 |
59 |
60 |

Materials

61 |
    62 |
  • Two people with projects already hosted on GitHub
    • 63 |
  • Computers to work on
    • 64 |
  • An Internet connection to access the GitHub site
    • 65 |
66 |
67 |
68 |

Introduction

69 |

70 | GitHub is a web-based interface for version control, a way of keeping track of changes made to a collection of working documents. GitHub provides a structure and space for communicating about collaborative work on open projects. With bit of set-up, and a good workflow, you can make your project accessible and transparent, and create a respectful and productive working environment for your collaborators.

71 |

This exercise walks you through a workflow for collaboration on open projects, and demonstrates good communication with contributors. You'll need a partner for this exercise. And you'll each play two roles: you'll act as "project lead" on your own project, and "contributor" on your partner's project, as desginated in the steps below.

72 | 73 |

Before you start, provide your partner with a link to your repository. Your repo should look something like this (with your own content, of course). 74 |

75 | 76 | 77 | 78 |

Steps to Complete

79 | 80 | 81 |
    82 | 83 |
  1. 84 |

    Add Files

    85 |

    86 | As project lead: add any new files you've created to your repo (readme.md, roadmap.md, contributing.md). Give the file a name, and the .md extension so you can use markdown for formatting. 87 |

    88 |
    2. 89 | 90 |
  2. 91 |

    Make a Label

    92 |

    93 | As project lead: Make a new label. Click the "Issues" tab, then look for the labels tab, just to the right of the "filter" box. Add a label called "good first bugs."

    94 | 95 |
    3. 96 | 97 |
  3. 98 |

    Make An Issue

    99 |

    100 | As project lead: create an issue in your own repo to document a "good first bug". A good first bug is something simple that a new contributor can work on, to try out contribution and get comfortable with the workflow. It's work that's useful to the project but relatively easy... not so difficult as to be overwhelming or discouraging for someone new to your project. An example of a good first bug for this exercise: fix a typo in the readme, add a badge, add a science fox, etc.

    101 | 102 |
    4. 103 | 104 |
  4. 105 |

    Comment On An Issue

    106 |

    107 | As contributor: Go to your partner's repo, find the "Good First Bug" issue. (Click on the issue button to see all the issues.)

    108 | 109 |

    Make your comment! Introduce yourself and volunteer to work on this issue! 110 |

    111 | 112 |
    5. 113 |
  5. 114 |

    Reply to a Comment

    115 |

    116 | As project lead: In your own repo, go to the issue that's just been commented on. Reply to your new contributor and assign this issue to yourself (you should act as a mentor, and offer to answer any questions). Assigning issues is a good way to track which tasks are underway. 117 |

    118 | 119 |
    6. 120 |
  6. 121 | 122 | 123 |

    Fork and Branch

    124 |

    125 | As contributor: Go to your partner's repo and fork it. The fork button is in the top right corner.

    126 |

    GitHub may take a moment to fork your repo!

    127 | 128 |

    If you have multiple organizations, you may have to designate where the fork will live.

    129 | 130 |

    You'll see that the fork now exists in as part of your own GitHub Account

    131 | 132 |

    Now create a branch in your forked copy.

    133 | 134 |

    Name this branch. You should give it a name that relates to the feature or change you're working on. You'll get confirmation that the branch was created, and see it in your branches dropdown menu.

    135 | 136 |
    7. 137 |
  7. 138 |

    Commit

    139 |

    140 | As contributor: Make a change in this branch, completing the task from the "good first bug issue".

    141 | 142 |

    Write a great commit message! The top line should summarize your changes. Include details in the field below.

    143 | 144 |
    8. 145 |
  8. 146 |

    Make a Pull Request

    147 |

    148 | As contributor: Make a pull request to the orginal (upstream) repo. 149 |

    150 | 151 |

    Write a good message to go along with your request. You may want to link this request to the issue you're solving.

    152 | 153 |

    Make sure you have selected the correct branch where you made your changes for this pull request!

    154 | 155 |

    Here's where you can make that selection!

    156 | 157 |

    You'll see that your pull request has been submitted.

    158 | 159 |
    9. 160 |
  9. 161 | 162 |

    Review

    163 |

    164 | As project lead: Review the pull request and leave a comment thanking the contributor... If you have any questions or comments or discussion points, bring them up here. You could also invite other collaboraters to weigh in. Make use of gifs and emoticons here, to emphasize your appreciation! 165 |

    166 | 167 | 168 |
    10. 169 |
  10. 170 |

    Merge

    171 |

    172 | As project lead: merge the changes from your contributor's pull request into the original repo. 173 |

    174 | 175 |
    11. 176 | 177 |
  11. 178 |

    Close the Issue

    179 |

    180 | As project lead: close the issue with more thanks, gifs, and emojis! 181 |

    182 |
    12. 183 |
184 |

Glossary

185 |
186 |
187 |

repository, or repo

188 |

189 | a collection of documents related to your project, in which you create and save new code or content. 190 |

191 |
192 |
193 |

markdown

194 |

195 | a lightweight way of annotating a document with instructions that tell a web browser how to format and display text. 196 |

197 |
198 |
199 |

version control

200 |

201 | a way of tracking changes to a document or collection of documents. Version control is like a time machine, it can take you back to the moment your document was created, or any other point in time when you or a collaborator saved that document. 202 |

203 |
204 |
205 |

Git

206 |

207 | the command-line software that tracks all changes to a collection of documents 208 |

209 |
210 |
211 |

GitHub

212 |

213 | a service that hosts your repository online and helps you work with contributors. GitHub adds a web-based interface to version control. 214 |

215 |
216 |
217 |

fork

218 |

219 | a copy of a repository that is saved in another user's GitHub account. 220 |

221 |
222 |
223 |

branch

224 |

225 | a copy of a repo that is contained within the orignal repo. Branches are used to work on a project features without altering the original or "master" repo. 226 |

227 |
228 |
229 |

commit

230 |

231 | a saved change to a document in a repository. 232 |

233 |
234 |
235 |

issue

236 |

237 | a message on gitHub that outlines a task that needs to be completed. 238 |

239 |
240 |
241 |

pull request

242 |

243 | a request to add a commit or collection of commits to a repository. 244 |

245 |
246 |
247 |

merge

248 |

249 | the act of incorporating new changes (commits) into a repository. 250 |

251 |
252 |
253 | 262 |
263 | 264 | 265 | 266 | -------------------------------------------------------------------------------- /handouts/code_of_conduct.md: -------------------------------------------------------------------------------- 1 | ### Title: Getting Started with Code of Conducts 2 | 3 | Updated lesson: http://mozillascience.github.io/working-open-workshop/code_of_conduct/ 4 | 5 | ### Learning Goals: 6 | This exercise will walk you through some of the considerations associated with anti-harassment policies, and help you put in place a plan and process for creating a welcoming, inclusive, harrassment-free space. 7 | 8 | ### Target Audience: 9 | Project, event and community leads. 10 | 11 | ### Delivery Format: 12 | In person workshop or online. 13 | 14 | ### Level: 15 | Beginner. 16 | 17 | ### Time to complete: 18 | 1h30m. 19 | 20 | ### What you'll need to start: 21 | Paper, pen (in person); Collaborative document like Etherpad, Google Docs, etc. (online). 22 | 23 | ### Before using this resource you should be familiar with: 24 | n/a 25 | 26 | ### For information on those topics, see: 27 | * Familiarize yourself with [an example of a short, medium and long Code of Conduct](http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy) 28 | * [A list of ways](http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Actions) event attendees can help support anti-harassment policies 29 | * [Contributor Covenant: A Code of Conduct for Open Source Projects](http://contributor-covenant.org/) 30 | 31 | ### Glossary of key terms: 32 | * **Code of conduct**: a set of rules outlining the social norms and rules and responsibilities of, or proper practices for, an individual, party or organization. 33 | * **Elevation / escalation**: the process of flagging an issue or violation to be addressed by the Safety/ Code of Conduct behavior. 34 | * **Harassment**: covers a wide range of behaviours of an offensive nature. It is commonly understood as behaviour which disturbs or upsets, and it is characteristically repetitive. It also includes behaviours that are threatening or disturbing. 35 | * **Discrimination**: treatment or consideration of, or making a distinction in favor of or against, a person or thing based on the group, class, or category to which that person or thing is perceived to belong to rather than on individual merit. types of discrimination include race, color, religion, sex, socioeconomic status, sexual orientation, public assistance status, disability, and age. 36 | * **Enforcement**: the process of moving from elevating an issue to be addressed, to acting on resolving that issue. 37 | * **Inclusion**: a state of being valued, respected and supported. often referred to in terms of an event or community, as in an "inclusive event", meaning one that's welcoming and a respectful environment. 38 | 39 | ### Intro to material: 40 | Code of conducts serve a number of purposes. One is to help establish and clearly communicate the sort of behaviors prioritized in your project or at your event, like being respectful to others, or making sure your event is accessible to others. 41 | 42 | They also serve a functional need, in communicating to participants that should someone happen to violate the code, there’s a process and support from organizers in place. This alone signals that you’re serious about the well-being of your community members, and are taking steps to ensuring the event, project or workshop is an inviting, welcoming, and safe place. 43 | 44 | Think of communities you identify with, be they a set of friends, a group of peers, or an organization you feel a part of in some way. What sort of values or characteristics do you associate with being part of that community? What makes that a community you come back to, and how does it welcome others to participate? 45 | 46 | Whether you’re leading a project or running an event, there are certain community dynamics that can help boost your work and provide a welcoming environment for others to join. This exercise will walk you through how to build a Code of Conduct with your community. 47 | 48 | ### Steps to complete: 49 | 50 | 1. This exercise can be done individually or in a group. Involving other members of your community in the creation of your Code of Conduct helps others feel a shared sense of responsibility. We find the best codes of conduct emerge from real discussion with the community it's aiming to serve, and when it's reflective of the issues they're facing. We encourage you to work with other members of your, if possible. This can be done in person or through circulating an editable document that others can participate in virtually. 51 | 52 | 2. Whether in person in a group or online, start by reflecting on the following questions. Take notes about the answers. Try to give yourself 5-7 minutes per question. 53 | * If working in a group online, share the questions for others to work on with you. One way to get started is to put the questions in an editable document (ie, etherpad, Google Doc, etc), and circulate to a group of community members for their input. Once you've recieved their feedback, move on to the additional steps below. We find this works best when the group of peers represent the diversity of interests and opinions within the community, even if a subsection of a larger group. 54 | * Here's an [etherpad version of the questions](https://public.etherpad-mozilla.org/p/CoC-template-questions) to get you started. 55 | * **What core words would you associate with your community?** These could be values, ideals, or characteristics. Try to keep these to one word answers, if possible. *(Examples: welcoming, safe, inclusive, open, vibrant)* 56 | * If you are working with a group, it might be useful to do this as a silent sticky note exercise. Have participants jot down their ideas, put up on a wall, then see what words overlap. Take note of any common terms, outliers and surprises. 57 | * **What behaviors do you want to encourage? .... and what do you want to discourage?** 58 | * *(Examples: Encourage - active listening, being welcoming, asking questions; Discourage: unwanted physical contact, sexist comments)* 59 | * Note: Be specific enough to be useful here, but try not to linger only on the negative. 60 | * **How does someone elevate an issue, should someone violate the code?** 61 | * Be explicit in these steps, and keep in mind various elevation options. It's OK (and encouraged, even) to have a few options. 62 | * *Examples:* 63 | * *Set up a Safety/Code of Conduct committee, and advertise a bit about each person (general information, bios) including a photo.* 64 | * *Talk to or email Safety/Code of Conduct representatives at an event or email them with your concern. Note that all discussions or correspondences are confidential.* 65 | * *Call or text a Google Voice number, set up specifically for the event.* 66 | * **What consequences are there for violating the code?** 67 | * *(Examples: Asked to leave the event. Removed as a contributor from the project.)* 68 | * **How can you make others feel safe and supported?** 69 | * Code of Conducts aren't only about reporting bad behaviour, and the responsibility for creating a welcoming and safe environment is one that all attendees and participants to share. Take a few minutes to reflect on how you can better support your peers, and model the behaviour you want to see. 70 | * **Who decides what does and does not violate the code? What's an example of how this might be done?** 71 | * Brainstorm some ideas for what the process would look like for participants. This could include response times, how decisions on reported events will be handled, where this will be posted etc. Articulating a clear process for attendess and participants often helps show your commitment to providing a safe experience. 72 | 73 | 3. Using the information and examples listed above, create your own Code of Conduct. You can also remix this example to get started. 74 | 75 | 4. Share the version created with your community for feedback. Make sure your community knows about the Code, those there to help, and feel a shared sense of responsibility to report any behavior that feels off. It helps make sure communities are inclusive, welcoming and human. 76 | 77 | ### Follow-up resources and materials: 78 | * Why You Want a Code of Conduct & How We Made One (Erin Kissane): http://incisive.nu/2014/codes-of-conduct/ 79 | * Codes of Conduct 101 & FAQ (Ashe Dryden): http://www.ashedryden.com/blog/codes-of-conduct-101-faq 80 | * Conference Anti-Harassment Resources (Geek Feminism Wiki): http://geekfeminism.wikia.com/wiki/Conference_anti-harassment 81 | * What Makes a Good Community: http://sarah.thesharps.us/2015/10/06/what-makes-a-good-community/ 82 | 83 | * Examples: 84 | * JSCONF (open source): http://confcodeofconduct.com/ 85 | * Girl Develop It: https://www.girldevelopit.com/code-of-conduct 86 | * OSFeels (long and short version): http://osfeels.com/conduct 87 | * Slidewinder: http://www.slidewinder.io/docs/01_code_of_conduct.html 88 | * Mozilla Science Lab: https://mozillascience.org/code-of-conduct 89 | 90 | 91 | ### Any credits or attribution: 92 | Erin Kissane, Ashe Dryden, Aurelia Moser, Geek Feminism, Ada Initiative (RIP), Kaitlin Thaney, OSFeels Conference 93 | -------------------------------------------------------------------------------- /handouts/contributing.md: -------------------------------------------------------------------------------- 1 | ### Learning Goals 2 | 3 | We will learn how to create and maintain a `CONTRIBUTING.md` for an open source project. 4 | 5 | ### Target Audience 6 | Project, event and community leads. 7 | 8 | ### Delivery Format 9 | In person workshop or online. 10 | 11 | ### Level 12 | Beginner. 13 | 14 | ### Time to Complete: 15 | 30 min. 16 | 17 | ### What you'll need to start: 18 | Paper, pen (in person); Collaborative document like [Etherpad](public.etherpad-mozilla.org/), Google Docs, etc. (online). Download [Mou](http://25.io/mou/) or a markdown viewer so that you can test your file before posting it online. 19 | 20 | ![Mou Markdown View](http://i.imgur.com/byGmNwM.png) 21 | 22 | *Fig 1: side-by-side markdown and rendered contributor file for Atom.io, as viewed in Mou* 23 | 24 | ### Before using this resource you should be familiar with: 25 | 26 | * General structure of a Github repository 27 | * Creating files on Github (editing in browser or on command line) 28 | * Markdown syntax, and (optional) a "markdown editor" like [Mou](http://25.io/mou/) or [Dilliger](http://dillinger.io/) will help you toggle between Markdown sytax and its rendered product 29 | 30 | ### For information on those topics, see: 31 | 32 | * [Contributor Covenant: A Code of Conduct for Open Source Projects](http://contributor-covenant.org/) 33 | * [Suggested project structure outline for Github](https://github.com/CODESIGN2/Project-Structure) 34 | * [Github's guidelines for Markdown syntax](https://guides.github.com/features/mastering-markdown/) 35 | * [Github's Guidlines for setting up CONTRIBUTING.md](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) 36 | * [Working Open Guide: Mechanics of Contributing](http://mozillascience.github.io/leadership-training/03.1-mechanics.html) 37 | 38 | ### Intro to material: 39 | A `CONTRIBUTING.md` file, in your open source repository or site, provides potential project contributors with a short guide to how they can help with your project or study group. It is convention to capitalize the word "contributing" as the file title, and to save it as a resource in markdown (hence the extension `.md`). 40 | 41 | This file is for: 42 | 43 | * *Project owners* - creators and maintainers of the file 44 | * *Project contributors* - users of the file who want to know items they're welcome to tackle, and tact they need in navigating the project/respecting those involved with the project 45 | * *Project consumers* - users who want to build off the project to create their own project 46 | 47 | `CONTRIBUTING.md` should be in your root directory, think of it as a anchor for your project, around which you will build community and keep things tidy. It complements other "all-caps" resources like your `README.md` (which introduces your community to the project, its purpose and basic installation requirements), or your `LICENSE.md` (which provides information on the resuse and permissions associated with the code). 48 | 49 | `CONTRIBUTING.md` should be one of your first priorities in putting an open source/science project online to solicit contributions. If you have yet to define possible avenues of contribution, consider creating a `CONTRIBUTING.md` file with a "check back later, we will populate this soon" message, and the contact information of the project lead for follow-up. 50 | 51 | ![Atom.io](http://i.imgur.com/Xp8TMvT.png) 52 | 53 | *Fig 3: where the Atom.io CONTRIBUTING.md file lives in Github* 54 | 55 | ### Steps to complete: 56 | 57 | This exercise can be done individually or in a group. Try to build a draft of the `CONTRIBUTING.md` file with the core contributors to your project, to help others feel a shared sense of responsibility, and create the best possible guide for encouraging new contributors. It's sometimes best to practice building a markdown file in an offline program like [Mou](http://25.io/mou/) or an online one like [Dilliger](http://dillinger.io/), before you post it online. 58 | 59 | ##### STEP 1: Reflect/Plan 60 | 61 | Start by reflecting on what to include, and what to invite (in terms of contributions) in your `CONTRIBUTING.md`. 62 | 63 | ![Atom Contributing file](http://i.imgur.com/wASaP5P.png) 64 | 65 | *Fig 4: contents of the the Atom.io CONTRIBUTING.md file in Github* 66 | 67 | Consider the following bulleted items: 68 | 69 | * **Welcome contributors to the project** - admit that you are eager for contributions and so happy they found themselves here. 70 | 71 | > :+1::tada: First off, thanks for taking the time to contribute! :tada::+1: 72 | 73 | * **Table of Contents** - if your `CONTRIBUTING.md` file is long, you might consider including a table of contents with links to different headings in your document. In github, each heading is given a URL by default, so you can link to that URL in the appropriate section of the Table of Contents for each heading. Do this in Markdown by wrapping the heading in `[ ]` and following with a parenthetical that includes the URL or header after `#`, like `[Reporting Bugs](#reporting-bugs)`. 74 | 75 | So this in Markdown: 76 | 77 | ``` 78 | [Styleguides](#styleguides) 79 | * [Git Commit Messages](#git-commit-messages) 80 | * [CoffeeScript Styleguide](#coffeescript-styleguide) 81 | * [Specs Styleguide](#specs-styleguide) 82 | * [Documentation Styleguide](#documentation-styleguide) 83 | 84 | ``` 85 | 86 | ...would look like this when rendered: 87 | 88 | [Styleguides](#styleguides) 89 | * [Git Commit Messages](#git-commit-messages) 90 | * [CoffeeScript Styleguide](#coffeescript-styleguide) 91 | * [Specs Styleguide](#specs-styleguide) 92 | * [Documentation Styleguide](#documentation-styleguide) 93 | 94 | * **Short link to important resources** - 95 | * **docs**: handbook/roadmap (you'll learn more about this in the roadmapping session, you can read the outline for that [here](http://mozillascience.github.io/leadership-training/02.2-roadmap.html) and take a look at the [Study Group Handbook](http://mozillascience.github.io/studyGroupHandbook/) as an example) 96 | * **bugs**: issue tracker/bug report tool 97 | * **comms**: forum link, developer list, IRC/email 98 | * **Testing** - how to test the project, where the tests are located in your directories. 99 | * **Environment details** - how to set up your development environment - this might exist in the `README.md` depending on the project. If so, then include a link. 100 | * **How to submit changes** - (Pull Request protocol etcet), you might also include what response they'll get back from the team on submission, or any caveats about the speed of response. 101 | * **How to report a bug** - Bugs are problems in code, in the functionality of an application or in its UI design; you can submit them through "bug trackers" and most projects invite you to do so, so that they may "debug" with more efficiency and the input of a contributor. Take a look at [Atom's example here](https://github.com/atom/atom/blob/master/CONTRIBUTING.md#reporting-bugs) for how to teach people to report bugs to your project 102 | * **Templates** - in this section of your file, you might also want to link to a bug report "template" like this one [here](https://gist.github.com/auremoser/72803ba969d0e61ff070) which contributors can copy and add context to; this will keep your bugs tidy and relevant. 103 | * **First bugs for Contributors** - Sometimes it is helpful to provide some guidelines for the types of bugs contributors should tackle (should they want to fix the bugs and not just submit them), see [Atom's example section here](https://github.com/atom/atom/blob/master/CONTRIBUTING.md#styleguides) 104 | * **How to request an "enhancement"** - enhancements are features that you might like to suggest to a project, but aren't necessarily bugs/problems with the existing code; there is a "label" for enhancments in Github's Issues (where you report bugs), so you can tag issues as "enhancement," and thereby allow contributors to prioritize issues/bugs reported to the project; see [Atom's example section here](https://github.com/atom/atom/blob/master/CONTRIBUTING.md#suggesting-enhancements) 105 | * **Style Guide/Coding conventions** - see [Atom's example here](https://github.com/atom/atom/blob/master/CONTRIBUTING.md#styleguides) 106 | * **Code of Conduct** - (this is linked here, or part of `CONTRIBUTING.md`), you might put it at the start of your `CONTRIBUTING.md` file, as Atom did [here](https://github.com/atom/atom/blob/master/CONTRIBUTING.md#code-of-conduct) just to set the tone for contributions. 107 | * You might extend this section to link to your `LICENSE.md`, or any details for project consumers about how they might use this open source project for their own work, or how they can build on-top of it according to the permissions and license details you have established 108 | * **Recognition model** - provide a pre-emptive "thank you" for contributing, and list any recognition contributors might receive for participating in your project (if applicable) 109 | * **Who is involved?** - [Open Government's CONTRIBUTING.md](https://github.com/opengovernment/opengovernment/blob/master/CONTRIBUTING.md) has as a name/author, and it might be nice to have a more personal/friendly individual to attact to a project and reach out to with questions. You might list the core contributors and their preferred methods of contact here, or link to a [humans.txt](http://humanstxt.org/) file in your root directory (same place as your `CONTRIBUTING.md` file), which lets people know who they are working. Here is an example of a [humans.txt file](http://www.stereosemantics.com/humans.txt). 110 | * **Where can I ask for help?** - a nice extension to the previous section, with links to good comms channels for anyone with questions. 111 | 112 | ##### STEP 2: Create a file named `CONTRIBUTING.md` 113 | 114 | * Start by making the structure of your project clean and welcoming, with folder titles that make sense, if you have several projects, consider adopting a template "project structure" that is consistent across projects, take a look at this [example](https://github.com/CODESIGN2/Project-Structure). 115 | * Author a `CONTRIBUTING.md` file that fits your projects, check out the models below in "Followup Resources", and inorporate the appropriate "To Include" items above. 116 | 117 | #### STEP 3: Make supporting materials 118 | 119 | * Make a LICENSE - make a `LICENSE.md` file that you can reference in your `CONTRIBUTING.md` file, use the following links to generate and copy the appropriate text: https://creativecommons.org/choose/ + http://choosealicense.com/ 120 | * Make a README - make a `README.md` with a brief description of your project and some setup/installation details that you might link to in your `CONTRIBUTING.md` file. 121 | * Create a system for rewarding people 122 | * (optional) Include a [humans.txt](http://humanstxt.org/) file - to give accolades to contributors (store in your root directory just like your `CONTRIBUTING.md`, on deployment, it will be available via your website www.yourwebsite.com/humans.txt) 123 | * (optional) Get a [DOI for a github project](https://guides.github.com/activities/citable-code/), and make [Contributor Badges](https://mozillascience.org/projects/contributorship-badges) as a way to recognize contributors for their particular contributions 124 | * Hat-tip or thank people in your `README.md`, especially if you forked the repo; thank people when they submit issues or requests; be polite. 125 | 126 | ### Glossary Terms: 127 | 128 | * **bugs** : bugs are problems in a project, particularly one in code, they are either problems where a program/project does not perform according to intention, or situations where the users' expectations are not met in a program/project. You can read a more granular definition in [Code Simplicity](http://www.codesimplicity.com/post/what-is-a-bug/) or in [Wikipedia](https://en.wikipedia.org/wiki/Software_bug). 129 | * **bug report tool** : bug reporting tools are applications for processing and organizing bugs submitted by product contributors or users, [Bugzilla](https://bugzilla.mozilla.org/) is Mozilla's bug tracking tool, and [Github has it's own issue system](https://github.com/features) built into every repository, in the "issues" tab of your repo. See [Wikipedia](https://en.wikipedia.org/wiki/Bug_tracking_system) for more details. 130 | 131 | ### Follow-up resources and materials: 132 | 133 | * [Github's Guidlines for setting up CONTRIBUTING.md](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) 134 | * [Working Open Guide: Mechanics of Contributing](http://mozillascience.github.io/leadership-training/03.1-mechanics.html) 135 | * [SlideWinder Contributor Site](http://www.slidewinder.io/docs/) 136 | * [Atom Editor's CONTRIBUTING.md](https://github.com/atom/atom/blob/master/CONTRIBUTING.md) 137 | * [Open Government's CONTRIBUTING.md](https://github.com/opengovernment/opengovernment/blob/master/CONTRIBUTING.md) 138 | 139 | ### Any credits or attribution: 140 | 141 | Hat-tip to the Atom and Open Government developers for their fabulous examples, the creators of Humans.txt, Github and Github's documentation, Mou, Dilliger, Bugzilla, Slidewinder, and the Working Open Guide (linked above). -------------------------------------------------------------------------------- /handouts/data_reuse_plan.md: -------------------------------------------------------------------------------- 1 | ##Your Data Can Live Forever: How to Promote Data Reuse 2 | ####Learning Goals: 3 | This activity is designed to help you understand what someone outside your research project (or you in 5-10 years) would need to know about your data in order to build on your work. 4 | ####Target Audience: 5 | Graduate students, early-career researchers, project leads 6 | ####Delivery Format: 7 | in-person workshop 8 | ####Level: Beginner 9 | ####Time to complete: 10 | 45 mins in-person w/ add’l time to refine post-workshop 11 | ####What you'll need to start: 12 | pen/pencil or text editor, [Data Reuse Plan Template] (../Handouts/DataReusePlanWorksheet.md), a data set with which you are familiar 13 | ####Before using this resource you should be familiar with: Not applicable 14 | ####For information on those topics, see: Not applicable 15 | ####Glossary of key terms: 16 | **Open data:** Data that is made easily and freely available for anyone to access, use, and share without restrictions, the possible exception being a requirement of attribution. 17 | **Metadata:** Information that describes, explains, locates, or in some way makes it easier to find, access, and use a resource (in this case, data). For example, metadata for a photograph may include the name of the photographer, when and where it was taken, as well as the type of camera and settings used to take the photograph. 18 | **Licensing:** A license gives explicit permissions for the use of something. This is particularly important if you want to make your data open as some jurisdictions assign copyrights to data sets which limit their use. There are several types of licenses that are in common use for data. You can read more about them here: [http://www.dcc.ac.uk/resources/how-guides/license-research-data] (http://www.dcc.ac.uk/resources/how-guides/license-research-data) 19 | **Naming conventions:** These are a set of predefined rules for the naming and structure of folders, files, field names, etc. (e.g. all files begin with a date, location and project name.) Naming conventions help provide context to a data set, as well as make sure a standard of data collection and management is being followed by all members of a team. 20 | **Permanent Identifiers:** A permanent identifier (or PID) is a set of numbers and/or characters, frequently in the form of a URL, that points to the location of a resource. PIDs are set up in such a way that even though the storage location of the resource may change over time (e.g. moving data from one university server to another), the PID will always point to the correct location. DOI is a commonly known type of PID. 21 | ####Intro to material: 22 | Data reuse saves time and accelerates the pace of scientific discovery. By making your data open and available to others, you make it possible for future researchers to answer questions that haven’t yet been asked. Thinking about data reuse in advance and documenting it, saves you time by helping you plan research processes and workflow early in the research project. Finally, this documentation makes it easier for you to defend your research... remember back in second grade when your teacher told you to “show your work”. 23 | 24 | When it comes to making your work reusable, “the devil is in the details”. Upon completion of this exercise, you will have a detailed data reuse plan which you can save as a README or text file to store with your data files so others can understand and reuse your data. Extra bonus feature: it provides an outline for the “Methodology” section of any publications that arise from this data. 25 | ####Steps to complete: 26 | 1. Break into evenly distributed groups of 2-5 people. *(2 mins)* 27 | 2. Identify one volunteer to be the “Researcher” and describe their research data for this exercise. This person will need to be fairly familiar with how and why the data was collected. *(2 mins)* 28 | 3. Identify a note taker to record responses to questions from the group about the data set. *(1 min)* 29 | 4. Using the Data Reuse Plan worksheet as a guide, members of the group ask questions of the “Researcher” about her or his data set while the note taker records responses. (The note taker can ask questions, too!) As you ask questions, think about how you would (if you could) respond to a similar question for your data set. *(30-40 mins)* 30 | 5. If you have time, upon completion of the worksheet, review your responses and make sure they would be clear to someone viewing your data set for the first time. You are writing this for someone you’ve never met. Avoid jargon and abbreviations where possible. 31 | 6. Review the questions below and be prepared to share out your responses with the larger group. 32 | 33 | #####Questions to Keep in Mind: 34 | If you don’t have some of the applicable information asked for in the worksheet, is there a way you can get it? If not, is there something you could have done differently during your research project to collect that information? 35 | Which parts of the worksheet are particularly challenging? Why? What research best practices could be put into place to make it easier? 36 | Are there pieces of information missing from this worksheet that would help someone understand your data with an intent to reuse it? 37 | 38 | ####Follow-up resources and materials: 39 | * [Metadata Guide](http://www.ands.org.au/guides/metadata-working.html) from Australian National Data Service (ANDS) 40 | * [Metadata Directory](http://rd-alliance.github.io/metadata-directory/) from Research Data Alliance 41 | * [Best Practices for Data Management](https://www.dataone.org/sites/all/documents/DataONE_BP_Primer_020212.pdf) from DataONE 42 | * [Challenges to Open Data and How to Respond] (../Handouts/ODChallengesQI.md) 43 | 44 | ####Credits and attribution: 45 | Metadata definition adapted from “Understanding Metadata” published by NISO Press (2004): [http://www.niso.org/publications/press/UnderstandingMetadata.pdf] (http://www.niso.org/publications/press/UnderstandingMetadata.pdf) 46 | -------------------------------------------------------------------------------- /handouts/data_reuse_plan_template.md: -------------------------------------------------------------------------------- 1 | ## **Data Reuse Planning Template** 2 | 3 | Create a text file including information provided below, as appropriate. Save this file as " **DataReusePlan.txt**" and save in top-level folder of your data set for use by future researchers wanting to reuse your data. 4 | 5 | ## | **What** | 6 | 7 | **Description (abstract):** What is your project about? What is the goal? Why are you doing it? How does this data relate to your project? 8 | 9 | **Title:** What do you want to call your data set? 10 | 11 | e.g. "Data from: ", "Soil moisture data in Namibian Delta 1982" 12 | 13 | **Permanent Identifier:** A way for folks to find your data. Do you have a DOI or other permanent identifier? 14 | 15 | e.g. https://dx.doi.org/10.6084/m9.figshare.2061996.v1 16 | 17 | **Data Source:** If you included someone else's data in your data set, provide information on where it came from. Just like articles, if you use it, cite it. It is preferable to include a permanent identifier like a DOI. 18 | 19 | e.g. Forstmann BU, et al. (2014) Data from: Multi-modal ultra-high resolution structural 7-Tesla 20 | MRI data repository. Dryad Digital Repository. (http://dx.doi.org/10.5061/dryad.fb41s) 21 | 22 | **Subject:** In what discipline or subject area is your project? 23 | 24 | e.g. Neurological biochemistry, applied ecology, etc. 25 | 26 | **Related publication:** Have you published an article, thesis or some other publication based on this data? Include a full citation and permanent identifier, if available. 27 | 28 | e.g. Forstmann BU, et al. (2014) Multi-modal ultra-high resolution structural 7-Tesla MRI data repository. 29 | Scientific Data 1:140050. (http://dx.doi.org/10.1038/sdata.2014.50) 30 | 31 | ## | **Who** | 32 | 33 | **Data Collector:** Person/organization responsible for collecting data 34 | 35 | e.g. Roberts Lab, University of Washington; Phoebe Marshwana, PhD, Michigan State University 36 | 37 | **Funder Information** : Is this project sponsored by a funding agency? If so, include name of the funding agency, grant number, and principal investigator name/s & affiliations. 38 | 39 | e.g. Funded by European Commission's Framework 7 Program under Grant No. FP7-ICT-2016- 224495. 40 | PI: Dr. Carol Magnusson, Oxford University) 41 | 42 | **Collaborators:** Are there any collaborators on this project? Provide names and affiliations. 43 | 44 | e.g. Dr. Adorja Bilka, Rensselaer Polytechnic Institute 45 | 46 | **Contact person:** Who should someone contact for additional information about the data set? Include affiliation and contact information such as phone number, email, and/or physical address. 47 | 48 | e.g. Dr. Alain Benziger, Swiss Tropical and Public Health Institute, Socinstrasse 57, 4051 Basel, 49 | Switzerland; abenziger@swisstph.ch 50 | 51 | ## | **Where** | 52 | 53 | **Location:** Where was the data collected? One place? Multiple places? Use geographic coordinates if appropriate. 54 | 55 | e.g. Skukuza, Swaziland; N -24.9916 degrees, W 31.5874 degrees; Multiple sites along Congo 56 | River Delta 57 | 58 | **Place of publication:** Where is the data made publicly available? Include URL. 59 | 60 | e.g. Penn State University Scholarsphere: https://scholarsphere.psu.edu/ 61 | 62 | ## | **When** | 63 | 64 | **Temporal Coverage:** When was the data collected? On a specific date? Specific time? Over a range of dates? Use the international standard date format (YYYY-MM-DD hh:mm.ss) and try to be as specific as possible. 65 | 66 | e.g. 2015-07-01 to 2015-12-31; 2000 - 2010 67 | 68 | **Publication Date:** When was the data made available in the place of publication (above)? Again, use the international standard date format. 69 | 70 | e.g. 2016-01-15 71 | 72 | ## | **How** | 73 | 74 | **Data collection process:** What instruments were used to collect the data? how frequently were the data collected? how were data collection sites selected? if there was a sample population, how was it selected? 75 | 76 | e.g. Minimum and maximum observed temperature for each day was calculated at morning 77 | high tide using CoolRead thermometers calibrated using the XYZ method. 78 | 79 | **Data processing:** How did you clean the data? how are missing or null values handled? did you write code for processing the data and where can it be found? 80 | 81 | e.g. Differences in site mortality were determined through survdiff tests performed using X software 82 | version 2.10.3. Comparisons with a p-value less than 0.05 (P<0.05) were considered different. Raw data 83 | and scripts used in analysis are available in a GitHub repository: https:github.com/omeara/oysters/ 84 | 85 | **File index:** A listing of folders and files included in the data set. Explain what files will be found in each folder and naming conventions used. Additional files could include any questionnaires or other survey instruments used to collect the data. Be sure to nclude codebooks and data dictionaries or similar README files. 86 | 87 | See http://www.fs.usda.gov/rds/archive/products/RDS-2013-0013/_fileindex_RDS-2013-0013.html 88 | 89 | **File format/s:** What type/s of files are these? Are there multiple formats? What software is needed to use the file/s? 90 | 91 | Avoid proprietary formats if possible! Most data can be reformatted to be communicated in text-based forms. 92 | 93 | e.g. Data files are in text files in the comma-separated-values format and can be opened with any text editor. 94 | 95 | **Standard Metadata:** Increasingly, scientific fields are moving towards standard metadata formats (data.json, data.xml, etc) to pull all the information in the Data Reuse plan together in a machine readable format. Machine readable metadata enables cataloging of datasets on sites like Data.gov and allows other to ask questions and access your datasets using code. For example, open US govenment data online is required to expose a data.json in the landing page html to be listed on Data.gov, thereby facilitating data discovery. Because not all researchers who are mandated to actually include data.json files, Data.gov is incomplete, and simple questions like "what is the total volume of data generated by US federally funded scientists?" are unanswerable. 96 | 97 | What is the metadata standard in your field? Not sure? That's normal. Your field may not have a universal standard yet. Check out the [Research Data Alliance recommendations](https://www.rd-alliance.org/recommendations-and-outputs/all-recommendations-and-outputs) and consider getting involved in the creation of metadata standards in your field! 98 | 99 | ## Note about codebooks and data dictionaries: 100 | 101 | The use of additional documentation formats such as codebooks and data dictionaries in conjunction with your DataReusePlan.txt and other data set files makes your data infinitely more reusable and provide assistance with managing your data and your research process as a whole. Like your Data Reuse Plan, these file are stored with the rest of your data files, usually in a top-level folder. 102 | 103 | A **data dictionary** (sometimes used interchangeably with " **codebook**") is another text file for defining field names and values. The file includes a list of all field names in the data set and a description of each such as: units of measurement, formulas used for calculation, abbreviations, value ranges, as well as the relationship of fields to one another. 104 | 105 | Example of a data dictionary: http://www.utexas.edu/cola/redcap/_files/data_dictionary_example.jpg 106 | 107 | For more information see: "Best Practices for Data Dictionary Definitions and Usage" by the Northwest Environmental Data Network (http://www.pnamp.org/sites/default/files/best_practices_for_data_dictionary_definitions_and_usage_version_1.1_2006-11-14.pdf). 108 | -------------------------------------------------------------------------------- /handouts/gitHub_for_collaboration.md: -------------------------------------------------------------------------------- 1 | 2 | **Title:** A Collaborative Workflow for Open Projects in GitHub 3 | 4 | **Learning Goals:** 5 | Get comfortable with a Collaborative workflow in the GitHub interface. Practice adding resources to your repo, working with issues and lables, forking and branching, writing commit messages, making and reviewing pull requests, and merging changes. You'll also practice good communication with contributors. 6 | 7 | **Target Audience** Project Leads and Contributors 8 | 9 | **Delivery Format:** In-person, facilitated workshop with pairs of learners working together on each other's repositories. 10 | 11 | **Level:** Intermediate 12 | 13 | **Time to complete:** 45 mins 14 | 15 | **What you'll need to start:** two people with projects already hosted on GitHub, computers to work on, an Internet connection to access the GitHub site 16 | 17 | Before using this resource you should be familiar with: the basics of version control, setting up a GitHub repo, markdown basics. 18 | 19 | **For information on those topics, see:** Short Presentation: [GitHub for Collaboration and Enjoyment](https://docs.google.com/presentation/d/17R2EqTq7GM4RyvdG7bNK_g77r50X5-dufzgc5tBmihs/edit?usp=sharing) 20 | 21 | **Glossary of key terms:** 22 | repository or repo: a collection of documents where you are working and saving your work 23 | 24 | markdown: a lightweight way of annotating a document with instructions that tell a web browser how to format and display text 25 | 26 | version control: a way of tracking changes to a document or collection of documents. Version control is like a time machine, it can take you back to the moment your document was created, or any other point in time when you or a collaborator saved that document. 27 | 28 | Git : the command-line software that tracks all changes to a collection of documents 29 | 30 | GitHub: a service that hosts your repository online and helps you work with contributors. GitHub adds a web-based interface to version control. 31 | 32 | fork: a copy of a repository that is saved in another user's GitHub account 33 | 34 | branch: a copy of a repo that is contained within the orignal repo. branches are used to work on a project features without altering the original or "master" repo. 35 | 36 | commit: a saved change to a document in a repository 37 | 38 | issue: a message on gitHub that outlines a task that needs to be completed 39 | 40 | pull request: a request to add a commit or collection of commits to a repository. 41 | 42 | merge: the act of incorporating new changes into a repository 43 | 44 | **Intro to material:** 45 | The magic of GitHub is providing a structure and space for communicating about those changes, making decisions, assigning tasks. With some good set-up, you can making your project accessible and transparent, and create a respectful and productive working environment for your collaborators. 46 | 47 | This exercise walks you through a workflow for collaboration on open projects and demonstrates good communication with contributors. 48 | 49 | *Before you start, provide your partner with a link to your repository.* 50 | 51 | 1. As project lead: add any new files you've created to your repo (readme.md, roadmap.md, contributing.md). Give the file a name, and the .md extension so you can use markdown for formatting. Add your content and click commit at the bottom. 52 | 53 | 2. As project lead. Make a new label. Where to do this: click the "Issues" tab, then look for the labels tab, just to the right of the "filter" box. Add a label called "good first bugs" 54 | 55 | 3. As project lead: create an issue in your own repo to document a "good first bug". A good first bug is something simple that a new contributor can work on, to give contribution and this way of working a try. It's work that's useful to the project but relatively easy, not so difficult as to be overwhelming or discouraging for someone new to your project. A good first bug is as much an opportunity to learn the workflow as it is to make changes to the project. An example of a good first bug for this exercise: fix a typo in the readme, add a badge, add a science fox, etc. 56 | 57 | 4. As contributor: Go to your partner's repo, and comment on the new "Good First Bug" issue that they've posted... introduce yourself and volunteer to work on this issue! In your own repo, go to the issue that's just been commented on. 58 | 59 | 5. As project lead: Reply to your new contributor and assign this issue to yourself (you should act as a mentor, and offer to anser any questions). Assinging issues is a good way to track which tasks are underway and have help. 60 | 61 | 6. As contributor: Go to your partner's repo and fork it. Then create a branch in your forked copy. Name this branch. 62 | 63 | 7. As contributor: Make a change in this branch, and commit it. Write a great commit message! The top line should summarize your changes. Include details in the field below. 64 | 65 | 8. As contributor: Make a pull request to the orginal (upstream) repo. 66 | 67 | 9. As Project Lead: Review the pull request and leave a comment thanking the contributor... Make use of gifs and emoticons here, to emphasize your appreciation! 68 | 69 | 10. As project lead: merge the changes 70 | 71 | 11. As project lead: close the issue with thanks, gifs, and emojis! 72 | 73 | **Any credits or attribution:** 74 | Joey Lee, Abby Cabunoc, Zannah Marsh, and Arliss Collins contributed to the creation of this resource. 75 | 76 | -------------------------------------------------------------------------------- /handouts/image-list.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | -------------------------------------------------------------------------------- /handouts/image-list.md: -------------------------------------------------------------------------------- 1 | ![](img/badges_open_canvas.jpg) 2 | ![](img/branching-naming.png) 3 | ![](img/branching-navigate.png) 4 | ![](img/coc-commit-message.png) 5 | ![](img/coc-content-additions.png) 6 | ![](img/coc-content.png) 7 | ![](img/coc-submitted.png) 8 | ![](img/fork-initializing.png) 9 | ![](img/fork-page.png) 10 | ![](img/fork-where.png) 11 | ![](img/issue-convo.png) 12 | ![](img/issue-first-comment.png) 13 | ![](img/issues-labels.png) 14 | ![](img/issues-search.png) 15 | ![](img/merge-pull-request.png) 16 | ![](img/open_canvas_details.jpg) 17 | ![](img/open_canvas.jpg) 18 | ![](img/pull-request-ask.png) 19 | ![](img/pull-request-button.png) 20 | ![](img/pull-request-comment.png) 21 | ![](img/pull-request-message.png) 22 | ![](img/pull-request-selection.png) 23 | ![](img/pull-request-specifying-branch-01.png) 24 | ![](img/pull-request-submitted.png) 25 | ![](img/repo-issues.png) 26 | ![](img/repo-labels.png) 27 | ![](img/repo-learning.png) 28 | ![](img/repo.png) 29 | 30 | 31 | -------------------------------------------------------------------------------- /handouts/img/Screen Shot 2016-02-03 at 6.31.04 PM.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/Screen Shot 2016-02-03 at 6.31.04 PM.png -------------------------------------------------------------------------------- /handouts/img/Screen Shot 2016-02-03 at 6.48.44 PM.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/Screen Shot 2016-02-03 at 6.48.44 PM.png -------------------------------------------------------------------------------- /handouts/img/badges_open_canvas.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/badges_open_canvas.jpg -------------------------------------------------------------------------------- /handouts/img/branching-naming.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/branching-naming.png -------------------------------------------------------------------------------- /handouts/img/branching-navigate.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/branching-navigate.png -------------------------------------------------------------------------------- /handouts/img/coc-commit-message.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/coc-commit-message.png -------------------------------------------------------------------------------- /handouts/img/coc-content-additions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/coc-content-additions.png -------------------------------------------------------------------------------- /handouts/img/coc-content.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/coc-content.png -------------------------------------------------------------------------------- /handouts/img/coc-submitted.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/coc-submitted.png -------------------------------------------------------------------------------- /handouts/img/feedbackissue.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/feedbackissue.png -------------------------------------------------------------------------------- /handouts/img/feedbackissue.psd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/feedbackissue.psd -------------------------------------------------------------------------------- /handouts/img/fork-button.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/fork-button.png -------------------------------------------------------------------------------- /handouts/img/fork-initializing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/fork-initializing.png -------------------------------------------------------------------------------- /handouts/img/fork-page.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/fork-page.png -------------------------------------------------------------------------------- /handouts/img/fork-where.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/fork-where.png -------------------------------------------------------------------------------- /handouts/img/issue-convo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/issue-convo.png -------------------------------------------------------------------------------- /handouts/img/issue-first-comment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/issue-first-comment.png -------------------------------------------------------------------------------- /handouts/img/issues-labels.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/issues-labels.png -------------------------------------------------------------------------------- /handouts/img/issues-search.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/issues-search.png -------------------------------------------------------------------------------- /handouts/img/merge-pull-request.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/merge-pull-request.png -------------------------------------------------------------------------------- /handouts/img/open_canvas.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/open_canvas.jpg -------------------------------------------------------------------------------- /handouts/img/open_canvas_details.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/open_canvas_details.jpg -------------------------------------------------------------------------------- /handouts/img/pull-request-ask.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/pull-request-ask.png -------------------------------------------------------------------------------- /handouts/img/pull-request-button.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/pull-request-button.png -------------------------------------------------------------------------------- /handouts/img/pull-request-comment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/pull-request-comment.png -------------------------------------------------------------------------------- /handouts/img/pull-request-message.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/pull-request-message.png -------------------------------------------------------------------------------- /handouts/img/pull-request-selection.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/pull-request-selection.png -------------------------------------------------------------------------------- /handouts/img/pull-request-specifying-branch-01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/pull-request-specifying-branch-01.png -------------------------------------------------------------------------------- /handouts/img/pull-request-submitted.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/pull-request-submitted.png -------------------------------------------------------------------------------- /handouts/img/repo-issues.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/repo-issues.png -------------------------------------------------------------------------------- /handouts/img/repo-labels.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/repo-labels.png -------------------------------------------------------------------------------- /handouts/img/repo-learning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/repo-learning.png -------------------------------------------------------------------------------- /handouts/img/repo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/repo.png -------------------------------------------------------------------------------- /handouts/img/respondtoissue.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/respondtoissue.png -------------------------------------------------------------------------------- /handouts/img/reviewrequest.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mozillascience/working-open-workshop/8931bf19bedb99166b931f82dbd2fba815dc6fe1/handouts/img/reviewrequest.png -------------------------------------------------------------------------------- /handouts/roadmapping.md: -------------------------------------------------------------------------------- 1 | ### Title: Roadmapping 2 | 3 | ### Learning Goals: 4 | We will learn how to create and maintain a roadmap for an open source project 5 | 6 | ### Target Audience: 7 | new project leads on open source projects 8 | 9 | ### Delivery Format: 10 | In person workshop 11 | 12 | ### Level: 13 | Beginner friendly 14 | 15 | ### Time to complete: 16 | 45 mins 17 | 18 | ### What you'll need to start: 19 | computer, your favourite browser, GitHub account, open source project on GitHub 20 | 21 | ### Before using this resource you should be familiar with: 22 | * Editing files in GitHub 23 | * Writing a good README 24 | 25 | ### For information on those topics, see: 26 | * @zee-moz's README lesson 27 | 28 | ### Glossary of key terms: 29 | * **Roadmap**: Schedule of work to be done on a project 30 | * **Milestone**: An event or state marking a specific stage in development on the project 31 | 32 | ### Intro to material: 33 | When you're starting on an open source project, it's important to record what your community (this might just be you at the beginning) decides to work on! A roadmap organizes the tasks that nees to be done on a project around milestones. This helps potential contributors understand the current status of your poject and where it's going next. 34 | 35 | A roadmap can also express your vision for the project. Make sure you clearly state why you are implementing certain things to get people excited about joining. 36 | 37 | This can be as simple as a collection of issues in your issue tracker, or a detailed timeline complete with milestones. It's up to you to choose what works best for your community! At the Mozilla Science Lab, we break our Roadmaps into three sections: 38 | 39 | 1. **Project Mission & Summary** 40 | 2. **How to Get Involved** 41 | 3. **Timeline** 42 | 43 | You can see an example of this in the [Contributorship Badges for Science Roadmap](https://github.com/mozillascience/PaperBadger/issues/17) 44 | 45 | ### Steps to complete: 46 | 47 | 1. Write the **Project Mission & Summary** 48 | * Since new contributors may be linked directly to the Roadmap, it can be jarring if you jump right into the timeline. Use this section to orient new visitors 49 | * Start with the project name along with your mission statement or a clear summary of what you are doing. 50 | * Keep this shorter than your README, but make sure your mission is clear 51 | * **tips** 52 | * Keep it short and simple! 53 | * Use this space to case some vision -- people get involved because they're excited about what you're building 54 | 2. Write **How to Get Involved** 55 | * Once users have seen your summary, they may want to get involved right away! If you have any good first bugs, or if you've labelled any of your issues with specific skillsets, link them here! This gives potential contributors a way to get involved immediately. 56 | * **tips** 57 | * Try to keep a handful of smaller, simpler tasks open labelled 'Good first bug' and make it point to let others know new contributors will be mentored through this issue 58 | * Try labelling tasks by type of contribution (development, design, discussion) - this helps limit the choices to tasks users are interested in 59 | 3. Write the **Timeline** 60 | * This section organizes tasks needed to complete your project around milestones 61 | * When your community decides to do something, write it down in the roadmap! Your roadmap will constantly be changing as you hit milestones and decide on important features. 62 | * **Pick some milestones** - they can be: 63 | * project status goals (project up on Collaborate, MVP) 64 | * dates (good if you have deadlines / set time to work on the project) 65 | * events (Mozilla Science Lab Global Sprint, MozFest) 66 | * short term, medium term and long term - use this if you don't have set deadlines 67 | * **Lists tasks under each milestone**. Take time here to explain *why* you are doing this task. It can help enforce your vision for this project. 68 | * Your tasks will probably be more detailed in shorter-term goals 69 | 70 | ### Follow-up resources and materials: 71 | 72 | 73 | ### Any credits or attribution: 74 | -------------------------------------------------------------------------------- /handouts/sprints_events.md: -------------------------------------------------------------------------------- 1 | ### Title: Event Planning Is Fun ! 2 | 3 | ### Learning Goals: 4 | We will learn what steps need to be completed to plan a sprint or community event. 5 | 6 | ### Target Audience: 7 | Anyone that would like to organize a well-planned, welcoming sprint or community event. 8 | 9 | ### Delivery Format: 10 | In person workshop or online 11 | 12 | ### Level: 13 | All levels 14 | 15 | ### Time to complete: 16 | * 3-5 minutes to read the exercise 17 | * 30 minutes to get started on the initial planning 18 | * 2 months - to fully plan a local sprint 19 | * 3 - 4 months - to fully plan a global sprint 20 | 21 | ### What you'll need to start: 22 | Paper, pen (in person), a collaborative document like Google docs, Etherpad (online) 23 | 24 | ### Before using this resource you should be familiar with: 25 | N/A 26 | 27 | ### For information on those topics, see: 28 | N/A 29 | 30 | ### Glossary of key terms: 31 | 32 | * **Sprint** - is an event where project leads connect with contributors from the community to work on open source projects. 33 | 34 | * **Local sprint** - is an event that has projects, project leads and contributors that come from the local area 35 | 36 | * **Global sprint** - is an event with multiple sites around the world where participants work on projects for a set time period within their timezone 37 | 38 | * **Contributor** - a person that contributes content or services to an open source project 39 | 40 | * **Project lead** - a person that is the main contact for a particular project 41 | 42 | * **Venue** - the place where the sprint will be held 43 | 44 | * **Swag** - Promotional merchandise given away at events, trade fairs or conferences 45 | 46 | 47 | ### Intro to material: 48 | Planning project-based sprints or community events is a great way to bring leaders and contributors together to collaborate and share. 49 | Well organized, welcoming and inclusive sprints & events take some time to prepare. 50 | 51 | ### Steps to complete: 52 | Consider the following questions in each section and answer them as detailed as possible. We,ve provided tips to help you better plan, and suggestions of the kind of materials and needs you might consider. 53 | 54 | 1. **Pre-sprint planning**: 55 | 56 | * **General Information**: 57 | 58 | * What is the overall goal /purpose of your event ? 59 | 60 | * Who is your (target audience) ? 61 | 62 | * What is the format for the event ? 63 | 64 | * Is there a budget for the event ? 65 | 66 | * When will the event take place ? 67 | 68 | **Tip**: In picking a date remember to consider any special events / religious holidays / family time / seasonal workloads. 69 | 70 | 71 | **Venue and Room Set-up**: 72 | 73 | * Where will it be held ? 74 | 75 | * Take a moment to think about three possible places for your event 76 | 77 | * How many will it need to hold ? 78 | 79 | * How will the room be arranged? 80 | 81 | * Are there lots of electrical plug-ins ? 82 | 83 | 84 | * **Tip**: When considering a venue make sure to pick one that is accessible, close to public transit and has parking options for those coming from a distance. 85 | 86 | 87 | * **Tip**: The room should be large enough to hold all attendees at round tables. For example, for a group of 60 attendees there should be room for 8-10 tables, if the tables seat 6-8 attendees. There should be space at the front of the room for a podium, a flip chart, and projection screen that is visible to all attendees. 88 | 89 | 90 | **Food and Beverage**: 91 | 92 | * Is there budget for the food and drink ? 93 | 94 | * What food will you provide ? 95 | 96 | 97 | * **Tip**: Food and beverage service is not required, but is typically appreciated by attendees. For full-day workshops, it is recommended that light breakfast items along with coffee and tea be provided in the morning, lunch at midday, and a light snack during an afternoon break. It is useful to have coffee and water provided throughout the day, if possible. 98 | 99 | 100 | * **Tip**: If there is a food and beverage service, an adjacent room can be set up for this, or it should be set up in an area of the workshop room that will cause the least amount of disturbance to the ongoing training. 101 | 102 | 103 | **Event Promotion**: 104 | 105 | *How will you promote your event ? 106 | 107 | *What contacts do you have in the community ? 108 | 109 | *What groups are active in your area that match your target audience ? 110 | 111 | 112 | * **Tip**: The following is a suggested list of ways to promote your event 113 | 114 | 115 | * Personal Contacts 116 | 117 | * Email distribution lists 118 | 119 | * Twitter - pre-schedule tweets before and during lead-up to event 120 | 121 | * Meetup groups - contact the organizers to see if they will post your event 122 | 123 | * Local newspapers 124 | 125 | * Event page or website 126 | 127 | * Blogging about your event 128 | 129 | 130 | **Audio-Visual Needs**: 131 | 132 | * What A/V setup do you need to accommodate the sprint format ? 133 | 134 | * What will the venue provide ? 135 | 136 | * What will you have to bring ? 137 | 138 | 139 | * **Tip**: The following is a recommended list of equipment that should be onsite for the workshop: 140 | 141 | 142 | * Podium with microphone or other appropriate speaking spot for facilitator 143 | 144 | * Handheld wireless microphone for groups larger than 50 attendees 145 | 146 | * LCD Projector 147 | 148 | * Projection screen 149 | 150 | * Computer with Microsoft PowerPoint, USB port, and internet access 151 | 152 | * Video/audio projection capability through computer and audio hookup (i.e., for playing video with sound from laptop) 153 | 154 | * Flip chart and markers 155 | 156 | * Whiteboards 157 | 158 | 159 | **Workshop Materials and Give-aways**: 160 | 161 | Although not required it is a great idea to offer give-aways to sprint participants. These are great for promotional purposes as well as reminders to participants of their sprint experience. 162 | 163 | 164 | * **Tip**: Here are some suggestions: 165 | 166 | * stickers 167 | 168 | * USB drivers 169 | 170 | * mini device chargers 171 | 172 | * T-shirts 173 | 174 | * pens 175 | 176 | 177 | ### Follow-up resources and materials: 178 | https://public.etherpad-mozilla.org/p/sciencelab-facilitation-handout 179 | https://docs.google.com/spreadsheets/d/14aczcRsP3pn7A1jWowQu3EYSuWj4yRRDxEBAl1-6--w/edit#gid=565772497 180 | 181 | 182 | ### Any credits or attribution: 183 | 184 | NOTE: add some suggested lists, pick a consistant format between sections, ask the questions 185 | -------------------------------------------------------------------------------- /handouts/user_person_pathways.md: -------------------------------------------------------------------------------- 1 | **Title:** Personas and Pathways for Growing Communities 2 | 3 | **Goals:** This activity is designed to help you identify potential users and contributors, understand their goals and motivations, help them find a way into your project, and grow them into strong, committed community members. 4 | 5 | **Target Audience:** Open science project leads and Mozilla Study Group leads seeking to attract and grow communities of contributors around their projects 6 | 7 | **Format:** This is a short writing/thinking exercise. Best done with a partner or small group, but can also be done alone. 8 | 9 | **Level:** Beginner 10 | 11 | **Time to complete:** 30 to 45 minutes, or as needed 12 | What you'll need to start: Timer, paper and pen or some way of recording notes 13 | Before using this resource you should be familiar with: no pre-requisites 14 | 15 | **Intro** 16 | Your open project needs users and contributors, but how can you find them, get them involved, and keep them engaged and active in your community? One way is by creating and using "personas" and "pathways" to help you plan and test how you'll interact with new contributors. 17 | 18 | About Personas 19 | 20 | “persona” is a tool commonly used in the design world, to help create products and experiences that work for real world users (aka “user-centered design”). The persona is an imaginary user, based on real-world observations and understandings of actual potential or current users. The persona becomes real to the designer, and is used as a tool to test features and experiences (for example, a designer might ask “Would our user persona, Rodrigo, who is an avid photographer and technophile but also an introvert who’s protective of his private information, like feature x of our social media platform?”). 21 | 22 | Personas may be composites of several real-world users. The power of the persona is in its specificity; a good persona feels real, and helps a designer (or project lead) put their own perspectives aside and empathize with the needs and motivations of users. 23 | 24 | Example: 25 | 26 | *Rashid is a PhD student in astronomy at a university in Southern England. He’s outgoing and a snappy dresser, favoring skinny jeans and colorful cardigans. He lives in on-campus housing and after a long day at the lab he usually rushes home to see his wife and infant son. Rashid took an intro Java programming course long ago, as an undergrad, but his research now demands Python skills. Because of the competitive nature of his lab, he’s reluctant to ask colleagues for help. He follows Mozilla Science Labs on Twitter, has some exposure to and interest to Open Science, but is hesitant to share his data for fear of being “scooped” on an important discovery.* 27 | 28 | About Pathways 29 | 30 | Once we have a persona, we can imagine how they might interact with our project. Let's imagine that this process has a few phases: 31 | 32 | 1. Discovery (how they first hear about the project or group) 33 | 2. First Contact (how they first engage with the project or group, that intial interaction) 34 | 3. Participation (how they first participate or contribute) 35 | 4. Sustained Participation (how their contribution or involvement can continue) 36 | 5. Networked Participation (how they may network within the community) 37 | 6. Leadership (how they make take on some additional responsibility on the project, or begin to lead) 38 | 39 | 40 | If we've constructed a good persona, we can clearly see a progression of steps. 41 | Here's an example (using Rashid): 42 | 43 | 1. Discovery- Sees poster advertising study group around campus 44 | 2. First Contact- Attends a meeting of the group, and is encouraged to return in a follow up email 45 | 3. Participation- Asks and answers questions during the help session 46 | 4. Sustained Participation- attends several "hacky hour" sessions throughout the semester 47 | 5. Networked Participation- invites some of his colleagues from his lab to a session 48 | 6. Leadership- agrees to present an intro session on Java, and creates a learning resource to contribute to the group's repo 49 | 50 | 51 | As you create your pathway, ask yourself, what needs to be in place to move your persona along this pathway? What are the potential pitfalls for your persona, in terms of skills, time, motivations? Once you have a sense of this story, you might list solutions to any challenges. Here are examples: 52 | 53 | * Publicize group meetings via posters around campus as well as on twitter and via email blasts. 54 | * Collect emails of new group attendees for follow up messages. 55 | * Offer an online intro to GitHub for those who join mid-semester and missed the first sessions. 56 | * Schedule meetings for daytimes and early evenings to avoid conflicts with family schedules. 57 | 58 | 59 | 60 | **Steps to complete:** 61 | 1. Brainstorm. in groups of two, read through the following questions. Take notes! Each person should answer the question in caps in the time provided. Use a timer to keep time for each person. 62 | 63 | Who is the person you most need in your community or on your project? Think of skills and attributes, but also give them identifying details. (3 mins each) 64 | 65 | What are that person's motivations and needs? Think of what might draw them to your project, what is the value for them? (3 mins each) 66 | 67 | 68 | 2. Write. 69 | Create a short description of your persona. See above "Rashid" for an example. (3-4 mins each) 70 | 71 | 3. Plan a Path. 72 | Using the structure above, describe a pathway for your persona. What are the steps through this project? What could be stumbling blocks for user? (3 mins each) 73 | 74 | 4. List your Solutions 75 | For each potential stumbling block or barrier your user might encounter, list a solution that you'll work into your design of your group or project. (3 mins each) 76 | 77 | **Glossary of key terms:** 78 | persona- a fictional user, based on real-world observations of actual or potential users. personas are used to test and shape the design of a product or experience, so that the final design is responsive and relevant to user needs. 79 | 80 | **Follow-up resources and materials:** 81 | You may find it useful to review this handout on the the creation of your Contributing.md file in light of your new understanding of your users. 82 | You may also want to revise your proejct description to better appeal to your users, using this handout. 83 | -------------------------------------------------------------------------------- /handouts/writing_readmes.md: -------------------------------------------------------------------------------- 1 | **Learning Goals:** 2 | Create an effective, welcoming, detailed readme file for your open project. 3 | 4 | **Target Audience:** 5 | Anyone starting an open project. 6 | 7 | **Delivery Format:** 8 | This can be done by project collaborators working in groups, or working alone online 9 | 10 | **Level:** 11 | Beginner 12 | 13 | **Time to complete:** 14 | 45 minutes 15 | 16 | 17 | **What you'll need to start:** 18 | Computer with internet connection 19 | 20 | **Before using this resource you should be familiar with:** 21 | Project set-up on GitHub 22 | 23 | **Introduction:** 24 | 25 | When you open your project, you may have a specific audience in mind (for example, software developers or other researchers in your field)... but you can reach a much broader community! Many people outside of your field-- designers, technical writers, citizen scientists-- may be interested in your project and have valuable contributions to offer! Clearly communicating information about your project in simple language is an excellent way to grow and diversify your community. 26 | 27 | The readme file is one of the first things you add to your project repository. It introduces your project idea and goals. Along with the contributing file, the roadmap, and your Code of Conduct, the readme file helps welcome, orient, and encourage newcomers to participate. 28 | 29 | The following steps are designed to help you create an effective readme file. First, you'll use a tool called Open Canvas to define and organize key information about your project. Then you'll write a readme file and test it for clarity, using an online text editor that encourages the use of simple language. 30 | 31 | **1. Create an Open Canvas for your project.** 32 | Open Canvas is adapted from Lean Canvas, a one-page format used for describing a start-up business project. Open Canvas helps you clarify the problem you aim to solve, the solution you propose, and what is especially valuable about your open project. It also helps you define your users and contributors, measurements of success, and any resources you'll need. 33 | 34 | 35 | ![open canvas](http://mozillascience.github.io/working-open-workshop/handouts/img/open_canvas_details.jpg) 36 | 37 | Here is an example of an Open Canvas grid filled in for the Mozilla Science Lab's Paper Badger Project: 38 | 39 | ![paper badger example](http://mozillascience.github.io/working-open-workshop/handouts/img/badges_open_canvas.jpg) 40 | 41 | 42 | Fill in the boxes in the Open Canvas format. [Here is a link to an editable version of the Open Canvas Format.](https://mozillascience.github.io/working-open-workshop/open_canvas/) 43 | 44 | **2. Write** 45 | 46 | Using the information you gathered in the Open Canvas exercise, write your readme file. Be sure to: 47 | 48 | * Say hello! Welcome people to the project. 49 | * Show what you're doing, for who, and why. 50 | * Explain what makes your project special, useful, exciting! 51 | * Show how to get started using or contribution to the project 52 | * State what resources and contributions you're looking for 53 | * Point to other key resources, such as a contributing.md file and a roadmap. 54 | 55 | 56 | **3. Remove jargon** 57 | 58 | Copy your new project description (what you're doing, for who, and why) and drop it into the [Up-Goer 5 text editor](http://splasho.com/upgoer5/). Try to rewrite the description using only allowed words. This is a great way to identify technical language that will confuse newcomers. [For reference, here's an example of a rocket ship diagram communciated in common language](http://xkcd.com/1133/). 59 | 60 | In your final readme text, don't restrict yourself to only the most common words--if you do, your project description may become overly simplified and limited. **Use what you've learned from this exercise to keep your readme as jargon-free as possible. If you use jargon, be sure to define those words.** 61 | 62 | **4. Re-write** 63 | 64 | Re-write your entire readme in clear language and define all terms. Post your readme in your GitHub repo. 65 | 66 | **Follow-up resources and materials:** 67 | 68 | See our guides on Roadmapping and writing Contributing.md files 69 | 70 | **Glossary:** 71 | 72 | * **Readme file:** a document that introduces an open project to the public and any potential contributors. 73 | * **jargon:** a type of language, especially vocabulary, that is particular to a certian trade or discipline, and is not understood by anyone outside that discipline. 74 | * **repository or repo:** a collection of documents related to your project, in which you create and save new code or content. 75 | 76 | 77 | **Any credits or attribution:** 78 | 79 | Created by Zannah Marsh, with assistance from Abby Cabunoc Mayes. Comic from XKCD; Up-Goer 5 text editor from splasho.com 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | -------------------------------------------------------------------------------- /humans.txt: -------------------------------------------------------------------------------- 1 | All the lovely humans involved in WoW Berlin 2016 2 | 3 | // Team // 4 | 5 | Mozilla Science Lab: 6 | 7 | - Abigail Cabunoc Mayes 8 | - Arliss Collins 9 | - Aurelia Moser 10 | - Zannah Marsh 11 | - Kaitlin Thaney 12 | - Stephanie Wright 13 | 14 | Mozilla Fellows: 15 | - Christie Bahlai 16 | - Richard Smith Unna 17 | - Joey Lee 18 | - Jason Bobe 19 | 20 | 21 | // Participants (and affiliations) // 22 | - Brian Bot / Sage Bionetworks / 23 | - Achintya Rao / UWE, Bristol + CERN 24 | - Fatma Guerfali/Pasteur Institute 25 | - Amel Ghouila/ Institut Pasteur de Tunis 26 | - Bastian Greshake / University of Frankfurt & openSNP 27 | - Oliver Sauter / WorldBrain - Verifying the Internet with Science / Berlin 28 | - Gabriella Azzopardi / University of Malta 29 | - Harun Urhan / FSMVU 30 | - Siddha Ganju / Carnegie Mellon University 31 | - Patricia Herterich/ CERN & Humboldt-Universitat zu Berlin 32 | - Ali Swanson/ Oxford & Zooniverse (www.zooniverse.org & www.snapshotserengeti.org) 33 | - Tom Hardwicke/ Department of Experimental Psychology, UCL 34 | - Anirudha Bose / IIIT Bhubaneswar 35 | - Shubham Gupta/ UPES 36 | - Demitri Muna / Ohio State Univ, Trillian Project 37 | - Igor Babuschkin / University of Manchester 38 | - Richard Smith-Unna / Mozilla Science Lab + Cambridge 39 | - Tim Head / project everware 40 | - Stuart Mumford / The Univeristy of Sheffield (SunPy) 41 | - Anna Krystalli/ University of Sheffield 42 | - Madeleine Bonsma / University of Toronto 43 | - Robert Sullivan / Springer Nature 44 | - Kirstie Whitaker / University of Cambridge 45 | - Anelda van der Walt / Talarify & North-West University 46 | - Jon Tennant / Imperial College London; ScienceOpen 47 | - Harry Smith / Lancaster University 48 | - Christopher Kittel / Institute for System Sciences, Uni Graz 49 | - Melissa Romaine / Mozilla, Open Web Fellows program 50 | -Sarah Allen / Mozilla 51 | 52 | // Special Thanks!! // 53 | 54 | - Luke Pacholski + the Mozilla Design team for template design. 55 | - Norma Miller from White Coat Captioning for transcribing the event! 56 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | WOW 2016 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 28 | 29 |
30 | 35 | 36 |

Working Open Workshop

37 |

http://bit.ly/moz_wow

38 | 39 |
40 |

41 | At our first Working Open Workshop, Mozilla Science Lab staff, Fellows and community will run a set of trainings to help up-and-coming projects prepare for a strong launch on Collaborate and a successful Global Sprint in June 2016. This page will serve as a resource for all session materials. 42 |

43 |
44 | 45 |
46 | mozwow 47 |
48 | 49 | 50 |

Schedule

51 | 52 |

53 | The schedule can be found in the workshop repository here, the following handouts are ordered according to the scheduled session times. 54 |

55 | 56 |

Presentations

57 |

58 | Each session has a ten-minute presentation. Slides for these presentations are linked below. 59 |

60 | 61 |
    62 |
  1. README and Project Communication - How they first hear about the project or group.
    2. 63 |
  2. Roadmapping - How to plan your project schedule and priorities.
    3. 64 |
  3. Contributor Guidelines - How they first participate or contribute.
    4. 65 |
  4. GitHub for New Project Leads and Contributors - How to use Github as a collaborative platform.
    5. 66 |
  5. Code of Conduct - How to control behavior and the tone of project interactions.
    6. 67 |
  6. Event Planning - How to plan activities that support and build your project.
    7. 68 |
  7. Personas and Pathways - How to plan for your project users and their participation.
    8. 69 |
  8. Open Data and Data Reuse Plans - How to manage data in your research and share it appropriately.
    9. 70 |
  9. Open Leadership Cohort & Closing - About the Open Leadership Cohort and closing remarks.
    10. 71 |
72 | 73 |

Handouts

74 | 75 |

Sessions

76 | 77 |

78 | Handouts will provide participants with post-presentation exercises to complete during work sessions. 79 |

80 | 81 |
    82 |
  1. README and Project Communication
    2. 83 |
  2. Roadmapping
    3. 84 |
  3. Contributor Guidelines
    4. 85 |
  4. GitHub for New Project Leads and Contributors
    5. 86 |
  5. Code of Conduct
    6. 87 |
  6. Event Planning
    7. 88 |
  7. Personas and Pathways
    8. 89 |
  8. Open Data and Data Reuse Plans
    9. 90 |
91 | 92 |

Notes

93 | 94 |

95 | Each session will feature transcriptions from our guest transcriber, Norma Miller. We will publish those transcripts here as they come, stay tuned! 96 |

97 | 98 | 113 |

114 | Likewise, we have a living etherpad where we will be collecting any questions from participants and answering on a rolling basis 115 |

116 |

117 | You can find photos from the event on our Mozilla Science Flickr account, and by following the twitter feed for #mozwow. 118 |

119 | 120 |

Help

121 | 122 |
    123 | 124 |
  1. 125 |

    Getting Help

    126 |

    127 | Here we'll hopefully answer questions you might have. 128 |

    129 | 130 |
      131 |
    • 132 |

      What is the WIFI code?

      133 |
        134 |
      • Cathedral
        • 135 |
      • Cathedral_16
        • 136 |
      • OR
        • 137 |
      • RM-Loft
        • 138 |
      • loftberlin2014
        • 139 |
      140 |
      • 141 |
    • 142 |

      What is our event hashtag?

      143 |

      144 | #mozwow 145 |

      146 |
      • 147 |
    • 148 |

      Where can I find the Science Lab Code of Conduct?

      149 |

      150 | You can find it here. We'd love for feedback on how it could be improved. Stay tuned for the Code of Conduct session at WOW (see above). 151 |

      152 |
      • 153 |
    • 154 |

      Who can I approach if I have any problems or issues to report that violate our Code of Conduct?

      155 |

      156 | In coordination with our Code of Conduct, we have two appointed members of our "safety team" responsible for maintaining the ethos of that code throughout the event, and providing help or resources to anyone who might require it. Reach out to the following people if you have questions, issues, or concerns that you wish to express. 157 |

      158 |
        159 |
      • Kaitlin Thaney - @kaythaney, kaitlin@mozillafoundation.org
        • 160 |
      • Joey K. Lee - @leejoeyk, josephkanglee@gmail.com
        • 161 |
      162 |
      • 163 |
    164 |
    2. 165 | 166 |
  2. 167 |

    Finding Resources

    168 |

    169 | Here we'll list some persistent resources that you might use throughout the workshop. 170 |

    171 | 205 |
206 | 207 |

Glossary

208 |
209 |
210 |

OLC

211 |

212 | Open Leadership Cohort is a group of participants who have a shared experience and goal - to help further open practice in their work and community. It's what the WOW participants will be inducted into, you can read more about it on this blog. 213 |

214 |
215 |
216 |

Fellows

217 |

218 | The Mozilla Science Lab has a group of awesome fellows in our annual fellowship program, the 2015 fellows are present at WOW, and will be co-running sessions throughout the event. 219 |

220 |
221 |
222 | 223 |
224 | 225 | 226 | -------------------------------------------------------------------------------- /open_canvas/index.html: -------------------------------------------------------------------------------- 1 | 2 | Open Planvas scratchpad 3 | 4 | 59 | 60 | 61 | 62 | 63 |

Open Planvas

64 | 65 |
66 |
67 |

Problem

68 | 69 |
70 |
71 | 72 |
73 |
74 |

Solution

75 | 76 |
77 |
78 | 79 |
80 |
81 |

Key Metrics

82 | 83 |
84 |
85 | 86 |
87 |
88 |

Unique Value Proposition

89 | 90 |
91 |
92 | 93 |
94 |
95 |

User Profiles

96 | 97 |
98 |
99 | 100 |
101 |
102 |

User Channels

103 | 104 |
105 |
106 | 107 |
108 |
109 |

Resources Required

110 | 111 |
112 |
113 | 114 |
115 |
116 |

Contributor Profiles

117 | 118 |
119 |
120 | 121 |
122 |
123 |

Contributor Channels

124 | 125 |
126 |
127 | 128 |
129 |

Product

130 |
131 | 132 |
133 |

Community

134 |
135 | 136 | 137 | -------------------------------------------------------------------------------- /personas_pathways/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Personas and Pathways for Growing Communities 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 30 | 31 |
32 | 37 | 38 | 39 |

Personas and Pathways for Growing Communities

40 | 41 |
42 |

43 | This activity is designed to help you identify potential users and contributors, 44 | understand their goals and motivations, help them find a way into your project, 45 | and grow them into strong, committed community members. 46 |

47 |
48 | 49 |

For beginners

50 |
51 |
52 | 53 |
54 |
55 |

Format

56 |

57 | This is a short writing/thinking exercise. Best done with a partner or small group, 58 | but can also be done alone. 59 |

60 |
61 | 62 |
63 |

Target Audience

64 |

65 | Open science project leads and Mozilla Study Group leads seeking to attract and 66 | grow communities of contributors around their projects 67 |

68 |
69 | 70 |
71 |

Materials

72 |
    73 |
  • A timer
    • 74 |
  • Pen & Paper
    • 75 |
  • A way to take notes
    • 76 |
77 |
78 |
79 | 80 |

Introduction

81 | 82 |

83 | Your open project needs users and contributors, but how can you find them, get 84 | them involved, and keep them engaged and active in your community? One way is 85 | by creating and using "personas" and "pathways" to help you plan and test how 86 | you'll interact with new contributors. 87 |

88 | 89 |

About Personas

90 | 91 |

92 | “persona” is a tool commonly used in the design world, to help create products 93 | and experiences that work for real world users (aka “user-centered design”). 94 | The persona is an imaginary user, based on real-world observations and 95 | understandings of actual potential or current users. The persona becomes 96 | real to the designer, and is used as a tool to test features and experiences 97 | (for example, a designer might ask “Would our user persona, Rodrigo, who is an 98 | avid photographer and technophile but also an introvert who’s protective of 99 | his private information, like feature x of our social media platform?”). 100 |

101 | 102 |

103 | Personas may be composites of several real-world users. The power of the 104 | persona is in its specificity; a good persona feels real, and helps a designer 105 | (or project lead) put their own perspectives aside and empathize with the needs 106 | and motivations of users. 107 |

108 | 109 |
110 |
111 |

Sample Persona

112 |
113 |
114 |

115 | Rashid is a PhD student in astronomy at a university in Southern England. 116 | He’s outgoing and a snappy dresser, favoring skinny jeans and colorful 117 | cardigans. He lives in on-campus housing and after a long day at the lab 118 | he usually rushes home to see his wife and infant son. 119 |

120 |

121 | Rashid took an intro Java programming course long ago, 122 | as an undergrad, but his research now demands Python skills. Because of the competitive nature of his lab, he’s reluctant to ask colleagues for help. 123 | He follows Mozilla Science Labs on Twitter, has some exposure to and interest to Open 124 | Science, but is hesitant to share his data for fear of being “scooped” on an important discovery. 125 |

126 |
127 |
128 | 129 |

About Pathways

130 | 131 |

132 | Once we have a persona, we can imagine how they might interact with our project. 133 | Let's imagine that this process has a few phases. 134 |

135 | 136 |
    137 |
  1. Discovery - How they first hear about the project or group.
    2. 138 |
  2. First Contact - How they first engage with the project or group, that intial interaction.
    3. 139 |
  3. Participation - How they first participate or contribute.
    4. 140 |
  4. Sustained Participation - How their contribution or involvement can continue.
    5. 141 |
  5. Networked Participation - How they may network within the community.
    6. 142 |
  6. Leadership - How they may take on some additional responsibility on the project, or begin to lead.
    7. 143 |
144 | 145 |

146 | If we've constructed a good persona, we can clearly see a progression of steps. Example (using Rashid) 147 |

148 |
149 |
150 |

Sample Pathway

151 |
152 |
153 |

154 |

    155 |
  1. Discovery - Sees poster advertising study group around campus.
    2. 156 |
  2. First Contact - Attends a meeting of the group, and is encouraged to return in a follow up email.
    3. 157 |
  3. Participation - Asks and answers questions during the help session.
    4. 158 |
  4. Sustained Participation - Attends several "hackathons" sessions throughout the semester.
    5. 159 |
  5. Networked Participation - Invites some of his colleagues from his lab to a session.
    6. 160 |
  6. Leadership - Agrees to present an intro session on Java, and creates a learning resource 161 | to contribute to the group's repo. 162 |
    7. 163 |
164 |

165 |
166 |
167 | 168 | 169 |

170 | As you create your pathway, ask yourself, what needs to be in place to move your persona 171 | along this pathway? What are the potential pitfalls for your persona, in terms of skills, 172 | time, motivations? Once you have a sense of this story, you might list solutions to any 173 | challenges. Here are examples: 174 |

175 | 176 |
    177 |
  • Publicize group meetings via posters around campus as well as on twitter and via email blasts.
    • 178 |
  • Collect emails of new group attendees for follow up messages.
    • 179 |
  • Offer an online intro to GitHub for those who join mid-semester and missed the first sessions.
    • 180 |
  • Schedule meetings for daytimes and early evenings to avoid conflicts with family schedules.
    • 181 |
182 | 183 |

Steps to Complete

184 | 185 |
    186 | 187 |
  1. 188 |

    Brainstorm

    189 |

    190 | In groups of two, read through the following questions. Take notes! Each person 191 | should answer the question in caps in the time provided. Use a timer to keep 192 | time for each person. 193 |

    194 | 195 |
      196 |
    • 197 |

      Who is the person you most need in your community or on your project?

      198 | 199 |

      200 | Think of skills and attributes, but also give them identifying details. 201 |

      202 |
      • 203 | 204 |
    • 205 |

      What are that person's motivations and needs?

      206 | 207 |

      208 | Think of what might draw them to your project, what is the value for them? 209 |

      210 |
      • 211 |
    212 |
    2. 213 | 214 | 215 |
  2. 216 |

    Write

    217 | 218 |

    219 | Create a short description of your persona. See above "Rashid" for an example. 220 |

    221 |
    3. 222 | 223 | 224 |
  3. 225 |

    Plan a Pathway

    226 | 227 |

    228 | Using the structure above, describe a pathway for your persona. What are the steps 229 | through this project? What could be stumbling blocks for user? 230 |

    231 |
    4. 232 | 233 | 234 |
  4. 235 |

    List your Solutions

    236 | 237 |

    238 | For each potential stumbling block or barrier your user might encounter, list a 239 | solution that you'll work into your design of your group or project. 240 |

    241 |
    5. 242 |
243 | 244 |

Glossary

245 |
246 |
247 |

Persona

248 |

249 | A fictional user, based on real-world observations of actual or potential users. Personas are used 250 | to test and shape the design of a product or experience, so that the final design responsive 251 | and relevant to user needs. 252 |

253 |
254 |
255 | 256 |

Follow-up Resources & Materials

257 |
    258 |
  • 259 | You may find it useful to review this handout on the creation of your CONTRIBUTING.md 260 | file in light of your new understanding of your users. 261 |
    • 262 |
  • 263 | You may also want to revise your project description to better appeal to your users, using this handout. 264 |
    • 265 |
266 | 267 | 276 | 277 |
278 | 279 | 280 | -------------------------------------------------------------------------------- /roadmap.md: -------------------------------------------------------------------------------- 1 | ##WOW Roadmap 2 | 3 | ####Goal 4 | To create materials our first Working Open Workshop, for delivery at the event in early February 2016 in Berlin. Materials include talks, handouts/tear sheets, work session formats, and activities per our schedule for the workshop. 5 | 6 | ####Timeline: 7 | Milestones are week by week in the run-up to the Workshop. 8 | 9 | ####Week ending January 15 10 | 11 | - [x] Create Repo, Readme and Roadmap 12 | - [x] Create workshop schedule 13 | - [x] Review Pre-workshop Survey Responses 14 | - [x] Check in with Design Team on visual resources for WOW 15 | - [x] Assign issues 16 | - [ ] Compile drafts (work in progress, notes, whatever you have) of [short talk outline](https://github.com/mozillascience/learning/blob/master/talk-guidelines.md) (see issues for each): 17 | 18 | **(WOW Day 1)** 19 | 20 | * Roadmapping 21 | * Crafting a Readme 22 | * Contributor Guidelines 23 | * Github for New Leads and Contributors 24 | * More Github 25 | 26 | **(WOW Day 2)** 27 | 28 | * User personas 29 | * Codes of Conduct 30 | * Events and Sprints 31 | * Data Reuse Plans 32 | 33 | ####Week Ending January 22 34 | - [ ] Holiday! MLK Day in USA 35 | - [ ] Review Drafts of Talks (above) 36 | - [ ] Revise Talks 37 | - [ ] Design visual format for talk assets/slides 38 | - [ ] Draft [tearsheets/handouts for talks](https://github.com/mozillascience/learning/blob/master/resource-template.md) 39 | - [ ] Create plan for curriculum work during Fellows Workweek 40 | - [ ] Plan format for Kits 41 | 42 | ####Week ending January 29 43 | - [ ] Revise tearsheets/handouts 44 | - [ ] Create visuals for talks/slides 45 | - [ ] Review all materials 46 | - [ ] Build kits 47 | 48 | ####Week ending February 6 49 | - [ ] Catch up 50 | - [ ] Testing and revision with Fellows 51 | - [ ] Some production with Fellows 52 | - [ ] Run the workshop! 53 | -------------------------------------------------------------------------------- /roadmapping/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Intro to Roadmapping 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 30 | 31 |
32 | 37 | 38 |

Introduction to Roadmapping

39 | 40 |
41 |

42 | This activity is designed to help you write a Roadmap for your open source project or Mozilla Science study group. 43 |

44 |
45 | 46 |

For beginners

47 |
48 |
49 | 50 |
51 |
52 |

Format

53 |

54 | This is a short writing/thinking exercise. Best done with a partner or small group, 55 | but can also be done alone. 56 |

57 |
58 | 59 |
60 |

Target Audience

61 |

62 | Open science project leads and Mozilla Study Group leads seeking to attract and 63 | grow communities of contributors around their projects 64 |

65 |
66 | 67 |
68 |

Materials

69 |
    70 |
  • Computer
    • 71 |
  • Your favourite browser
    • 72 |
  • GitHub account
    • 73 |
  • Open source project on GitHub
    • 74 |
75 |
76 |
77 | 78 |

Introduction

79 | 80 |

81 | When you're starting on an open source project, it's important to record what your community (this might just be you at the beginning) decides to work on! A roadmap organizes the tasks that nees to be done on a project around milestones. This helps potential contributors understand the current status of your poject and where it's going next. 82 |

83 | 84 |

85 | A roadmap can also express your vision for the project. Make sure you clearly state why you are implementing certain things to get people excited about joining. 86 |

87 | 88 |

89 | This can be as simple as a collection of issues in your issue tracker, or a detailed timeline complete with milestones. It's up to you to choose what works best for your community! At the Mozilla Science Lab, we break our Roadmaps into three sections: 90 |

91 | 92 |
93 |
94 |

Roadmap Structure

95 |

If your roadmap is more than a list of issues, we recommend three sections to welcome new contributors.

96 |
97 |
98 |

99 | 1. Project Mission & Summary (optional) - Welcome and orient visitors to your project. Users may have been linked directly to the Roadmap, it's important to help them understand where they are. 100 |

101 |

102 | 2. How to Get Involved (optional) - New contributors might want to jump in right away! This points them to parts of the project they can immediately work on. 103 |

104 |

105 | 3. Timeline - The star of the roadmap!
106 | This section organizes tasks needed to complete your project around milestones, mapping out what you're working on now and where it's going next. This can be as simple as a list of issues in your issue tracker. 107 |

108 |
109 |
110 | 111 |

Examples

112 | 115 | 116 |

Steps to Complete

117 | 118 |
    119 | 120 |
  1. 121 |

    Add your "Project Mission & Summary"

    122 | 123 |

    124 | Use this space to orient and welcome new visitors. Start with the project name along with your mission statement or a clear summary of what you are doing. If you've already written a README, you can adapt the summary and add a shorter version here. 125 |

    126 | 127 |

    128 | For more information on writing a project mission statement or summary, see the Writing a README Exercise. 129 |

    130 | 131 |
    2. 132 | 133 | 134 |
  2. 135 |

    Write "How to Get Involved"

    136 | 137 |

    138 | New contributors might want to jump in right away! This points them to parts of the project they can immediately work on. 139 |

    140 |
    3. 141 | 142 | 143 |
  3. 144 |

    Pick Milestones

    145 | 146 |

    147 | Depending on your project, milestones can vary from development goals to events. Here are some milestones you can use: 148 |

    149 |
      150 |
    • 151 |

      Project Status Goals

      152 |

      Are you working to implement your MVP (minimum viable product) or a specific feature? Your milestones can be completing a feature or a release.

      153 |

      examples: Get your project on Collaborate, build an MVP

      154 |
      • 155 |
    • 156 |

      Dates

      157 |

      If you have deadlines or a set time to work on this project, use this as a milestone!

      158 |
      • 159 |
    • 160 |

      Events

      161 |

      If you'll be sprinting or demoing your project at an event, it's helpful to know what you'll need to complete before and during the event.

      162 |

      examples: Mozilla Science Lab Global Sprint prep work, MozFest sprint tasks

      163 |
      • 164 |
    • 165 |

      Short, Medium & Long Term

      166 |

      When working with volunteers, it can be difficult to set hard deadlines. When unsure, you can use short, medium and long term milestones. 167 |

      168 |

      Short term - things you are working on now
      169 | Medium term - things contributors can start working on that is not currently being worked on
      170 | Long term - you can describe where your project is going here 171 |

      172 |
      • 173 |
    174 |
    4. 175 | 176 | 177 |
  4. 178 |

    List Tasks to Complete for Each Milestone

    179 | 180 |

    Create an issue for each task. Take time to describe the task along with why you are doing this task. 181 | This will strengthen the vision for your project and help others get involved.

    182 |

    Tips for issues: Include as much context and help as possible! Add links, mention specific people involved 183 | by their username (i.e. @acabunoc). Articulate the problem or idea along with solutions and next steps.

    184 |

    Link to these issues in your Roadmap under each milestone. Congrats! You now have a Roadmap with tasks.

    185 |
    5. 186 |
187 | 188 |

Glossary

189 |
190 |
191 |

Roadmap

192 |

193 | A document outlining the schedule of work to be done on a project. 194 |

195 |
196 |
197 |

Milestone

198 |

199 | An event or state marking a specific stage in development on the project. 200 |

201 |
202 |
203 | 204 |

Follow-up Resources & Materials

205 | 206 | 217 | 218 | 227 | 228 |
229 | 230 | 231 | -------------------------------------------------------------------------------- /template/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Personas and Pathways for Growing Communities 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 28 | 29 |
30 | 35 | 36 |

Personas and Pathways for Growing Communities

37 | 38 |
39 |

40 | This activity is designed to help you identify potential users and contributors, 41 | understand their goals and motivations, help them find a way into your project, 42 | and grow them into strong, committed community members. 43 |

44 |
45 | 46 |

For beginners

47 |
48 |
49 | 50 |
51 |
52 |

Format

53 |

54 | This is a short writing/thinking exercise. Best done with a partner or small group, 55 | but can also be done alone. 56 |

57 |
58 | 59 |
60 |

Target Audience

61 |

62 | Open science project leads and Mozilla Study Group leads seeking to attract and 63 | grow communities of contributors around their projects 64 |

65 |
66 | 67 |
68 |

Materials

69 |
    70 |
  • A timer
    • 71 |
  • Pen & Paper
    • 72 |
  • A way to take notes
    • 73 |
74 |
75 |
76 | 77 |

Introduction

78 | 79 |

80 | Your open project needs users and contributors, but how can you find them, 81 | get them involved, and keep them engaged and active in your community? 82 | One way is by creating and using "personas" and "pathways" to help you. 83 |

84 | 85 |

86 | A “persona” is a tool commonly used in the design world, to help create products 87 | and experiences that work for real world users (aka “user-centered design”). 88 | The persona is an imaginary user, based on real-world observations and understandings 89 | of actual potential or current users. The persona becomes real to the designer, 90 | and is used as a tool to test ideas and experiences (for example, a designer 91 | might ask “Would our user persona, Rodrigo, who is an avid photographer and 92 | technophile but also an introvert who’s protective of his private information, 93 | like feature x of our social media platform?”). 94 |

95 | 96 |

97 | Personas may be composites of several real-world users. The power of the 98 | persona is in its specificity; a good persona feels real, and helps a designer 99 | (or project lead) put their own perspectives aside and empathize with the needs 100 | and motivations of users. 101 |

102 | 103 |
104 |
105 |

Sample Persona

106 |
107 |
108 |

109 | Rashid is a PhD student in astronomy at a university in Southern England. 110 | He’s outgoing and a snappy dresser, favoring skinny jeans and colorful cardigans. 111 | He lives in on-campus housing and after a long day at the lab he usually rushes home 112 | to see his wife and infant son. 113 |

114 |

115 | Rashid took an intro Java programming course long ago, 116 | as an undergrad, but his research now demands Python skills. He attended a two-day 117 | Software Carpentry workshop at his institution. 118 |

119 |
120 |
121 | 122 |

About Pathways

123 | 124 |

125 | Once we have a persona, we can imagine how they might interact with our project. 126 | Let's imagine that this process has a few phases. 127 |

128 | 129 |
    130 |
  1. Discovery - How they first hear about the project or group.
    2. 131 |
  2. First Contact - How they first engage with the project or group, that intial interaction.
    3. 132 |
  3. Participation - How they first participate or contribute.
    4. 133 |
  4. Sustained Participation - How their contribution or involvement can continue.
    5. 134 |
  5. Networked Participation - How they may network within the community.
    6. 135 |
  6. Leadership - How they may take on some additional responsibility on the project, or begin to lead.
    7. 136 |
137 | 138 |

139 | As you create your pathway, ask yourself, what needs to be in place to move Rashid along this pathway? 140 | What are the potential pitfalls for Rashid-- in terms of his skills, his time, his motivations? 141 | Once you have a sense of this story, you might list solutions to any challenges. 142 | Here are a few examples… 143 |

144 | 145 |
    146 |
  • Publicize group meetings via posters around campus as well as on twitter and via email blasts.
    • 147 |
  • Collect emails of new group attendees for follow up messages.
    • 148 |
  • Offer an online intro to GitHub for those who join mid-semester and missed the first sessions.
    • 149 |
  • Schedule meetings for daytimes and early evenings to avoid conflicts with family schedules.
    • 150 |
151 | 152 |

Steps to Complete

153 | 154 |
    155 | 156 |
  1. 157 |

    Brainstorm

    158 |

    159 | In groups of two, read through the following questions. Take notes! Each person 160 | should answer the question in caps in the time provided. Use a timer to keep 161 | time for each person. 162 |

    163 | 164 |
      165 |
    • 166 |

      Who is the person you most need in your community or on your project?

      167 | 168 |

      169 | Create a persona for this user. Think of the skill set or attributes you want, 170 | but ALSO give them a name, age, a place to live, life circumstances (single, 171 | married? family? student? mid-career?), what they like and don’t like, etc. 172 | This may seem superfluous, but the more real the persona feels to you, the 173 | more useful they’ll be. Have fun with this! 174 |

      175 |
      • 176 | 177 |
    • 178 |

      What are that person's motivations and needs?

      179 | 180 |

      181 | What’s likely to get your persona engaged and excited? What are their personal 182 | goals? Why might they be drawn to your project? What might be the value for 183 | them — what can they get out of it? 184 |

      185 |
      • 186 |
    187 |
    2. 188 | 189 | 190 |
  2. 191 |

    Write

    192 | 193 |

    194 | Create a short description of your persona. See above "Rashid" for an example. 195 |

    196 |
    3. 197 | 198 | 199 |
  3. 200 |

    Plan a Pathway

    201 | 202 |

    203 | Using the structure above, describe a pathway for your persona. What are the steps through 204 | this project? What could stumbling blocks for user? What skills, info, or resources are 205 | missing that they”ll need to better engage with the project? What kinds of things might 206 | drive them away from your project? 207 |

    208 |
    4. 209 | 210 | 211 |
  4. 212 |

    List your Solutions

    213 |

    214 | For each potential stumbling block or difficulty your user might encoutner, list a solution 215 | that you'll work into your design of your grop or project. 216 |

    217 |
    5. 218 |
219 | 220 |

Glossary

221 |
222 |
223 |

First Term

224 |

225 | A fictional user, based on real-world observations of actual or potential users. personas are used 226 | to test and shape the design of a product or experience, so that the final design responsive 227 | and relevant to user needs. 228 |

229 |
230 |
231 |

Another Term

232 |

233 | A fictional user, based on real-world observations of actual or potential users. personas are used 234 | to test and shape the design of a product or experience, so that the final design responsive 235 | and relevant to user needs. 236 |

237 |
238 |
239 | 240 |

Follow-up Resources & Materials

241 |
    242 |
  • 243 | You may find it useful to review this handout on the the creation of your Contributing.md 244 | file in light of your new understanding of your users. 245 |
    • 246 |
  • 247 | You may also want to revise your proejct description to better appeal to your users, using this handout. 248 |
    • 249 |
250 | 251 | 260 | 261 |
262 | 263 | -------------------------------------------------------------------------------- /wow-schedule.md: -------------------------------------------------------------------------------- 1 | ##WOW SCHEDULE 2 | 3 | ###DAY 1: FRIDAY 4 | 5 | ####Arrivals & Breakfast 6 | *8:30am - 9:30am* (Breakfast served at 9:00am) 7 | 8 | ####Welcome & Intros 9 | *9:15am - 9:35am* - Short intros: name, affliation, project, interest (30 sec each!) 10 | 11 | *9:35am - 9:40am* - Introducing the Open Leaders Cohort Program 12 | 13 | *9:40 - 10:00am* - Diversity & Inclusion Exercise 14 | 15 | **Break** (25 mins) 16 | 17 | ####How to Open Your Project 18 | *10:15am - 12:30pm* 19 | 20 | **Short Talks** (10 mins each - 30 mins total) 21 | 22 | * Readme and project communication (Zannah) 23 | * Roadmapping (Abby) 24 | * Contributor Guidelines (Aurelia) 25 | 26 | **Break** (15 mins) 27 | 28 | **Work Session** (1 hour 45 mins-ish) 29 | 30 | * small groups of 3 to 4 31 | * facilitator-led work zones for Roadmapping, Readme, Contributor Guidelines 32 | * participants move from zone to zone to work on deliverables, for as long as needed; check-in at 30 min mark 33 | * facilitators provide one-on-one feedback and guidance 34 | * cross-group work is welcome, for feedback and discussion 35 | 36 | **Feedback/reflections** (20 mins) 37 | 38 | ####Lunch 39 | *12:30pm - 2:30pm* 40 | 41 | ####Tools for Collaboration 42 | *2:30pm - 5:30pm* 43 | 44 | #####GitHub for New Project Leads and Contributors (Abby, Zannah, Joey) 45 | **Short Talk with Demo** (20-30 mins) 46 | 47 | * intro to version control, model, uses, 48 | * putting our checklist and new docs in github 49 | * basics on branches, forks, merges, pull requests 50 | * polite collaboration 51 | 52 | **Break** (25 mins) 53 | 54 | **Work session/small groups** (1 hour 45) 55 | 56 | **Feedback/reflections** (20 mins) 57 | 58 | 59 | ### DAY 2: SATURDAY 60 | 61 | ####Arrivals & Breakfast: 62 | *9:00am - 9:30am* 63 | 64 | 65 | ####Community Building and Managment 66 | *9:30am - 12:30pm* 67 | **Short Talks** (10 mins each - 30 mins total) 68 | 69 | * Code of Conduct (Kaitlin) 70 | * Event Planning (Madeleine + Arliss) 71 | * Personas and Pathways (Zannah) 72 | 73 | **Break** (25 mins) 74 | 75 | **Work session/small groups** (1 hour 45 mins) 76 | 77 | ####Lunch 78 | *12:30pm - 1:30pm* 79 | 80 | ####Open Data & Data Reuse Plans 81 | *1:30pm - 2:45pm* 82 | 83 | **Short talk** (10-15 mins) 84 | 85 | * Open Data and Data Reuse Plans (Steph & Christie) 86 | 87 | **Work session** (45 mins) 88 | 89 | **Wrap up** (10 mins) 90 | 91 | ####Closing 92 | *2:45 - 3:00* 93 | 94 | 95 | -------------------------------------------------------------------------------- /writing_readme/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Open Project Communication 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 30 | 31 |
32 | 37 | 38 |

Open Project Communication

39 | 40 |
41 |

42 | Create a useful and welcoming readme file for your open project. 43 |

44 |
45 | 46 |

For beginners

47 |
48 |
49 | 50 |
51 |
52 |

Format

53 |

54 | This exercise works well as an in-person or online exercise. You can work alone, or in a group. 55 |

56 |
57 | 58 |
59 |

Target Audience

60 |

61 | Project leads 62 |

63 |
64 | 65 |
66 |

Materials

67 |
    68 |
  • A computer and an internet connection.
    • 69 |
  • An open project you want to tell people about.
    • 70 |
71 |
72 |
73 | 74 |

Introduction

75 | 76 |

77 | When you open your project, you may have a specific audience in mind (for example, software developers or other researchers in your field)... but you can reach a much broader community! Many people outside of your field-- designers, technical writers, citizen scientists-- may be interested in your project and have valuable contributions to offer! Clearly communicating information about your project in simple language is an excellent way to grow and diversify your community.

78 | 79 |

The readme file is one of the first things you add to your project repository. It introduces your project idea and goals. Along with the contributing file, the roadmap, and your Code of Conduct, the readme file helps welcome, orient, and encourage newcomers to participate.

80 | 81 |

The following steps are designed to help you create an effective readme file. First, you'll use a tool called Open Canvas to define and organize key information about your project. Then you'll write a readme file and test it for clarity, using an online text editor that encourages the use of simple language.

82 | 83 |

Steps to Complete

84 | 85 |
    86 | 87 |
  1. 88 |

    Create an Open Canvas for your project

    89 |

    90 | Open Canvas is adapted from Lean Canvas, a one-page format used for describing a start-up business project. Open Canvas helps you clarify the problem you aim to solve, the solution you propose, and what is especially valuable about your open project. It also helps you define your users and contributors, measurements of success, and any resources you'll need. 91 |

    92 | 93 |

    Here is an example of an Open Canvas grid filled in for the Mozilla Science Lab's Paper Badger Project:

    94 | 95 | 96 |

    Here is a link to a Google Sheets version of the Open Canvas you can copy and edit online. Go to File > Make a copy... to start editing.

    97 |

    Here is a link to download a pdf version of Open Canvas.

    98 | 99 |
  2. 100 |

    Write

    101 |

    102 | Using the information you gathered in the Open Canvas exercise, write your readme file. Be sure to:

    103 |
      104 |
    • Say hello! Welcome people to the project.
      • 105 |
    • Show what you're doing, for who, and why.
      • 106 |
    • Explain what makes your project special, useful, exciting!
      • 107 |
    • Show how to get started using or contribution to the project
      • 108 |
    • State what resources and contributions you're looking for
      • 109 |
    • Point to other key resources, such as a contributing.md file and a roadmap.
      • 110 |
    111 |
    3. 112 | 113 |
  3. 114 |

    Remove Jargon!

    115 |

    116 | Copy your new project description (what you're doing, for who, and why) and drop it into the Up-Goer 5 text editor. Try to rewrite the description using only allowed words. This is a great way to identify technical language that will confuse newcomers. For reference, here's an example of a rocket ship diagram communciated in common language. 117 | 118 |

    In your final readme text, don't restrict yourself to only the most common words--if you do, your project description may become overly simplified and limited. Use what you've learned from this exercise to keep your readme as jargon-free as possible. If you use jargon, be sure to define those words.

    119 |

    120 |
    4. 121 |
  4. 122 |

    Re-write

    123 |

    124 | Re-write your entire readme in clear language and define all terms. Share your new readme in your project repository. 125 |

    5. 126 |
127 | 128 |

Glossary

129 |
130 |
131 |

Readme file

132 |

133 | a document that introduces an open project to the public and any potential contributors. 134 |

135 |
136 | 137 |
138 |

jargon

139 |

140 | a type of language, especially vocabulary, that is particular to a certian trade or discipline, and is not understood by anyone outside that discipline. 141 |

142 |
143 | 144 |
145 |

repository or repo

146 |

147 | a collection of documents related to your project, in which you create and save new code or content. 148 |

149 |
150 |
151 | 152 |

Follow-up Resources & Materials

153 | 164 | 165 | 174 | 175 |
176 | 177 | 178 | --------------------------------------------------------------------------------