Coder army - thinking out loud

[lgromanowski]

One thing I'm curious about, is, as we find more people or grow, how to effectively manage things and keep tasks organized. I know this doesn't seem like an immediate problem, and I tend to look way far ahead on these things, but I like to make others think, so I thought I'd make a thread for it and see what everyone thinks about it and think out-loud myself about it.

Currently, there are 7 tasks for 009. Github lists 11 people. In an ideal environment, we're already done.

but that's terribly unrealistic, right? I mean, this isn't our job. We have lives to live and bills to pay. It's be silly to delegate tasks as part of a hobby, else we have very low expectations should anyone be inactive or get hung up with a technical problem.

So having someone delegate tasks looks like trouble.

huh...
One thing I'm a fan of is the "welcome package". To make two rather funny comparisons, one would be for the last job I had, which, as part of their orientation, would introduce me and show me around and get me familiar with a lot of things before I even worked. Even though it was very formal and hard to care about, it's one of those things that are essential - you are usually better off with them than without them.

Then there was the time I re-subscribed to EQ2. I joined the EQ2 chapter of a large guild I was a member of - nice, nice people. They got me set up and edu-ma-cated about all the changes very well, and it was very enjoyable. I had a blast, and everyone was great.

so - with that sort of example set up - I am now talking about two things:

First: How we generate, track and manage tasks with our team as it grows
Second: How we get members into our team and participating.

The obstacles to both of these would be:
- Here, we all are hobbyists first.
- We are on the Internet - our communication is very limited.

Even if it's found we shouldn't or can't realistically implement some things, we've now discovered two very important obstacles that, if overcome, would be enough to make everything else less painful.

Any thoughts?

- Here, we all are hobbyists first.

I think we have quite a few professional coders here.

We are on the Internet - our communication is very limited.

That is a statement I so do not agree with. I think for this kind of work Internet is superior to personal interaction. It is slightly slower paced, which allows for more thought out and condensed communication.

Really, I don't see any problems here. git and github already offer the tools to manage a larger number of contributors. Besides the build issues on Windows there isn't an obstacle for new people to get in either, at least if they work at professional level. The code is documented well enough and the overall structure pretty clear (with a couple of minor exceptions).

- Here, we all are hobbyists first.

I read Star-Demon's comment a bit differently than Zini. I've got professional coding experience, but at the moment this is certainly a "hobbyist" project for me.

When I first read this thread and a lot of tech lead / project management ideas jumped to mind. And I quickly realized that the 'professional' approaches I had in mind wouldn't likely be a good fit. The reason: an solid team plan is one you have high confidence in when the various tasks will be done and tested so that dependencies between tasks can be managed correctly. In an unpaid, non-contractual, hobbyist environment, you cannot ask anyone to provide the level of commitment necessary to construct such a schedule.

For this kind of environment, I would guess the best fit would be for the experts to generate as many small (< 1 week), easy, self-contained, well-described tasks as possible for others for the OpenMW non-experts (e.g. me) to pick and choose from at random. The developers who are doing the majority of the coding (e.g. Zini) probably have a pretty good idea of what needs to be done and don't really need a detailed task list to work from.

So my two cents about what would help with your concerns:

- "Experts" should intentionally leave TODOs and stubs in the code and write up on the wiki what a non-expert would need to do to complete that task and test that it is actually correct and complete. This frees up time for the experts to work on the architectural tasks that require a better understanding of the "big picture" of the code.

- No one should spend too much time on a elaborate, formal plan because it'll be impossible to stick to it on a volunteer project

I read Star-Demon's comment a bit differently than Zini. I've got professional coding experience, but at the moment this is certainly a "hobbyist" project for me.

Well, that is certainly not my definition of hobbyist. For me a hobbyist is someone who either doesn't have the competence to work on a professional level or someone who is simply slacking.

For me the only difference between OpenMW and RL work is, that I invest less time into OpenMW and that it has a lower priority if more than one task requires my attention at the same time. If something is worth doing, then it is worth doing right.

Ok, well the actual definition of hobbyist says nothing about skill level: http://dictionary.reference.com/browse/hobbyist. It's about pursuing something primarily for pleasure.

pursuing something primarily for pleasure

is what I would call slacking (for some definitions of primary). But let's not get into this further. I think we understood each others point.

I read Star-Demon's comment a bit differently than Zini. I've got professional coding experience, but at the moment this is certainly a "hobbyist" project for me.

Definitely more what I had in mind, considering the context when it was mentioned. Professionals or not, this isn't our job.

In an unpaid, non-contractual, hobbyist environment, you cannot ask anyone to provide the level of commitment necessary to construct such a schedule.

Exactly what I meant when I mentioned settling for low expectations. How to get around that?

For this kind of environment, I would guess the best fit would be for the experts to generate as many small (< 1 week), easy, self-contained, well-described tasks as possible for others for the OpenMW non-experts (e.g. me) to pick and choose from at random. The developers who are doing the majority of the coding (e.g. Zini) probably have a pretty good idea of what needs to be done and don't really need a detailed task list to work from.

That makes a lot of sense.

So my two cents about what would help with your concerns:

- "Experts" should intentionally leave TODOs and stubs in the code and write up on the wiki what a non-expert would need to do to complete that task and test that it is actually correct and complete. This frees up time for the experts to work on the architectural tasks that require a better understanding of the "big picture" of the code.

- No one should spend too much time on a elaborate, formal plan because it'll be impossible to stick to it on a volunteer project

That sounds really good - strikes a balance between keeping things open and keeping things on task. We should do that.

That is a statement I so do not agree with. I think for this kind of work Internet is superior to personal interaction. It is slightly slower paced, which allows for more thought out and condensed communication.

There is nothing that replaces being face-to-face. While I'll say we've developed powerful tools to enhance our reach and perhaps organize our written communications, it definitely cannot overcome some serious obstacles that only face-to-face communication can solve for a team that is working together. I haven't discussed it at length, but forums and email are highly inefficient, and there is a lot of room for misunderstanding and disorganization.

Really, I don't see any problems here. git and github already offer the tools to manage a larger number of contributors. Besides the build issues on Windows there isn't an obstacle for new people to get in either, at least if they work at professional level. The code is documented well enough and the overall structure pretty clear (with a couple of minor exceptions).

I can't downplay the issues on windows. I think they are a very serious obstacle because a large amount of people are on windows, and, conflicting expectations of professionals and hobbyists aside, anything that makes the project harder to get into at any level is something that needs to be taken seriously.

Also - I don't believe Mushroom Management is a very good way to invite people to work in a community that isn't paying them to be there. This is not Red Hat. I'm doing my part to make strides so, even if the problems of windows remain (which, given our progress, likely won't), they are easily negotiable, and we are still well-served by caring for Windows' 90% market share. There's nothing more important than making things easy and friendly for everyone that encounters this project on all levels.

I read Star-Demon's comment a bit differently than Zini. I've got professional coding experience, but at the moment this is certainly a "hobbyist" project for me.

Well, that is certainly not my definition of hobbyist. For me a hobbyist is someone who either doesn't have the competence to work on a professional level or someone who is simply slacking.

It's certainly possible (and, for cynical gamers like myself, apparent!) that professionals can be quite lacking in competence, drive, and motivation. As well, if one can be called a professional and not be paid for work, then I really need to rewrite my resume.

For me the only difference between OpenMW and RL work is, that I invest less time into OpenMW and that it has a lower priority if more than one task requires my attention at the same time. If something is worth doing, then it is worth doing right.

It's a good thing that you take the quality of what you do very seriously - however, I don't think it would be right for anyone to say that people not as devoted to an Open Source project as they would be devoted to the work that feeds them and their families are not serious, or are doing things wrong. It's just not true.

Hey guys, let's split more hairs!

In all srsness though, you guys should do less nit-picking of each other and more working together. I'm not pointing fingers because no one's really to blame, it's a pretty normal Open Source Project phenomenon. However as OpenMWs resident cheerleader I wanted to put in some positive energy.

SO ?????????? WEE OMG RELEVANT LINK

Hi,

I like the way this project is going forward, there was a lot of enhancements recently. About open sources projects for the ones who don't know about it, you shoud read http://catb.org/esr/writings/homesteadi ... ral-bazaar.

It is clear that OpenMW project has a clear vision of the goal to reach, the WIKI and this forum are the place where we share ideas.

I think the net is the best way to work together on an open source project, too close devs in the same place could result in much more noise and a lower efficient organisation.

perhaps http://www.pivotaltracker.com/ can help? I started using it for some projects, its ok, has its drawbacks but for a project that does not have to keep track of $ I think it could be really useful.

Thanks for the link, but we don't need help in this area. The tools we currently use (git, GitHub, wiki, forum) work very well.

Thanks for the link, but we don't need help in this area. The tools we currently use (git, GitHub, wiki, forum) work very well.

uhh I though someone was just asking for help with tracking features and whatnot. github chat isn't good for that. I guess the forum and wiki would work but don't you think povitoltracker is going to be better for tracking features?

its free. did you even look at it?

uhh I though someone was just asking for help with tracking features and whatnot

That was a mostly theoretically question, I guess. Or aimed at a time when the size of the developer team has grown greatly.

a) I don't see that happen, considering the current amount of developer fluctuation.

b) I suspect our current infrastructure will scale rather well, so even if it does happen, there is no need to look for alternative solutions.

I guess the forum and wiki would work but don't you think povitoltracker is going to be better for tracking features?

I don't see why we would need a feature tracker. The wiki roadmap works well enough.

its free. did you even look at it?

Only had a very short look, since I don't see the need for improvements to our infrastructure and my time is a bit limited right now. Really, this whole thread is about a problem that does not exist yet and maybe never will.

Thanks for the link, but we don't need help in this area. The tools we currently use (git, GitHub, wiki, forum) work very well.

They work well when used and implemented well - Right now I'd say the wiki doesn't help us at all because it's incorrect and unfriendly. We can fix that, though, with some work. I've been quiet lately, but that's because of real life. My first order of business coming back is to write a lot and take another look at what we got when the character creation windows are in good shape. I'd like to use them as examples for future work, so please make sure they are fully internally documented and look very pretty.

TBH I really liked Athile's idea and I think we may need to start using it sooner than we might think now. I'm sure there will be a point where Zini and Nico will feel disproportionally responsible/burdened for the code. It would make sense if we could use every person one could see on github more effectively and still have room to suit all of our lifestyles.

This takes human effort, not a piece of software.

That being said, everyone is welcome and encouraged to post suggestions for tools that we may or may not know about that will help us do a better job. Already we've had two or three successful suggestions. That's really good.

In fact, I'll make a thread right now for that.