Looking at the terms_of_reference.rtf in CVS it is a mess that needs cleaning up before I can do a very decent job creating a [UseCaseTemplate].  This is a start to the Use Case Template, but it is wholy inadequate atm and is just a skeleton.  We need to get the demo design straightened so we can create some valid basic Use Cases.  How can you create a decent test use case if you don't have a very good picture about the demo?

In the coming days I'll be taking this document, dividing and editing it to make it a bit more clear, the initial document is the IronicDemoDesignScratchpad.  Also, some parts will likely be split into separate documents.  If you have some comments on this approach, or the [UseCaseTemplate] as it stands now I welcome comments (as always).

This is a test blog entry.

Basically I have a bunch of exams and tests to do so I have no time to work on WW really for some time now. 

Work continues apace on the IronicDemoDesignScratchpad.  It's banging into shape pretty nicely.  The goal is basically to have a document which describes the demo on a high level that is readable and understandable by River Trolls.  C'mon now, no faces like that...  I work with some river trolls, although they deny their heritage!

One of the things I'm working on some Agile Paragraphs for Matt so he can continue is design of the modular design system.  I'm also reading a bit about

While there are some really good things about these methodologies, developing things completely within a unit and waiting too long to do integrated testing seems like a potentially dangerous recipe.  We'll see...  I stil have a fair bit of reading before I make any final conclusions.

I'm also beginning to research workflows and potential quality management systems.  Hopefully this could really help our production, which has been difficult to keep at a high level.  Henri and I have already had a chat about possibilities for these systems, which includes workflows revolving around traditionally film based workflows like the concepts of developing storylines, storyboarding, storybeats, etc.  Revolving around management and process control research for me has been Lean Manufacturing, Just In Time Manufacturing and the Six Sigmas.  Detailing the exact approaches will have to wait until we have reseached things a bit more thoroughly and consulted our river troll.

Not to mention that they are often interrupted by someone having to work, eat or go to the bathroom or some such nonsense.

You can try and hold it.

What we have to realize is that the time issue is mostly beyond our control.

It is agreed that life is what it is and no one is doing this full time. It is difficult to squeeze more things done out of a given day.

1. Planned meetings.
   These we know about at least a day in advance. In my option the person who called the meeting and/or presides over it should start a wiki document or something that shortly lists points he thinks should be discussed.
   Then other people taking part of the meeting will add their ideas to the wishlist. There is a deadline on this. After the deadline and before the meeting, the presiding member will go over the list and prioritize the points.

Unless it is a very large meeting, usually this can be done just minutes before the meeting. 10 mins. before the meeting should be fine for a cutoff. Still, I wouldn't throw out a good idea for a bullet point just because they didn't meet the deadline. We shouldn't plan 1/2 the meeting this way, but the occasional item here and there can be forgiven.

We should set an amount of time that we will allow discussion on a given topic. This will help prevent needless chit chat and wandering from the subject going too far. The presiding member can extend conversations at the expense of other agenda items if most everyone agrees that it is important enough.

1. Impromtu meetings.
   For these there should always be a list of issues that need discussion..preferably prioritized to some extent.
   Of course usually the meeting is called with a purpose, so the purpose goes to the top of the list.
   Otherwise the process is the same as for planned meetings.

There needs to be an agreement about who will transcribe the outcome on to the Wiki. These types of meetings would preferrably occur on IRC, and the contents / decisions should go in the Wiki. A mention of the meeting should go in a News item, so people who didn't happen to be around at the time can still read and comment / debate the decision. Even if you think no one would be interested in the meeting, it could be useful for historical purposes and for noobs sniffing around asking, "How / why was this decided?" Go read the Wiki and / or the logs you insufferable newb!

Communication...a big problem in an inter-timezone project like ours. Again I think it is rather imporant to realize that we can not overcome the need for sleep (not for long anyway), hence some things are certainly complicated. Here are my musings on communication issues and what we should think about.

The most important thing is - how do we deal with show stopping issues?
Everyone has different times when they are free to work on WW. However interdependencies can not and should not be elliminated - just coordinated more.
So let's take some examples.

1. I get up in the morning and decide to work on WW. Say I have 3 hours of time. After 20 mins I run into a problem - a UC lists 2 contradicting conditions. Which is true? I do not know enough about the subject and can not make a decision. So I can't work on it. Now everyone else is asleep at this time so my only possibility would be to mail the person who could answer the question or a list.
   A few things can be done to alleviate this situation:
   • Have other things to work on besides this, so the available 2.6 hours are not wasted.
   • Have me understand the subject well, so I can make the decision myself
   • Have the other people answer the mail asap..since our time difference is 7h, the shortest time limit we can set is 7h..but usually it can be answered quicker and should be, just in case I have some more time available right at that moment or something like that.
2. I am working on something during the time that others are awake. I run into a show stopping issue. But noone is around on IRC. How should I contact people? IRC lag can go as high as 1.5h..people can time out or even not answer the question at all. Mail...I have had mails not answered at all..or answered in several days time..not very nice in such a situation. Blogs are even worse than mail in this regard..also private matters are not suitable for blogging for sure. So what is the solution?
3. I am working on something and know that in 2 days I will get to a certain point in development where I need component X. I have no clue about component X and how it would be made. Someone else has to make it. How do I notify them that it should be done by that time? How do we make sure it does get done?

Post your own scenarios and of course ideas for solutions.

As you've probably noticed, I've changed the theme for our space a bit to use the Left Hand Nav Theme.  I also brought over the Werewolf Logo from the old Twiki site.  I think it is a bit nicer to get around in.  Anyhow, vote if you like it better and we'll see if it stays.

We'll be having a team meeting this Saturday, Dec. 16th.  We'll be using Skype, so bring your headset.

You can see a very rough agenda here.  I'll fill out the agenda in more detail tomorrow.  It is very late and I need to get some sleep (yes, I'm weak!).

Another meetingThursday morning.  Once again on Skype and Gobby.  This time we'll continue storyboarding and work on the GUI design a bit more.

Here's the meeting agenda: Meeting2006-12-19.

Well I started thinking about the base system, as you guys might have already noticed yesterday (what with all the annoying interview scheduling and all). All in all the interview with Jason will take place on Saturday and with Matt maybe next Friday then. In the meanwhile we can map out some basic things about the game. On that note I started a lil page called ObjectsInTheSimulation. This should list all objects that can be present in the simulation and their behaviour, actions and attributes and such. Feel free to append things to this document and of group things. Basically do not fear repeating things (like rabbit, bear etc.), we can always group em later (animals). Just trying to make sure we do not miss anything terribly important.
Later on we'll classify all the attributes and objects and stuff in order to see what kinds of game objects and simulation nodes in general we need. The page GameObjects was started with that idea.
Have fun kids

Last changed: Dec 17, 2006 20:58 by Jason Oppel
We're having a meeting this Saturday.  The most important points of discussion will be the Base System Interview and a discussion about Management Systems.

View the meeting agenda here: Meeting2006-12-23.

As all of you know we have started to create the special purpose technical use-cases. Now tho I have created a parent page for em that has some basic terminology listed as well. You can find it at TechUCs
Feel free to explain terminology more nicely, add terms that you would like described and of course choose things from the ObjectsInTheSimulation page that you would like described in a tech UC. The call for expanding that page as well is still valid of course
The FireTechUC is most complete atm altho still lacking some vital info as indicated by the problems listed. I have started on a PotionTechUC but that will take some time..All in all I hope to at least fill in a few of these with Jason today. And generally I hope to get a decent amount of them done before I leave y'all for a while again.