Core office day (DrupalCon Denver sprint)

Events happening in the community are now at Drupal community events on www.drupal.org.
xjm's picture
Posted by xjm on March 4, 2012 at 5:10am
Start: 
2012-03-23 09:30 - 17:00 America/Denver
Organizers: 
xjm
tim.plunkett
linclark
kbell
cweagans
Event type: 
Sprint

Our Core office day sprint has been selected as one of the featured sprints for DrupalCon Denver.

It's probably a good idea for the sprint co-leads to meet and chat about stuff earlier in the week. My availability:

Let me know what time(s) work for you.

The basic idea is that we start off with a presentation on the who and how and why, and then spend the rest of the day helping people get set up to work on issues, mentoring them, and helping them find and handle various core queue tasks. Below is a rough outline for the presentation part and how the sprinting would work--please add any suggestions!

Part I: Introduction (slides/demos)

(Edit: I'm kind of lame with slides, so if someone is good at that please feel free to put yourself in charge of that.) ;)

Introductions and sprint goals

  • Intro; where you can find this info after the sprint
  • Help you help with core
  • Background: mention core office hours
  • Like that, but in person and fun!
  • Resolve outstanding issues in Drupal 7
  • Make “room” for Drupal 8 development
  • Prioritize major and critical issues
  • Clean up the queue
  • Speed up issue turnaround

Why we’re doing this

  • Core office hours
  • It can be hard to know how/where to start contributing, especially for core
  • 9000+ open issues filed against Drupal core
  • Perception that core is hard, but many issues don’t actually need a ton of expertise

The core queue

  • Show how to get to it
  • Issue fields
  • Core structure (component and branch maintainers)
  • How issues are filed & backport policy
  • Coding & documentation standards
  • Testing policy

How testbot works

  • Automatically tests files with the extensions .diff or .patch.
  • Patches should be created using git or they will fail to apply.
  • Testbot tests against current issue version (so will fail to apply if it was created for a different version)
  • "Green" means the patch passed all existing assertions. (Does not guarantee that the patch is bug-free!)
  • "Red" means the patch failed one or more existing assertions. (Link to view detailed results.)
  • Testbot also runs new tests added in a patch, so it is a common practice to upload a test-only patch to expose test failures before a bugfix is applied.

Core tasks (briefly explain what’s involved for each and introduce docs)

Part II: Getting set up

  • Drupal.org account
  • Showing contributor links on the Dashboard
  • Finding the core queue, git instructions, etc.
  • Setting up a development stack (brief explanation of what & why--help individually later)
  • Installing git (what & why)
  • Installing Drupal from git
  • Brief mention of IE testing
  • Installing dreditor
  • Text editors -- use whatever you prefer; recommend Sublime Text 2 for beginners
  • Mention IRC

Part III: Sprint!

  • Help people take care of stuff in Part II. (Help me here. I hate installing stuff, tinkering with my stack, or dealing with other operating systems, so if someone else could be a go-to for those tasks that would be awesome.)
  • Separate working spreadsheet for each level task.
  • Some will be pre-populated with specific issues to work on
  • All will include links to find more issues
  • Columns with yellow header text are editable
  • Put your name next to the issue you’re currently looking at (even if you’re not sure you’re going to do it)
  • Mentors help everyone pick issues; guide through handling.
  • Try to get some experienced core contributors working in the room too to attack harder problems in the queue and foster community.

Comments

I'll be in on Sunday

Posted by cweagans on March 4, 2012 at 9:09am
cweagans's picture

I'll be in on Sunday afternoon at the Melbourne (~8 blocks from the convention center). I'm pretty much available most of the time - I'll probably be in the Core Conversations track most of the time.

Who is going to be speaking for part 1 and 2?

I'd be glad to help with non-Windows machine dev environment set up. I haven't touched Windows in years, though, so I'd prefer to stay away from that.

--
Cameron Eagans
http://cweagans.net

It'd probably be me speaking,

Posted by xjm on March 4, 2012 at 12:06pm
xjm's picture

It'd probably be me speaking, though it'd be cool if anyone else wants to do part of it, or even just stand there and make snarky remarks. (I'm not nearly as, um, rapid-fire in person as I am over the phone, and apparently "enthusiastic.") ;)

I haven't touched Windows in years, though, so I'd prefer to stay away from that.

Wouldn't we all...

My schedule looks a lot like

Posted by linclark on March 4, 2012 at 2:33pm
linclark's picture

My schedule looks a lot like yours, xjm, so I'm pretty available.

If people don't already have the stack installed, would it make sense to advise them to install Acquia's Dev Desktop? I did a screencast on installation back when it was the Stack Installer (~2 years ago), but haven't touched it since. It was really easy back then, at least.

It apparently has XHProf automatically installed, so we could possibly demonstrate how to test performance impact if we want to. There is also this gist for installing XHProf with PHP 5.3 on MAMP 2.

I created

Posted by xjm on March 6, 2012 at 7:12pm
xjm's picture

I created http://drupal.org/node/1470720. I'm working now or adding or updating the new contributor documentation for each task.

I think the Acquia Dev Desktop is a good choice. webchick checked yesterday and it supports PHP 5.3, but needs to be configured to use it when installing. I'll try to test it later this week.

Maybe we could even get

Posted by linclark on March 6, 2012 at 7:44pm
linclark's picture

Maybe we could even get someone who works with Acquia on promoting the Dev Desktop to come for an hour or two and offer support for people who have trouble setting it up on their systems.

I'd like to suggest that we

Posted by cweagans on March 6, 2012 at 7:53pm
cweagans's picture

I'd like to suggest that we point users to the Drupalize.me videos on setting up a local web server: http://drupalize.me/blog/201203/our-local-web-server-videos-are-now-free

--
Cameron Eagans
http://cweagans.net

Wednesday at 6:00p?

Posted by xjm on March 20, 2012 at 11:48am
xjm's picture

Shall we meet in the coder lounge at the end of sessions on Wednesday (6:00p)? We can hang out, talk about stuff, and maybe grab some dinner. Let me know if this works for you.

Works for me. See you then!

Posted by cweagans on March 20, 2012 at 4:18pm
cweagans's picture

Works for me. See you then!

--
Cameron Eagans
http://cweagans.net

That works for me.

Posted by linclark on March 20, 2012 at 2:13pm
linclark's picture

That works for me.

Just made a Planet post

Posted by xjm on March 20, 2012 at 10:55pm
xjm's picture

http://xjm.drupalgardens.com/blog/friday-march-23-drupal-core-mentoring-day

Of particular note:

Help us find target issues.  We're prioritizing majors and criticals tagged for backport first, and normals and minors tagged for backport second.  Take a look through the core queue and see if you can find issues  that would benefit from any of our office hours tasks.

  • Find issues that need tests and tag them "Needs tests".  
  • Find frontend and UX issues, and tag them with "Needs manual testing" and/or "Needs screenshot". 
  • Find patches that no longer apply and tag them with "Needs reroll".
  • Find issues with incomplete, unclear, or outdated summaries and tag them with "Issue summary initiative".
  • Find issues with patches that need straightforward cleanup or fixes (such as documentation, code style, or simple refactoring), tag them with Novice, and (in this particular case) tell me about them.  (Just post a link to the issue on the groups post).

Really going to sleep now. :)

Just added

Posted by xjm on March 21, 2012 at 11:39am
xjm's picture

Find backportable issues missing the "Needs backport to D7" tag and add it.

.

Posted by xjm on March 21, 2012 at 11:36am
xjm's picture

I've now woken up with this thought three times, so I am going to post it in the hope of more contiguous sleep. :P I had a conversation with someone at webchick's session yesterday that reminded me how challenging trying to parse an issue can be when you're just getting started with core, so for the super-novice contributors among those who choose to work on A, I think we might want to suggest working on issues in pairs or something. That way they can do things like co-author the issue summary, bounce ideas off each other, and research unfamiliar topics together.

Agreed

Posted by kbell on March 22, 2012 at 8:32am
kbell's picture

+1. Angie and I discussed this idea at length back during DIWD NYC, and agreed that a "pair programming" approach might be really useful for novices.

Sorry I didn't make it tonight, had a client meeting i had to attend that was on the schedule before tonight's time was suggested. And notifications aren't working for me on this thread for some reason, so I didn't even know I'd missed anything until Jess told me via email - my bad.

See you all on Friday!
Kelly

--Kelly Bell
Gotham City Drupal
twitter: @kbell | @gothamdrupal
http://drupal.org/user/293443

Remaining tasks

Posted by xjm on March 22, 2012 at 9:58pm
xjm's picture

<

ol>

  • Each pick a brief issue/story about getting involved in core to share during our intro.
  • Finish populating the new spreadsheets. Andrea, can you invite Kelly to the doc and also share them publicly for participants tomorrow?
  • Write new contributor task docs explaining:

    Reference:
    http://drupal.org/node/1424502
    Link them in the tables at:
    http://drupal.org/node/1470720

  • A couple of us should test learndrupal.org instructions for installing git and setting up the dev desktop:
    http://learndrupal.org/lesson/8daa1222-481d-fc54-a9bf-9d9ccc1ae702
    http://learndrupal.org/lesson/027b5839-7a74-af04-6905-fee2d01c7ef4
    NOTE: we want to install D8 from a clone of 8.x, NOT from the dev tarball.
  • Create doc with links to the stuff incl. working spreadsheets--I'll do this
  • Kinda break down who will do what
    • I'll intro the session
    • We tell our issue stories
    • Lin, do you want to talk about how to create a d.o account, set up dashboard blocks for contributor links and core issues, explain the issue queue, issue fields, etc.?
    • Someone explains the backport policy
    • Someone explains coding standards/documentation gate (not the details, just that they exist) and points them to the relevant docs.
    • Someone explains the testing policy
    • I'll do the brief rundown of the different tasks and the "pitch" for each

    • I'll see you if/when I wake up this evening; otherwise please do me a favor and make sure everyone reads this. :)

    Remaining tasks

    Posted by xjm on March 22, 2012 at 9:58pm
    xjm's picture
    1. Each pick a brief issue/story about getting involved in core to share during our intro.
    2. Finish populating the new spreadsheets. Andrea, can you invite Kelly to the doc and also share them publicly for participants tomorrow?
    3. Write new contributor task docs explaining:

      Reference:
      http://drupal.org/node/1424502
      Link them in the tables at:
      http://drupal.org/node/1470720

    4. A couple of us should test learndrupal.org instructions for installing git and setting up the dev desktop:
      http://learndrupal.org/lesson/8daa1222-481d-fc54-a9bf-9d9ccc1ae702
      http://learndrupal.org/lesson/027b5839-7a74-af04-6905-fee2d01c7ef4
      NOTE: we want to install D8 from a clone of 8.x, NOT from the dev tarball.
    5. Create doc with links to the stuff incl. working spreadsheets--I'll do this
    6. Kinda break down who will do what
      • I'll intro the session
      • We tell our issue stories
      • Lin, do you want to talk about how to create a d.o account, set up dashboard blocks for contributor links and core issues, explain the issue queue, issue fields, etc.?
      • Someone explains the backport policy
      • Someone explains coding standards/documentation gate (not the details, just that they exist) and points them to the relevant docs.
      • Someone explains the testing policy
      • I'll do the brief rundown of the different tasks and the "pitch" for each

    I'll see you if/when I wake up this evening; otherwise please do me a favor and make sure everyone reads this. :)

    I'll take Coding Standards/docs

    Posted by kbell on March 22, 2012 at 11:58pm
    kbell's picture

    I'll be happy to explain the standards/docs gate and grab links.
    -K

    --Kelly Bell
    Gotham City Drupal
    twitter: @kbell | @gothamdrupal
    http://drupal.org/user/293443

    Can someone invite me as

    Posted by kbell on March 23, 2012 at 12:00am
    kbell's picture

    Can someone invite me as kelly@gothamcitydrupal.com? I can't get in with the other address because of my Google Apps 4 biz account. some stupid bug.
    Thanks!

    --Kelly Bell
    Gotham City Drupal
    twitter: @kbell | @gothamdrupal
    http://drupal.org/user/293443

    Done

    Posted by ZenDoodles on March 23, 2012 at 2:40pm
    ZenDoodles's picture

    Hi Kelly,
    I added you again. Also, the public link is:

    https://docs.google.com/open?id=0Bx4VPptjRWQ6S205cWVQRXhSbktTc2dPT0hROEFNUQ

    I may be running a bit late, but I'm hoping not.

    Testing

    Posted by ZenDoodles on March 23, 2012 at 2:42pm
    ZenDoodles's picture

    Zgear tested the instructions for setting up the Acquia desktop, and he's up and running with it. He didn't test git because he's already got it set up, but they look correct to me.

    Are we in 601? Elsewhere?

    Posted by kbell on March 23, 2012 at 3:20pm
    kbell's picture

    What room are we in? I can only find reference to 601.
    Thanks,
    -K

    --Kelly Bell
    Gotham City Drupal
    twitter: @kbell | @gothamdrupal
    http://drupal.org/user/293443

    Retrospective

    Posted by xjm on April 29, 2012 at 12:28am
    xjm's picture

    Hey folks,

    I’ve had this 3/4-written post sitting on my laptop for nearly a month. I'd like to ask people to post their feedback about the sprint on this thread so that we can use our experience to help others do similar things at future DrupalCons, camps, and summits. Here's a start at a brain dump--please help fill in the blanks with anything I missed! (And sorry it’s so rambly; I realized I’m probably never going to get around to cleaning it up.)

    Promoting the sprint

    We promoted the sprint in the following ways:

    Preparing for the sprint

    • We created Google docs spreadsheets with lists of issues and links to instructions for all the core mentoring tasks and bundled them in a Google Docs collection. (e.g. for writing tests). Spreadsheets included links to instructions, links to views of the relevant issues, and prepopulated lists of issues that were targeted for the sprint, plus a column for participants to assign the issues to themselves.
    • Starting Wednesday night we began tagging issues and populating the spreadsheets. (We couldn't do this too far in advance because the list would grow state.) We prioritized major and critical issues tagged for D7 backport in most categories. (For issues needing triage, we populated the list with 0-reply issues that actually needed triage, as opposed to issues filed by core contributors, as the latter are hard to differentiate for new people.)
    • We created a google doc of links that participants would need for the sprint.

    During the sprint

    • I started by introducing myself & other mentors; explained my short-term core involvement, core office hours, and why we were having the sprint.
    • Described sprint goals (as above)
    • Asked who considered themselves developers, themers, site builders, etc.
    • Shared individual “early core contribution” stories
    • Explained how to create an account on d.o (everyone had one already because of DA conference registration).
    • Explained how to add contributor dashboard block; how to find and use core queue
    • Outlined backport, testing, and documentation policies
    • Briefly outlined the kinds of tasks that we were going to do.
    • Put doc up on the screen.
    • Asked people to introduce themselves to each other and wave us down for help. I did not stop walking from person to person except for a few announcements until after lunch.
    • David Rothstein actively helped people during the sprint in addition to the six mentors we had, and Kieran did a lot of air traffic control.
    • After lunch, once everyone had gotten into things and come up for air, webchick committed a participant’s first core patch live and explained her review and commit process.
    • We had people group up to discuss/demo specific topics of interest, including writing tests, creating a patch (with projector), etc.

    Things that worked well

    • Having our own sprint room with a mic and projector was definitely a must.
    • The room was just the right size. (75% the size of the main sprint room).
    • I think our personal stories working on core really helped set the tone.
    • Asking people to work in pairs and introduce themselves to others at their tables was very successful.
    • People did a good job of helping others get their development environments set up; we should encourage that more next time.
    • Our little “mini-demos” throughout the day were definitely effective.

    Things we should have done differently

    • Do not go to restaurants an unconfirmed distance away to discuss the sprint over dinner. :P
    • Do not try to do prep work in the coder lounge; people will distract your mentors and ask you for IRL patch reviews no matter how clear you try to make it that you are trying to work on something. :P Bars and restaurants also don’t work so well. Hotel room recommended.
    • I wished I had a second laptop for the sprint information doc etc., so that I could have actually used mine during the course of the day.
    • Bit of a scare early Friday morning when we had no AV equipment. I asked for AV equipment originally and the sprint planning folk did pass this message on to the conference center, but I guess I should have been more assertive about asking for confirmation in advance of the con. (My request for confirmation during the con went unanswered.) Requesting an onsite contact name for space setup would be good.
    • People had trouble finding the room. Better signage would have been really helpful. I did tweet the room number but I should have added hashtags and crap like that.
    • People from the other sprint room didn’t know ours existed. See above about better signage.
    • Forgot to tell them about dreditor.
    • I think our initial intro went too long. Explaining how to use the issue queue, while an important part of onramping people, is probably best done in smaller groups like setting up development environments, because it’s completely monotonous and boring for people who already know what to do. It might be better to simply explain generally the “life of an issue” (active -> NW <->NR <-> RTBC -> Fixed). I also still think explaining the backport, testing, and docs policies (gates) is essential.
    • Should have had a laptop/other method for demos/doc so I could use mine at all during the day.
    • We should have had people enter their names on a list somewhere, to get an actual account of who attended.
    • The google docs, in addition to having a limit of 50 HTML import functions (for automatically populated issue data), also had a limit to the number of people who could be actively editing them at once. As a result, people could not update who was working on each issue, leading to a lot of duplicated effort and a lot of work going untracked. We’re considering a Drupal site instead (duh) to facilitate the sprint, using views, flag, Gábor’s rocketship, etc.
    • Should probably recruit more volunteers in the future so people can swap out, and especially people to review issues after the fact. I never did get caught up on reviews of the issues handled.
    • Better guidance on how to do backports, summaries, and change notifications would likely be good. (Docs are weak.)

    Some statistics in closing

    • 6 mentors, plus 3 volunteers helping facilitate during sprint
    • Somewhere between 75 and 100 participants over the course of the day
    • Participants assigned themselves 68 issues from our prepared list, plus more that went unmarked due to our technical difficulties.
    • 100% of the code reviews, novice issues, and issue summaries we’d listed were handled.

    Reviewers

    Group organizers

    Group notifications

    This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: