usf-team team mailing list archive

[Kizzo Kilgore <davidpkilgore@xxxxxxxxx>]

Yeah I've been meaning to let the other devs know my most recent
thoughts - please disregard my written-down future plans for USF.  I'm
not contributing enough for my plans to really be considered (for
now), and I also feel that my plans are something too far into the
future anyway (I should worry about it later).

With regards to Git/Bzr, one way I would try to get someone to use
something I like is to make it easy for others to use it.  So I
suggest that you might want to clone the main USF branch over to
GitHub, and be personably responsible for keeping it in sync with the
(currently) main Bazaar branch.  I've been meaning to try Git, and
I've heard good things about GitHub (I wish Launchpad was more social
like that).  People may also want to check out
http://whygitisbetterthanx.com/ and
http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html
to get a better idea of the differences.

On Tue, Apr 20, 2010 at 11:31 AM, Edwin Marshall <aspidites@xxxxxxxxx> wrote:
> Tshirtman and I were in IRC discussing various aspects of the projects current status, including goals, readiness, etc. While I did answer him briefly, I think it would benefit the team as a whole if my opinions were made more public.
>
> We both agreed that the lack of momentum in development has nothing to do with a lack of helping hands. In fact, for more than a year Tshirtman has been developing this thing by himself, so common since would say that development should be happening at a more rapid pace. After a bit of thinking, I think I have narrowed the cause of this decrease in productivity to a few things:
>
> No Clear Goals
> While we would all agree that network games, better characters, and a more developed AI are design goals for a 1.0 release, there doesn't seem to be any focus on any short-term goals. I am not proposing that there should be strict deadlines (the lack of which I  believe is tshirtman's way of not being imposing, and allowing us to have the freedom to deal with the real world -- this is a hobby project after all), but I think it would be great to have sensible goalds. For example - "It would be nice to have a few concepts for network games thought up by the end of this month". If we don't meet such flexible goals, then we should be able to communicate as to why they weren't met, not excepting things like "I don't have time". In fact, each members lack of time should be communicated before hand so that realistic goals can be properly set.
>
> No Ownership of Tasks
> In a lot of commercial projects, this solved by a project leader assigning tasks to different members. Clearly for our use case this is unsatisfactory, but it does have the benefit of holding people accountable, which generally ensures things get done. For our situation, I think it would be great if we started taking advantage of our blueprint tools. No one would be assigned to anything, but people could volunteer to take ownership of a specific aspect. Another idea I had on how we could begin to implement new features is a bit of a collaborative model:
>
> For the first week everyone submitted a draft implementation, which could be pseudo code, a flow chart, or a few paragraphs explaining how things would be implemented. After that, team members would comment on which implementation was best (most intuitive, practical, less performance impacting, etc). If the feature was a small feature, one person (not neccessarily the person who came up with the implementation) would finish it, otherwise, we could do some sort of pair programming.
>
> Using BZR
> Ok, this primarily a rant, but it does hold some truth in it. Either way, you can probably skip this entire section and stop reading this email :-).
>
> Problems with using bzr are as follows:
> 1. It is slow. Not only will it take longer for developers to get the code and help contribute, but for source-based/bleeding-edge distros, it means it will take that much longer to install and they may give up before finishing the download.
>
> 2. As a developer and a package maintainer it is cumbersome to test new releases. When I try to use my package manager to install usf from bzr, I get ssh/launchpad errors unless I disable my username in my bzr config file. Afterwards, in order to continue to contribute to the project I have to re-enable my user name
>
> 3. It is not as widely accepted (except among Ubuntu users). People may protest contributing code for the simple fact that they have to install yet another distributed version control system. Also, as far as I know, launchpad is the only web frontend to bzr.
>
> 4. Branching/Tagging. In order to work on a different 'branch' of code, I have to create a completely different repository, which is a waste of precious hard drive space. With, for example, git, I can do everything within the same directory.
>
> 5. Merges. I won't even say anything else about this.
>
> All these complaints being said, I do like the blueprints feature and the idea of getting points for contributions. While using bzr is not anything that will make me stop working on this cool game, I'll probably compain about it on a bi-weekly basis as my level of frustration rises :)
>
> ____________________________________________________________
> Receive Notifications of Incoming Messages
> Easily monitor multiple email accounts & access them with a click.
> Visit http://www.inbox.com/notifier and check it out!
>
> _______________________________________________
> Mailing list: https://launchpad.net/~usf-team
> Post to     : usf-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~usf-team
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Kizzo