Managing the Drupal.org redesign: Prelude to a manifesto

@ceardach:

Thank you for the thoughtful and well-articulated response. I apologize that we as a team have not replied sooner. Time management is, as we've identified, one of the roadblocks to success.

I'd like to address your post point-by-point. Please bear in mind that I'm voicing my opinion -- I don't speak for the entire team. I hope they'll chime in so we can converge on some solutions.

Weekly meetings may be too often. I have found in other projects that if we meet weekly it starts eating into our productivity -- especially if we're not doing that project full time. [...]

I respectfully disagree. I dislike meetings in general, but regular, coordinated, time-boxed, and focused meetings can be incredibly helpful -- especially when we're working with a distributed team. Getting everyone "in the same room" for as little as 30 minutes a week is beneficial in three ways:

• It will rapidly bring problems, bugs, conflicts, etc. to light. If we're all working on disjointed schedules throughout the day on IRC, it's likely we'll repeat each other's work, unknowingly break something, or undo someone's changes because they didn't understand why they were implemented a certain way.
• It reminds us of our accountability to each other -- not just the project.
• Finally, it's an important team-building exercise. Not only is voice communication more efficient than typing, but speaking to one another as a team helps avoid misunderstandings. (When you know how someone sounds when they talk, you're less inclined to think they're being rude.)

So, we should enable easy and casual communication. I love IRC. Is there a redesign implementers IRC channel? If not, maybe we should have one. [...]

Absolutely agreed. IRC should be home base. I'm working on securing #drupal-redesign.

Having a scheduled "virtual code sprint", or otherwise imagined as "virtual office hours", could be helpful. [...]

Agreed. This is absolutely essential. However, we should recognize the limitations of "office hours." They do not, for example, replace all-hands-on-deck meetings. Scheduling a weekly, half-hour meeting that works for as many people as possible is going to be tough; agreeing on four office hours per week will be impossible. Due to these scheduling restrictions, office hours may overlap, but they will be largely unique for each person. They will be essential for getting work done, but they won't necessarily facilitate communication.

That said, I'd like to try and overlap office hours as much as possible.

Another thing to do is to break tasks up into small bite size chunks. [...]

Yes! Now we just need someone to break apart those chunks for everyone. :)

[... W]e could try breaking up tickets into components, site sections, and task types. That can help enable a contributor to create a view that is targeted on the types of tasks that are good for them. [...]

This is a great idea. We should definitely make more use of tagging. Can anyone volunteer to sift through the issues and come up with 3-4 (or more?) tags to categorize them?

Potentially, if we provide a view that has "exciting" things for a contributor in the list, it may avoid the chance of large or overwhelming tasks turning them off.

Can you define "exciting"? :)

So, you want this done by September 1st? We may need to plan it. Divide it up into chunks and create goals. Create deadlines of reasonable-to-accomplish tasks. If we have two week development phases, we have time for 5 mini deadlines before September. We can break things into tasks, divide into milestones, and assign tasks to individuals. If we all keep communicating openly and participate in IRC, we could potentially initiate enough inspiration and motivation for people to work to complete the milestone.

Yes, yes, yes, and yes. And yes!

And lastly... development process. Can you explain the current process in detail, and all of the problems you are encountering? What is your wishlist? How do you want things to work? (This may need to be in a different post, actually)

The purpose of this post is to do exactly this: detail all of the problems and roadblocks we're encountering. I've identified those that bug me the most above. Others will need to step in and voice their concerns.

Todd Ross Nienkerk
Co-founder, Four Kitchens | IRC: toddross

Todd - just thought I'd drop by (no pun intended)

Dropbox works fine for many users (so I'm told). The only thing is, you're limited to 2gb for the free version. Even if one person upgrades to pro, this doesn't have the same effect for everyone - they still have 2gb unless they upgrade too.

I've used it on a fair few projects with a max of 12 users (although I'm told it scales to many more than this pretty well). I'm sure I speak for most designers in saying this would certainly be preferable compared to SVN. :)

Cheers,
Mark

In regards to SVN -- why is it hidden to anonymous users? Why do they not have read-only access? I think requiring infrastructure assistance for each potential contributor is effecting the amount of contributors we'll have. No one can browse the code. My coworker applied for SVN access awhile ago, and hasn't gotten it. I applied last night, but I now have to wait until someone approves me.

But at least if people can browse the code, they can submit patches to the issue queue...

Dropbox is probably fine. I'd say the largest potential problem is someone deleting everything, or one person overwriting another person's work.

Another idea is to create a quick website we can upload files to.

I absolutely agree that we need a dedicated channel. It's always struck me as strange that we were using the infrastructure team's channel to do design and theming work. DamZ in #drupal-infrastructure told me to contact chx regarding a new, officially recognized IRC channel. (By "officially recognized," I mean adding Druplicon bot support and anything else "official" I may not be aware of.)

I'll keep everyone posted.

Todd Ross Nienkerk
Co-founder, Four Kitchens | IRC: toddross

I'm leaning against using a 3rd party tool, and sticking with g.d.o and d.o for as much as possible.

I would absolutely love to use Trac, since it has awesome flexible abilities to manage tickets (components, blockers and milestones! ::swoon::) and create views on the fly, and views targeted towards the viewing user (amplified by the ability to CC users). However... all communication really has to be in an open an archiveable place.

I am going to do my very best to maximize the tools we have before looking towards another source. And that other source I would hope would allow us to enhance the g.d.o and d.o tools available to us before considering replacements.