[crossfire] Organizing efforts, was Re: Project: New Intro

[Alex Schultz]

Mark Wedel wrote:
>   The original mail in question had what I really two different topics - one for 
> the idea of redoing what players see when they connect, and a second about group 
> efforts to get things done in a timely fashion.  This mail more focuses on how 
> to do group efforts - ideally to come up with some scheme that can be used as a 
> model, because as Ryo pointed out, there are lots of big projects on the list 
> beyond just a new starting village.
>   
Indeed I did have those two topics combined in there. Indeed there are
lots of other big projects, but I was just trying to pitch what seemed
most reasonable to me to be a starting place :)
Perhaps I may have been somewhat hasty in rushing to trying to suggest
one particular project, however I was rather anxious to see things
happen and I was, and still am, concerned that the decision making
process could be too slow or even stall.

>   Some projects/changes may have dependency issues (rebalancing spells should 
> likely be done after redoing classes/races as an example). Those need to be 
> identified and ordering sorted out.
>   
Perhaps map out all proposed big projects in including their
dependencies, and create a sort of vague roadmap which could be posted
on the site somewhere, which would be revised to include a marker for
what is the current project once it's been agreed on. Perhaps this may
sound a touch overengineered, however I think that such a roadmap could
be made quick and simple with Graphviz and would make it easy to see
what priorities and possible future priorities may be including
dependencies. Anyways, this little paragraph of mine is getting a little
off topic into the technical implementation details which are of
relatively lesser importance.

<snip>

>   In this particular case, I agree that a new intro should be something at the 
> top of the list.  But going forward, I think we need some way to decide what is 
> done.
>
>   In the context above, developer is anyone that is willing to help out to get 
> the project done - doesn't mean coder, could be map maker, artist, person 
> writing documentation.  but someone that just plays the game probably shouldn't 
> be included, as that isn't going to help get the project done - my idea here is 
> that you want the project decided on by those actually going to do the work. 
> One the project is decided on, all are welcome to pitch in ideas, etc.
>   
Yes, this makes sense: That the project would be decided on by those who
feel committed to trying to do what they can for the project that is
decided on.

>   So after the project is decided, there needs to be a project leader.
In some ways, it may make sense to have project leaders decided before
the project, in that each proposed project prior to deciding which one
would have a developer assigned to the project who feels competent with
the project at hand and comfortable with the leadership role, which may
often be whoever had the biggest hand in proposing that particular
project. This might shave a little time off of deciding on a project
leader and avoid disputes, though it may not, but just a thought.

> Depending on the project, what that means may vary.  But I would say that the 
> leader should come up with a plan detailed enough that it can be divided into 
> work by several people.  An example would be maps - having broad outlines of 
> what should be done is a good starting point, but having a 1 or 2 line 
> description of what is needed on the maps then provides folks enough detail to 
> work on it.  For coordination, putting this chart on the wiki, and people 
> signing up for parts of it is probably a good way to go.
>   
Yes, agreed. And just as a little note/tip/plug, dependency charts of
tasks within the project could also be done quick n' dirty with Graphviz
in a clear format if the project leader believes it would be useful :)

>   I tend to think that it is best of the project lead starts by sending out a 
> fairly detailed document - the reason I say this is that a fair number of 
> developers have been around a long time, and can probably come up with a fairly 
> complete starting plan without a lot of input.  They should still send that out 
> and get input, but having a good starting point may trim a week or two off the 
> discussion, and also provide a clearer picture to everyone what the idea is. 
> Some of the basis here is also that some points have already been extensively 
> discussed in the past - new points are welcome, but we don't necessarily need to 
> fully discuss all the issues again.
>   
Yes, this makes sense to me

>   Once the plan is more or less agreed to (hard to get 100% agreement), people 
> start working.  In fact, work may start before this, as there may be some points 
> which everyone is in agreement on, and it may be more adding new points/details 
> to the plan.
>
>   The role of the project lead/coordinator is to take the pieces and make sure 
> they all work.  In the case of the map example, look over the maps, make sure 
> they meet various standards, basic idea behind the map, and link up the exits, 
> etc (possible that some maps completed before the ones they link to).
>   
Indeed, this type of role is important (and is some ways something I
feel we've been lacking to an extent in the project in general)

>   All projects should be worked on until fully done.  If a new NPC speech method 
> is done that requires modifying the NPCs, it isn't sufficient to put that new 
> support in and modify the NPCs in scorn and say 'it is ready' - that project 
> isn't done until all the NPC's on all the maps are updated.  Otherwise, past 
> experience shows that those other NPCs probably won't get updated.
>   
Yes, we often get too much in the way of sparsely used features and this
policy may help avoid that (hopefully).


Alex Schultz