Heads up, this content is 9 years old. Please keep its age in mind while reading.

Over the last sixteen months, I’ve been working with a great group of people to build and nurture a new project: the Genderplayful Marketplace. This online marketplace celebrates diversity in gender presentation and body types. It rallies a community to work collectively on the question, “How can we build wardrobes we love that fit our bodies well?”, and it offers extra encouraging support for trans, genderqueer, and gender nonconforming folks (an identity set that we define very broadly). The project was inspired by what we’ve learned in our work at Genderfork.com.

The Process

The Genderplayful homepage, in private beta

It started with a fundraiser last year. I promised that we would build the marketplace if we raised $5,000, and we received such a strong show of support that our final total was $8,000. Since then, we’ve just been chugging along, step by step, trying to stay focused on the goal and not get discouraged by the sheer size of it (and all of those damned possibilities that would make it so much better except when they really just make it feel more daunting).

For the first six months, we focused on the tech foundation — WordPress Multi-Site, Buddypress, and Marketpress, coupled with Linode and Springloops — and we worked with designers to build our visual experience. Then we pulled in a bigger volunteer staff to jumpstart our social media presence (meet our Tumblr, Twitter, and Facebook accounts — each building their own collage of creativity, curiosity, and community style). We also assigned volunteers to help get our forums going, set our first vendors up with storefronts, develop a community blog, curate some featured content, keep the tech development moving forward, and keep our newfound team happy and healthy.

On January 15th of this year — one year after we finished our fundraiser — we opened our creaky doors to community members who’d supported us along the way for a Private Beta. And now we’re cleaning up, tweaking settings, building missing features, helping vendors settle in, and populating the site with the kind of culture we believe in.

Slowly, but surely. But slowly. Sure.

The Laws of Volunteerism

Featured sellers, community blogging

Eight grand is enough money to deal with legal and financial requirements, to cover tech account costs, and to hire the few services that you can’t easily request from volunteers. (It also buys t-shirts, which were part of the deal for getting community funds in the first place.)

It is not, however, enough money to also hire a staff or fund a professional web development job. And that’s fine — we didn’t ask for that level of support to begin with — but it does mean that everything we do is subject to the Laws of Volunteerism.

These laws, as far as I can tell, are as follows:

Law #1: Our predicted involvement will be bigger than our actual involvement. The energy and excitement that we have at the beginning of a project is rarely sustainable at its peak levels, and the actual time we can invest in a project over the long-term needs to have a realistic bare minimum.

Law #2: We will mostly do things that are either urgent or methodical. Give us a fire to put out, and we’ll jump on it. Give us task to repeat every week, and we’ll turn it into a habit. But ask us to think about something new every day without attaching a major deadline to it?  Yeah, sorry, we’d love to, but maybe you can find someone else to jump in…

Law #3: We need to see that our work is helping others in order to keep doing it. I think the single biggest mistake we made in the first year of Genderplayful was not creating a smaller version of the marketplace that we could release much sooner. As volunteers, we are fueled by the positive impact we have on others, and we lose momentum when that’s harder to see.

Law #4: Real life will get in the way. Job stress, moving, breakups, illness, overwhelm, family issues, school, travel, projects, personal transitions, and other forms of Real Life don’t stop knocking. Ever. Volunteering is a commitment, but it’s a rather secondary commitment to, say, staying alive and healthy, and we have to remain flexible as our own availabilities change.

All of these things have happened to all of us on the project, and they hit our tech team and our organizing/leadership energy the hardest. Which leads me to…

SHAMELESS PLUG! If anyone would like to offer their reinforcements in these areas, please first consider the Laws listed above, and then fill out our “SEND IN THE REINFORCEMENTS!” form with how you’d like to help.

Dreaming vs. Doing

When it comes down to it, we’re still walking and still building, even if it’s messy, slow, and quiet in the darkness some nights.

Ideas are fun and cheap, and Great Ideas are worth doing. Doing, however, requires pushing through every form of resistance your brain can come up with, withstanding the stretch of real timelines, and ignoring all those new fun cheap ideas that show up every morning and tempt you to do something new. Doing a Great Idea (as opposed to just any old idea) helps with that last part, but it still takes force, conviction, and faith to get to the finish line.

And we’re getting there. Soon*, you’ll be able to see and experience all the wonders (or at least the highest priority ones) that we’ve been imagining all along the way.

* “Soon” implies no specific timeline. (We know better than that by now.)

Heads up, this content is 11 years old. Please keep its age in mind while reading.

Quick Backstory:
This is a finicky evaluation of online project management systems, taken slightly out of context. I originally published it a few weeks ago via “Dopp Brain“, my email newsletter, which I’m writing for more often than I’m blogging right now. If you miss hearing from me, go sign up for that. I’m working on some infant/sensitive projects right now, and am preferring to talk about everything just a little less publicly for a bit.

But somebody just asked me about this overview, so I’m making it public now.

~~~~~

When we last heard from our hero, she was neck deep in trial accounts for online project management software…

Man, that was not a fun game.  But it was absolutely worth the digging.  Here’s what I learned (besides the fact that I am the Donald Trump of Project Management System Evaluators):

FIRED

Basecamp: It’s everybody’s golden child, but damnit, I can’t stand it.  Something about how the information is laid out just doesn’t fit how my brain works.  The Writeboards, which should be a centerpiece, are so far out of the way and take extra time to load that they feel like a disconnected afterthought.  The dashboard and calendar views are unreadably cluttered, and the task lists are clunky.  Fired.

Wrike: Oh, this one had so much potential, it broke my heart.  Completely fresh layout — they organize everything by Folders and Subfolders rather than Projects and Clients, so you can decide how your own work needs to be structured.  They also allow you to record the same task in multiple folders, so it’s cross-referenced against what it needs to do.  The only downside? It’s all about tasks.  And it takes a few too many clicks to enter a task to warrant that single focus.  There is a space for notes and discussions, but those are hidden away and hard to find — which is bizarre and completely unecessary.  I thought i was going to strangle it for that, so… Fired.

DeskAway: This one and I almost got married.  I had loaded up all my projects and we were halfway to the chapel (my tux looked great) when I realized that its Dashboard view of the All Tasks Due Today doesn’t let me mark tasks as done.  SERIOUSLY!  It’s just a summary — you have to click through to each task in this weird convoluted way to mark a task as done — so there’s no homebase area that you can hang out in and just be productive.  The other thing that bugged me was that the list of “Overdue” tasks included Today’s tasks.  You don’t get to tell me that something due today is overdue. And by the way, I lied, I don’t really like Bob Dylan and I don’t want to live in your stupid house with the stupid white picket fence and look at your stupid face all day long and this engagement is OVER. Fired.

Pelotonics: By this point, I was jaded.  I knew my standards were too high, and I was a little too familiar with the ejection button.  There was no passion here.  Just a bland dinner, a glimmer of hope (integrating with Evernote? Sweet…), and a quick dismissal based on a flat excuse.  I can’t add a new task from the Dashboard view. There. I said it. None of the other systems would let me do that either, but it seemed as good enough an excuse as any to end that date before we got any further.  It’s not you, it’s me. Let’s just be friends.  Trust me. You don’t want to get involved with me anyway. I’m bad news. I kill systems.  Just ask the others. Go. Now. Before we do something we’ll regret. You’re fired.

After I drowned my system incompatibility sorrows in several regrettable rounds of Chat Roulette, I got back on the horse.  I’m a reasonably attractive, successful consultant — I have a good personality, damnit!  There are plenty of fish in the sea!  Maybe I’m just using the wrong pickup line. Should I change my soap?

To cut to the chase, I put on my best “fine, i’ll be more agreeable this time” face and put together a hybrid solution:

HIRED

Remember the Milk for task tracking.  But not all tasks.  Just the tasks that aren’t part of any scheduled projects and still need to get done by a certain day.  I added the widget to my Gmail sidebar and configured it to only display tasks that are due today or are overdue.  I can check things off as I go, and I can add new things super-quickly when they come up. It works fabulously.

PBWorks Business Edition for project notes and collaboration.  It’s a wiki built for project management, and it’s yummy. I can have a different wiki for each project, and pull in guest collaborators for specific spaces only.  Bonus features: it has task lists (though they’re not any better than all the other system tasks lists I fired), and I’m using those to keep track of project requirements.  It also has this really sexy conference call feature, where it will call as many people as I want to have a meeting with on their telephones and bring them into a zero-hassle conference call.  And the best part about a wiki is that it has all the content I need, and none of the content I don’t need.  Win.

Google Calendar for scheduling work sessions. I’m blocking out time on my schedule for working on different projects. Old school, I know, but it works.

Emma, aka “Girl Friday,” aka “Queen of the Wikis” for tying it all together. (*joyful choirs erupt in praise*)  Emma’s a kick-ass project organizing consultant who is keeping the wiki and calendar updated, and making sense of new projects as they come in. You might also know her from KinkOnTap, the weekly webcast about culture, sexuality, and politics that she co-hosts and organizes.  She’s an awesome one, she is.

And there we have it.  That, plus some Gmail and Freshbooks is the organizational ground I’m standing on.  So far so good.

Heads up, this content is 12 years old. Please keep its age in mind while reading.

Over dinner last Thursday night, maymay and I spent several hours discussing what makes a Good Web Development Team, based on our particular work styles.  Here’s what we came up with (refined from a crude notebook sketch):

collab-webdevteam

Particular things to note here…

  • All team members have direct access to one another, and are encouraged to work together in real-time.  Quality assurance, scope agreements, user experience development, and engineering development all depend on direct collaboration.
  • D@n has already pointed out that we left out Sys Admin.  That’s a good point, and it should probably be its own person, with direct lines to Front-End, Back-End, and Project Manager.
  • He also expressed concern about QA not being a specific person.  I stand by the current model for dev teams that don’t aspire to grow any bigger than the setup above — peer-checking is sufficient.  As maymay put it, “QA is a state of mind.”  It’s always happening, and it can be structured to happen systematically.
  • Job roles and personal skills don’t always perfectly align. In my case, I can play both Front-End Developer and Project Manager, each with a particular flavor.  And maymay can take on both Front-End and Back-End Developer roles if the expectations are right.  But for both of us, it seems the case that if we only have to take on one role per project, we’re able to do better work.

This is just an abstract exercise in theoretical structuring based on our experience — not meant as anything to be set in stone. Take it for what you will, and feel free to expand on it.

Enjoy!,
Sarah