RFC: Core issue queue office hours and 'triage team'

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Posted by catch on July 27, 2011 at 4:26am
Last updated by krina.addweb on Thu, 2016-02-18 13:32

Update

First office hours are this week, see http://drupal.org/node/1242856

A few of us have been discussing in irc ways to improve the triage of the core issue queue.

The proposal

Several times per week, people join #drupal-contribute and ask for help getting started contributing to Drupal. Depending on who's in the channel at the time, they might be pulled into reviewing a specific core issue or contrib module, writing documentation, or if the channel is quiet just ignored.

To help structure this process better, we're proposing holding 'core issue queue office hours' a couple of times per week (or more regularly if enough people volunteer). This is not a new idea, Views already has a bug squad, jQuery has a bug triage team (and fancy graphs), and the Usability team and some Drupal 8 initiatives are holding regular office hours or irc meetings.

There is no 'core development team' as such, however there are people who regularly work on core issues, as well as people who are regularly in the #drupal-contribute irc channel. For new contributors, it is not at all obvious who those people are, or how to get involved. Regular office hours will make it easier for people to join the effort.

Goals

There are a few different goals:

provide a way for new contributors to get involved in a more structured way.
actually get the core issue queue in better shape
set up something that happens regularly, has its own momentum, and does not have a single person as a bottleneck as far as possible.

Background

Drupal 8 and 7 now have 'issue thresholds', where a mini-code freeze is instituted if the number of critical and major bugs and tasks goes over a certain limit. This doesn't guarantee that any particular bug gets fixed, but it prevents new features being committed if there are too many serious unresolved bugs and clean-up tasks in the system.

This (so far) works for major and critical issues - at least in the sense that new issues in those queues tend to be closely scrutinized, and core committers give them priority. While the thresholds were being discussed, and shortly after they were agreed, the number of major bugs and tasks in the queue was reduced from over 300/150 to around 100 - due to a combination of recategorising issues, closing duplicates, and some of them actually got fixed as well.

However the 'normal' and 'minor' bug queues have no such thresholds (nor would it be possible to set a meaningful one with more than 2,000 in there).

There are over 2200 open bug reports against Drupal 8 and 7.

There are over 1750 open bug reports against Drupal 6.

There are over 500 patches at "needs review" status against Drupal 8 and 7.

Nearly 200 bug reports against Drupal 6/7/8 have 0 replies.

Why is this a problem?

There are a large number of duplicate issues in the queue. There are dozens of people who regularly contribute code to core, and hundreds over the course of a major release cycle. This means it is very easy for different sets of people to spend weeks, months, or even years working on the same bug in different issues - each without knowledge of the other. This not only wastes people's time, but in some cases (especially low traffic issues) people working on the bug may be completely separated from others who are reporting or confirming the bug and could test patches.
It can be demoralizing to contributors to post bug reports and get no response.
It can be demoralizing to contributors to post patches and get no response.
Some important bugs get 'lost' amongst all the others, then when they're eventually found get promoted to major/critical status and can hold up releases.
patches that are left untouched in the queue at CNR or RTBC status for a very long time go 'stale' - develop conflicts due to changes elsewhere, update numbering goes out of sync etc.. This adds a lot of overhead to each individual issue. Triage doesn't remove the problem of conflicts in general, but could increase the velocity of each individual issue.
new contributors who would like to help with patching core can be overwhelmed by the number of issues, and sometimes end up jumping in on an issue that should long ago have been closed.

How is triage done currently?

Core triage over the past few years has generally been done by a few regular core contributors, usually taking an afternoon or so out of actually working on patches to 'attack' the queue overall. This never scaled particularly well but has become increasingly unmanageable over the past 2-3 years as the amount of core issues in general has increased significantly.

There are also occasionally 'sprints' at Drupal camps, DrupalCons etc. on particular areas of the core queue. In person sprints are great but do not necessarily suit the way the core queue works (where issues tend to take a few days, weeks or months before resolution). Also sprints (rightly) tend to focus on getting patches written for specific issue, rather than focusing on the issue queue as a whole.

What will happen during 'core issue queue office hours'?

While this hasn't happened yet, the general plan is that experienced contributors mentor new people who want to get involved in the core issue queue. 'Experienced' and 'new people' does not necessarily mean 'chx' and 'newbies' though.

Tasks that can be done, this isn't an exhaustive list but gives an idea:

verifying active bug reports, marking 'needs more info' if they look invalid, closing duplicates etc.
writing up steps to reproduce and issue summaries
writing up change notifications for issues that have been committed
reviewing patches
re-rolling patches
writing test cases for bugs

This is the kind of thing that could use more documentation, there is some at http://drupal.org/project/patch but it is out of date and incomplete. We also need some dedicated documentation for the core issue queue since it has its own conventions. We could improve that documentation during the office hours as issues come up :)

A great place to start is to read Jacine's post about using GIT and creating Patches

Who's needed?

To have effective office hours, we need at least the following two kinds of people to be around:
- Those who are familiar with core APIs should be available to answer questions/clarify specific issues - some core issues are a bit esoteric.
- Those who are familiar with tools like git, patch, dreditor and setting up LAMP stacks on Windows/Mac/Linux should be available for people who don't have a suitable local environment for core patch review.

We also need to promote the office hours, so that people who are interested show up (whether brand new contributors or people who want their own patch reviewed etc.).

Volunteers so far

catch
sun
chx
Aurorus
HedgeMage
lyricnz
marcingy
linclark
davereid
cweagans
xjm
beejeebus
karschsp

Just these people are spread over multiple continents and time-zones, so we've started a doodle. At this stage we're trying to find overlap on weekly/daily availability rather than set actual dates/commitments. Adding yourself to the doodle does not mean you have to turn up at all those times or guarantee availability, it is mainly to find good time slots that may suit multiple people.

http://www.doodle.com/xk6s3yq8u76c2u2q (switch to the weekly view to see the time slots)

Ideally we'll set up two or more slots per week, with at least three volunteers per slot. Ones the slots are set we can then advertise this more widely and get it rolling.

This write up is based on (but not at all the same as) some piratepad notes worked on collectively by some of the people listed above, see http://piratepad.net/5wC7N6kF15.

Comments

From the doodle so far, the

Posted by catch on July 31, 2011 at 1:31pm

From the doodle so far, the following days times look most likely at the moment (all times in UTC):

Monday 4pm

Tuesday 4am

Tuesday 4pm

Wednesday 4pm

Thursday 4am

Unless that changes dramatically, how about Tuesday 4am and Wednesday 4pm (UTC)?

Wednesday 4pm UTC works for

Posted by linclark.research on July 31, 2011 at 2:06pm

Wednesday 4pm UTC works for me.

Let's try to start this next

Posted by catch on August 3, 2011 at 3:25pm

Let's try to start this next week (9th August), will figure out somewhere to put an announcement.

My journey to my first Drupal Core patch submit

Posted by tsvenson on August 2, 2011 at 12:03am

I am definitely someone who would benefit enormously from the ideas and goals in this proposal. The best way I can think of right now is to simply describe the how my journey was when I decided to seriously give it a shot and create patches to improve Drupal Core myself. Hopefully it will give you an idea about how difficult it can be to get a development environment up and running.

I have been experimenting with Drupal 7 for over a year as a site builder to find the right mix of contributed modules to build a foundations for several sites I am working on. My goal was to create a set of Features modules to allow me to more rapidly get new sites up and as much as possible be able to reuse functionality between them.

Its also been a lot of testing with various combinations to allow enough flexibility so that the look, feel and user experience can still be tailored for each sites specific needs.

One such area is user management, including such things as how users can create accounts and also maintain their profiles. Drupal 7 has fantastic improvements when it comes to be able to make really good looking profiles, being easily organized in the Manage Fields/Display tabs. Then adding the power from http://drupal.org/project/field_group module to it and its all of a sudden possible to organize a users profile in horizontal/vertical tabs, add CSS classes and a lot more without the need of a single line of custom code (except CSS).

However, when I added the http://drupal.org/project/realname and created First and Last name fields I ran into a big problem. I wanted those fields at the top of the edit page, but when I did that I discovered that several user settings Drupal Core provides is not available on the Manage Fields tab. The result was that those missing fields randomly could pop up at almost any weight position when a user clicks edit in their profile. They would change position almost every time I made changes to the order of those that are available in Manage Fields.

The core fields I discovered so far missing is Overlay settings, User picture upload and Signature settings.

In my case I got something like this:

1 - First name field
2 - Core user field (User picture upload IIRC)
3 - Last name field

It was simply impossible to have First name and Last name after each other...

I practice, this renders the whole Manage Field tab/Field Group features useless since I wont be able to place any of those three fields where I want them, for example under separate tabs using Field Group.

So, I did what I usually do and went to the Drupal Core issue queue and filed two feature requests:
http://drupal.org/node/1176556 (overlay module)
http://drupal.org/node/1176562 (user module)

I also filed similar feature requests for contribs that also added user settings, but was not available under Manage Fields. First it was XML Sitemaps User sub module, but when greggles added it to Comment Notify, http://drupal.org/node/1176546#comment-4754212, and I looked at his patch I realized that this looked simple enough for me to try and fix myself for the above two issues I had filed 1.5 months earlier.

Before going into that, I need to explain that for over a year, more seriously after the great git migration, I have from time to time looked at various IDE's for developing Drupal code.

But since I have a windows computer, it has been far from easy to find something that works. Especially when it comes to git. First I made a serious effort with Eclipse. I was able to get most going there, but it has a very bloated and confusing UI. Now I am using Netbeans and I really like its UI, its so slick and polished.

The problem though, is that git support for both are far from ready. In Netbeans case I am running on the bleeding edge nightly builds of the upcoming v7.1 release. Its the only one I found where cloning for example is actually working.

However, it has been extremely difficult to find good documentation and/or tutorials to get to understand git, how to manage my clones and so on. I don't know how much time I have spent on trying to figure out how/if its possible for me to be able to for example have Drupal 7.x, 8.x and the current official checked out at the same time. That is, being able to work with files in all three of them at the same time. I have asked in IRC as well, but not really got answers that made it easier to understand if that is possible.

Some have recommend that I skip the UI git support in Netbeans and instead use a CLI. So I have tried that too, including Cygwin and via the http://drush.ws/drush_windows_installer (yeah, trying to get Drush working on win as well).

There are a lot of documentation scattered all over the Internet and d.o, a lot has been helpful, such as the excellent Netbeans configuration page at http://drupal.org/node/1019816. Theres also http://drupal.org/project/nb_templates that I will use. Besides that, its been very difficult to find answers to my, IMO, basic questions.

The parts where I really struggle though is git. It really is difficult to setup and get working on Windows. I do manage to clone Drupal projects, switch between revisions and all that, and even generate the patches in the end so I could submit them two the issues above. Once I actually got to writing those patches, it took me less than an hour to do both, including testing using greggles patch as template...

But, I know that I am not using git properly when it comes to how to best manage my cloned projects, how to work with different branches, versions, if its even possible to work with two (or more) versions at the same time without having to commit the changes before being able to switch.

Basically everything around how to manage the git repositories so that I can most effectively work with them and still be able to keep them synced with the main repositories etc. Right now I am definitely spending (wasting) more time doing things wrong than on actual coding and learning about both Drupal Core and contribs.

I would be very happy to work with any git expert on creating a complete n00b guide for how to work with it on Windows, both when it comes to the plugin for Netbeans and a CLI based one.

This guide needs to contain everything from how to organize the local repositories, clone projects, switch between branches, apply and create patches (including how to set author/committer correct for my d.o git account) and all the way to committing changes back do d.o.

I believe there are a lot of people like me with limited knowledge about this, but enough skills to be able to start with using the copy and paste technique, as I did for my patches. But without a very big effort getting an IDE and git going it is going to be a very big task to overcome for us.

The Netbeans configuration page (see above) was incredible helpful. It took me only 5-10 minutes to complete it and make my installation 100% Drupal tailored. It would have taken me days probably to figure that out on my own, reading the Drupal coding standard and then figuring out where (if) to change those settings.

I hope this gives a bit of insight to the struggles many will face when wanting to give contribution to the community a shot.

So, if anyone wants to work with me on this I'm here and willing to get started...

--
/thomas
T: @tsvenson | S: tsvenson.com

Great tutorial to get up to speed on git and patching

Posted by tsvenson on August 3, 2011 at 4:22pm

Jacine posted a wonderful tutorial about how to work with git and patches for Drupal. A lot of my questions got answered in it. You can find it at http://jacine.net/post/8419331209/patches

--
/thomas
T: @tsvenson | S: tsvenson.com

What about non bug fix pacthes?

Posted by tsvenson on August 2, 2011 at 2:14am

I found my way here via a link catch posted in a comment on chx post Is it time to fork Drupal?.

In a comment on that post, I listed some metrics about the D8 patch queue.

Of the 1,422 issues with patches, 661 is classified as bugs. Which leaves 761 patches as non bugs (all but one tasks or feature requests).

1/3 (264) are still needing review. While many are being worked on recently, the time when the patch was submitted quickly gets older and older for a lot of them. The oldest is 1 year 35 weeks...

I don't have the skills or experience regarding the the overall complexity of these patches, nor the implications they would have when/if committed to core. But, skimming over the titles, I can easily see that a lot of them would greatly improve Drupal for many aspects, and certainly also reduce the amount of support needs that often triggered the developer to submit the patch.

While the ideas and goals of this proposal is great, I can't help than read it as it is very tailored to patches fixing bugs. Also, reading the release notes for each point release of Drupal 7 also shows that practically every issue listed is a bug fix.

While fixing bugs of course is very important, I also believe we would have a lot to gain from paying more attention to non bug fix patches. Often they add missing pieces preventing features to be fully usable, leaving the site builders to either keep a patched version of core maintained, or find a workaround outside core.

In the end this also add more support issue tickets, forum posts and other things that will take time for users to tend to. It also makes using Drupal to build sites more complex due to these workarounds needed.

As I understand it there are not really any official teams delegated to review patches, catch even explained it to me as "many patch reviews only happen due to trades (I'll review your patch if you review mine etc.)".

If that is how it works in reality, then it makes much more sense to me that there are over 1,400 patches in the queue and growing.

As the proposal says, there are many efforts being made to improve this, but they seem to me be more short term solutions. Could even be compared to email spam, when a big botnet is taken down, the amount of spam decreases a lot, but soon they are back on the same level again as new botnets pop up...

Something new is needed to properly sort this out. For example, someone with authority should be able to make decisions about patches and say, yes this patch is important for improving Drupal Core and once approved it will be committed, while another patch might be a good idea, but wont be possible to add until later...

Basically, be able to create a shortlist of patches that will be committed as soon as possible (when ready) so the author knows that. This shortlist should not be limited to just bug fixes, but also important improvements that will make Drupal work better but not big enough to have to wait until the next major release.

As mentioned above, just looking through the non bug fix patches, I could easily spot many with titles that makes a lot of sense to get in ASAP, but they get stuck in the queue because there is no one that reviews them...

Frankly I think its a waste of the efforts the authors are doing. Not only that, leaving them in the queues wastes more precious time/resources due to all the support issues they would have prevented...

--
/thomas
T: @tsvenson | S: tsvenson.com

bugs vs. tasks and features

Posted by catch on August 2, 2011 at 3:42am

I agree that the number of patches in general needing review is an issue, the two areas where I think this could make the most difference are these:

reduce the number of issues in 'needs review' state.
reduce the number of untriaged issues, for me I'd rather start with bug reports since they run the most risk of causing problems when overlooked or left unfixed for ages, and there tend to be a lot that could just be closed (as duplicate or 'cannot reproduce').

In terms of Drupal 7, the reason there are only bug fixes mentioned is because Drupal 7 is supposed to be a stable release without getting new features or API changes added (with some exceptions, but those exceptions are mostly still in the queue and are not end-user facing). Tasks and feature requests are for Drupal 8 at this point, where progress has been slow, partly because it has been slow, partly because the past month or so there has been http://drupal.org/node/1201874 in place and we've been over the thresholds.

Even if the 'office hours' only ended up being an official 'matchmaking' time for people to swap patch reviews, that would be an improvement over now, so reducing the CNR queue is definitely in scope. I may try to update the original post to reflect this a bit better.

Drupal Core needs non bug fix improvements too

Posted by tsvenson on August 2, 2011 at 12:10pm

reduce the number of issues in 'needs review' state

Well, at the moment the only way to reduce them is if someone, not the patch author, does review and test them. However, in most cases the result will only be that they instead end up with the status changed to "reviewed and tested by the community". A small step in the right direction, but in reality nothing that will actually help users get a better Drupal experience...

reduce the number of untriaged issues, for me I'd rather start with bug reports

I got absolutely no problem with that, as I have stated in other comments. Bugs has to be fixed.

But then, for some issues/patches I would argue that there is a very thin line between if the issue is a bug or a feature request. It will depend on how you look at it.

For example, the two patches I mention in My journey to my first Drupal Core patch submit I filed as Feature requests. But I could have just as easily put them as bugs instead. After all, without those fixes in core, the Manage Fields tab becomes practically a useless feature as soon as I need to enable a core feature that doesn't have the support for it. The Manage Fields is a core feature, the hook function to make settings available for it is also a core feature. Most importantly, the core user Edit/View features are basing its order on it. That then important core features, such as the User picture upload and Signature settings doesn't implement them, at least in my mind could easily be seen as a "bug". Especially looking at how other issues are classified as bugs and then committed for the next point release.

In terms of Drupal 7, the reason there are only bug fixes mentioned is because Drupal 7 is supposed to be a stable release without getting new features or API changes added

I am aware about this rule. But when I skimmed over the issue queue for non bug fixes, there where loads of them that wont break any API's. Committing them to core might mean some websites does need to make a small amendment to the configuration, but in extremely few cases would they break the site functionality.

I was quite involved in testing and trying to help as much as possible with getting the new Update Manager fixed before D7 went RC. Some progress was being made, but it is still severely broken in many aspects and unless you understand exactly how to use it, you actually risk downgrading contribs using it.

I also discovered that in some cases, when a contrib and core module shares the same name, Update Manager will actually update the core module, not the contrib module. That bug is still not fixed as far as I know! What makes that even more astonishing is that Update Manage doesn't even support updating core!!!

Or another example, when you do use it, it will take your site into Maintenance mode, but if you read the messages it outputs on the screen, your site is automatically brought out of Maintenance mode once the code for modules you are updating have been replaced with the new versions, but BEFORE you have had a chance to run update.php! I mean, how can I then even consider using Update Manager on a live site???

Just check the list on the Update status module page and see how many issues are still not fixed.

Update Manager is probably the best example of all, of a core feature that easily can be improved and receive new features between major Drupal Core releases. As far as I know, nothing in it will ever break the functionality of a site. The only thing it does is to make updating of contribs/themes easier. If something goes wrong, it will go wrong for the exact same reasons as if you did the update the old fashion ways.

However, due to the rules for what can be fixed in point releases, Update Manager will not get fixed until Drupal 8.0. Which leaves us with core functionality that are severely broken and worst of all, will at some point screw up your site unless you are extremely careful using it.

Just before D7 went RC, there where quite a lot of discussions about changing the rules about what can go into a point release. I know Webchick did participate in those as well, searching for arguments to make that possible. Unfortunately that discussion pretty much have died out...

I think we need to take a good long look at if the future of Drupal can afford point release rules that prevents improvements between major releases. Especially since those major releases are years apart!

Microsoft is notorious for mastering this, just look at IE as an example. Same with Mozilla when it came to Firefox. I have seen Drupal being compared to this in more than one occasion. Microsoft finally woke up. Mozilla too and just look at the buzz around Firefox these days...

Sorry for ranting about this, but this is fast becoming a big issue for Drupal. Worst is that these for me are artificial issues based on historic reasons that simply serves no other purpose than taking focus away from the important things. At some point, people will start to give up. chx post is just another wakeup call about this!

This is an organizational and decision making problem. Unless its fixed there, it will only continue to grow...

--
/thomas
T: @tsvenson | S: tsvenson.com

Well, at the moment the only

Posted by catch on August 2, 2011 at 12:32pm

Well, at the moment the only way to reduce them is if someone, not the patch author, does review and test them.

Yep.

However, in most cases the result will only be that they instead end up with the status changed to "reviewed and tested by the community".

More often they end up as code needs work - it is usually easy to find defects in a patch, even without much patch review experience.

At least one of the patches you filed is a very good example of why we need more core issue queue triage, looks like a duplicate of http://drupal.org/node/967566

Actually, both are dupes to

Posted by tsvenson on August 2, 2011 at 12:54pm

Actually, both are dupes to http://drupal.org/node/967566. I will mark them as such. I do make as much effort as possible to search for existing issues before I file a new one.

The issue was filed November 10, 2010 when Drupal 7 was in beta2.

I also read through the issue and the comment and found this comment:

The problem is quite simple.
Your patch adds new translatable strings. And that is not allowed in a stable version.

Yes, we have that rule. But what I simply have bigger and bigger problems to understand is why a rule like this is going to keep existing when pretty much everyone within the community realizes it simply hampering the progress of Drupal. In fact, I would go as far as say it is making Drupal less competitive on the market.

That Drupal has a great momentum and is growing is not an argument against this. Our biggest competitors, Wordpress and especially Joomla, are increasingly improving their code base and feature sets. Looking at adoption, Drupal is still way behind both of them. Joomla is now on a 6 month release schedule, with LTS releases every 18 months. Both are introducing new improvements in every release they make.

Drupal is the only one that actively prevents improvements between major releases. Major release that has years between them.

Can we really afford this on a market where so much new technology is introduced on a daily basis?

In this case, the above bug should have been marked as an RC blocker until fixed! Simply because that would have been the only way to comply with the API/String rules!

--
/thomas
T: @tsvenson | S: tsvenson.com

For string freeze you want

Posted by catch on August 2, 2011 at 1:00pm

For string freeze you want the discussion at http://groups.drupal.org/node/154304

One step ahead of you, see

Posted by tsvenson on August 2, 2011 at 1:08pm

One step ahead of you, see http://groups.drupal.org/node/154304#comment-514894 :)

--
/thomas
T: @tsvenson | S: tsvenson.com

Issue summaries

Posted by xjm on August 8, 2011 at 7:03pm

I wrote up a super-extended version of the IRC factoid:
http://groups.drupal.org/node/167534

Could be helpful.

New to Core stuff + Travelling: How long will Office Hours last?

Posted by TransitionKojo on August 9, 2011 at 12:32am

I've never done ANY sort of Core ANYTHING other than install Drupal core. I'd like to participate in BOTH of the office hours, but I just saw the post last night (I'm in Japan; 9:21am JST here) and I'd planned to travel today. Office hours will start at 1pm JST, but I'm wondering how long they'll last. I can pop into an internet cafe in Nagoya to get online. But I'd hate to show up at 2pm JST and find everyone has "gone".

Also, the post I saw here (http://drupal.org/node/1242856) said

New contributors should already be prepared to do the following:
- Have a local environment to review and test core patches."

How are we defining that? What do I need beyond a local install of D6 or D7? Do I need to have GIT setup on my machine? What do I need to have setup to be helpful, contribute and get the most out of this experience? I'm running OS X and I've got MAMP, so a local install is no problem. I could even go Quickstart if needed.

The 4pm UTC Wednesday (16:00 UTC...sorry, I'm American, we're goofy like that) is more convenient (01:00 JST, I'm sure to be in my WiFi bubble at "home"), but I figure if I can get things worked out at 04:00UTC Tuesday, I'll be ready to hit the ground running at 16:00UTC Wednesday.

So, in summary:
1. What do I need to have setup as a Newb to actually make a contribution, beyond a local Drupal install of D6 & D7?
2. If I show up at say, 05:30 UTC, will it be "too late"?

Thanks!

How long it goes on for

Posted by catch on August 9, 2011 at 2:15am

How long it goes on for depends who turns up, but I'd expect at least 2-3 hours. I'm also in JST and I'll be on-line/irc at those times even if I might not be focused on the office hours the whole time.

It's worth adding a Drupal 8 install to your Drupal 6 and 7 installs since most patches target D8, but you don't need to since plenty of patches still apply to D7.

Git is useful for rolling and re-rolling patches but it's not required to be able to do anything at all, being able to apply patches with patch -p1 is a more fundamental requirement. It's also possible to triage the core queue without any local environment at all so depends what you're interested in doing :)

Thanks!

Posted by TransitionKojo on August 9, 2011 at 2:35am

I've already 'found' you in IRC. Trying to get wokr out the whole repository cloning issue now.

I'm ready to contribute!

Posted by nneka on August 9, 2011 at 4:39pm

Missed the Tuesday office hours. Plan on attending the one scheduled for Wednesday @ 12pm my time. Going to review the Drupal Core issues queue and dig in. Any questions I have I'll bring them with me tomorrow. I've set up many sites using drupal and written custom modules, where needed. It's time I give back....especially now that I have the time.

Went well today :D

Posted by xjm on August 10, 2011 at 6:55pm

We had several people triaging the queue and others co-authoring issue summaries. Yay!

Please include dates when you

Posted by benjifisher on August 13, 2011 at 3:26am

Please include dates when you update http://drupal.org/node/1242856 with new office hours (unless the office hours repeat weekly).

It can be demoralizing to contributors to post bug reports and get no response.
It can be demoralizing to contributors to post patches and get no response.

I agree. It is not clear (to me, at least) whether I am allowed to mark issues as RTBC. (According to this comment in the Bartik queue, "Needs signoff from jensimmons or Jeff Burnz before RTBC.") If my patches get no response and I am not qualified to mark an issue as RTBC, what can I do?

I disagree with requiring one

Posted by catch on August 15, 2011 at 3:53am

I disagree with requiring one or two people for a patch to be RTBC. You can suggest that core committers run patches past specific individuals before commit, or sometimes they will do that themselves, but RTBC is the right status for that kind of specific feedback.

I updated http://drupal.org/node/1242856 to say the office hours will continue the same times this week.

Brain dump from IRC

Posted by xjm on August 27, 2011 at 3:04am

Make an announcement in #drupal about office hours each time
If you've set someone on a task and they go quiet, check back in and see how they're doing
Find small tasks and actively seek new contributors to work on them, like rerolling a patch or fixing a comment
Promote again on main channels like d.o and planet
Think outside the box for other ways to reach people, e.g., posting to local DUGs
IRC is actually a barrier for a lot of people; how do we fix that? (local sprints? other communication channels?)
Civility matters. Greet people. Thank people. Make sure they don't take a NW as a personal criticism but as feedback.
Bojhan: "We fix communication with handbooks. That is our communication problem."
That said, the handbook pages aren't up to date entirely either.

Another thing I've noticed

Posted by xjm on August 31, 2011 at 6:10pm

It's time-consuming and maybe off-putting for new contributors to try to find their own tasks--a link to a big list can be overwhelming. Start by giving them a specific issue to summarize/test/patch/reply to/etc.

Yeah this is a good point. I

Posted by catch on September 1, 2011 at 2:49am

Yeah this is a good point. I have done both, and finding a specific issue for someone always works out better.

Weekly announcements; Twitter

Posted by xjm on September 2, 2011 at 5:18pm

Attendance has been tapering off a bit, and catch and I think it would be a good idea to re-announce the office hours each week in a few different channels. If people don't see a reminder somewhere they follow, they'll forget, even if they know office hours exist. Suggestions we've come up with:

Announce in #drupal on IRC 15 mins. before office hours start and again when they are starting.
Post a short announcement through Planet each week.
Announce the office hours on twitter from @drupalcore.

For the tweet, I'd suggest:

Weekly core office hours start in 15 min. Join us in IRC or tweet with #drupalcore to contribute. See http://bit.ly/pxOC1h for more info!

This tweet is sent out at 0345 Tues UTC and 1345 Wed UTC. (@chx: this is 8:45p Monday and 8:45a Wednesday in PDT; ignore the nonsense I said on IRC.)

(Note that I deliberately left #drupal-contribute out of the tweet so people don't confuse it with a hashtag.)

Which brings me to the second point. Several of us talked the other night about the barrier IRC creates for some people. Ideally we'd want them in IRC, but if IRC doesn't work for someone, they can tweet with #drupalcore that they want to participate and one of the mentor team will reply to them directly to help them find a task, etc. I even made a stupid twitter account just so I can do this during the Wednesday office hours if needed. :P

IRC channel topic

Posted by xjm on September 7, 2011 at 4:25pm

ksenzee added this bit to the beginning of the channel topic during office hours:

Core office hours going on right now! If you're here to help, introduce yourself and we'll help you get started.

#drupal vs. #drupal-contribute

Posted by xjm on September 28, 2011 at 6:17pm

Today we held office hours in #drupal rather than #drupal-contribute. We got a lot more visibility; there were 7-8 participants rather than the usual 1-2. (It helped that webchick was trading support for office hours work.) ;)

I think we should give it a try in #drupal again next week and see if we want to move it there permanently. Folks facilitating don't need to be in #drupal all the time; just for the duration of the office hours (~1-2h). We'd want to update the announcement if so.

A lot of people were also trying to join #drupalcore in IRC. Darn twitter for using the IRC channel signifier. =/ We might want to change the tweet to explicitly state that it's a hashtag and/or clarify the drupal channel name.

We could also create that IRC channel and have the channel topic be "See the #drupal-contribute channel."

Tweet text

Posted by xjm on September 28, 2011 at 10:01pm

People retweet the tweet at random times after the fact, so maybe better to tweet at the start rather than in advance. Trying to clarify the hashtag vs. IRC channel crap:

Core office hours are happening now! Join us in #drupal in IRC or tweet with hashtag #drupalcore to contribute. See: http://t.co/3fcfAdMs

#drupal-contribute hash tag

Posted by valthebald on September 29, 2011 at 9:05am

May be just use #drupal-contribute hash tag in twitter? Requires no change in IRC...

We wanted to do that originally, but...

Posted by xjm on September 29, 2011 at 3:55pm

Hashtags can only be alphanumeric, so the hyphen breaks it and it ends up being #drupal. (Which is too noisy to follow.)

In #drupal

Posted by xjm on October 13, 2011 at 9:46pm

I've been able to get a lot more people involved by holding the office hours in #drupal and putting a message in both channel topics, so we're doing that henceforth. It has the additional advantage of exposing the larger community to the idea of helping with core. :) (I've been doing a bit of soliciting people in both channels during the time window.)