Thread

So, I’ve recently finished a few of my paid-projects and have decided to delve back into an old project I started - and abandoned - many years (5+ 😉) ago.

This post is looking at the documentation side of the development process and how to attract a like-minded developer (something I’ve yet to figure out).

I put up a wiki for it here: http://wiki.geeklan.com/d20ocmt (and if you have any ideas for a name for this project - throw ‘em at me. I’ve been drawing blanks - d20ocmt.com just looks tacky.)

Am I approaching the documentation correctly with this project or am I going overboard?

My general approach to documentation is breaking everything down into categories, subcategories and sub-subcategories. It can make management of the documentation rough at times, but you always know where to find a piece of info. At least, that’s my logic.

——-

As to the method of attracting developers - what is the method with open source projects?

I’ve had a number of projects that have come and gone (either completed on my own or abandoned). Even with the ever important ‘proof of progress’, I’ve never seen more than fleeting interest that disappears within the first few chats.

I have a co-worker interested in my project, but only for his own specific gain - he wants to incorporate some of the ideas into his own project but doesn’t seem terribly interested on working on the project together).

I’ve been itching to go duo (or more) on a project for a long time - finding reliable people seems a difficult feat. At least in my case, it’s always been a bad roll of the dice. (Ahh.. DnD References. Gotta love it 😉)

I will finish this project on my own if I have to, but I don’t want it to be a solo project.

———

Give me your thoughts.

How do you handle project documentation?

What have your successful methods been to attract another developer (or more) to an open-source/PD project still in the mid-idea stage?

I think nothing can be over-documented.  I make the mistake of assuming that everyone thinks like I do and I don’t document things I think are obvious.  I have never been able to attract developers to work with me :/

The problem with that is so many time a question of attitude.

Already something to get real people you car in your life, so honestly is even harder to find good programmer with positive attitude out there.

I don’t think that your documentation is the problem there. You like many of us just find some pain in the ass people to work with or even worst, selfish people who just car about himself.

Work in team is a philosophy, a mentality and also a longer process to put in place, but it pay on the long run indeed. Most programmer just see short time impact of many many things indeed.

This is coming from my experience, i suppose people opinion could vary on this topic.

Concerning the documentation, honestly, if you write documentation for programmer, that have to be on API, phpdoc, or natural docs will do the job pretty well and also impose standard.

To make the follow-up, i find nothing more efficient than a good trac+svn+tracwiki. You can discuss, build, react and progress easyly with this structure.

see ya around !

Work. Ok, I’ve got a few hours to spare. How much work? Oh, lots you say? Hmmm. Well, what’s the reward? Fame? Fortune? Self gratification? Errr - you know what I mean. Oh, it’s a web 2.0 social network for knitters. Um, great.

OS projects are competing for developers and most developers would rather be part of a high profile project. There’s more fame to gain.

OS projects are competing for developers and most developers would rather be part of a high profile project. There’s more fame to gain.

This is to true.

And this project is definitely far from high profile. This is for something that’s generally considered a niche at best (Dungeons and Dragons). My whole desire for a co-dev has been someone to bounce ideas off of so I can be blatantly told how much of a retard I’m being by trying to do X instead of Z.

Never hurts to try.

Hi Awpti,

http://www.agilemodeling.com/essays/agileDocumentation.htm

A couple of years ago I was introduced to the Agile System of Documentation and I was impressed.

In a nutshell, three of us got together and decided to use Ebay to sell a digital camera program to download the photos, tweak and upload to a website.

Our Agile familiar project leader delegated the work and broke the task down to each individual.

From what I can remember:
1. Specific tasks were agreed and generalised.
2. Each item had inputs and expected results.
3. Tests were agreed to ensure the completed task was satisfatory.
4. An agreed delivery time was specified.

Surprisingly: our combined efforts achieved the deadline.
Unfortunately: we discovered to our detriment how difficult it was to make our fortunes on Ebay.
Thankfully: none of us gave up our day jobs.

The Agile site has an abundance of documentation which I am sure could be helpful in your project.