The Team Manager is an application to assist the formation and management of virtual teams. When a user wishes to form a new virtual development team, they can use the Team Manager to create an entry for it - specifying things like a home page (which may or may not be that member's webspace), some team info, etc. Other members can then apply to join that team. Teams can also be composed of subteams ("programming team," "art team," "sound team, etc). Members can be assigned varying permissions over teams and subteams, so the project lead could assign their lead artist permission to recruit people into the art team, for example. Integration with the suggested Subversion server seems like a sensible idea, though the idea doesn't depend on it. There would be direct interfaces for publishing team releases (to the showcase) and team media (to IOTD). A scheduling facilty would also be present, allowing the team managers to schedule things like IRC meetings and milestones. These scheduled events can then be presented to team members as reminders through popups and the like, while they browse the site. If a member is due to submit a milestone in the next couple of days, a reminder can be displayed near the top of the page.

This might be an extremely valuable additional premium service benefit, in terms of really binding the members to the brand for production purposes of their own games. Doesn't sound like it's capital intensive to implement, but I can't account for the labor time. These types of tools are going to appear elsewhere eventually. Getting the jump on the gun is a good thing.


Adventuredesign

Quote:Original post by adventuredesign
This might be an extremely valuable additional premium service benefit, in terms of really binding the members to the brand for production purposes of their own games.

Right. It's also a first step towards GDNet-published indie games - just swap the showcase for GDNet's theoretical shareware publishing mechanism.

Quote:Original post by superpig

Quote:Original post by adventuredesign
This might be an extremely valuable additional premium service benefit, in terms of really binding the members to the brand for production purposes of their own games.

Right. It's also a first step towards GDNet-published indie games - just swap the showcase for GDNet's theoretical shareware publishing mechanism.

This is part of the mechanism in my forthcoming brand strategy for management review.

I would like to see a fleshed out version of your idea from the POV of your technical expertice taking into account minimum gamedev.net resource utilization, I would be happy to work it into the larger context strategy I am drawing.

The key component here is the team system. A complete team is composed of a hierarchy of subteams, and each subteam has members, one of whom may be selected as that subteam's "lead." The person who initiated the team is automatically lead of the root subteam.

Permissions operate such that team leaders can be given the ability to recruit people into their teams, throw people out, reorganize their people into subteams, assign team leaders, assign permissions, etc. So the project leader could create an 'Art' team, add a person who he then selects as 'Art lead,' and gives that person permission to recruit and reorganize subteams. That art lead then has complete control over his own staff, and can run his section as he sees fit.

Recruiting is a mutual agreement process. An applicant submits a request to join the team/subteam; a new 'application' is opened for that user/team pair - a private thread tracking correspondence. The request is set to the team leader (teams without leaders cannot recruit). The team leader can correspond with the applicant via the application, or can hand it off to someone else - one of his subordinate team leaders, his line manager, or sibling team leaders (so the art lead can pass to the testing lead without needing to bother the project lead).

The application can be viewed at any time by anyone higher up than the person who currently 'holds' the application. The applicant can also close the application from their end, if they wish to withdraw from negotiations.

This continues until the application is closed with either a rejection or an acceptance; this closure can either by done by the person handling the application on his own, or as a joint effort between this person and someone more senior (if the permissions are set as such). If rejected, the application is locked and filed, to be accessed by the applicant and by the team member (or those senior to him) who rejected the application. If accepted, the applicant must also signify his acceptance, and when he does this the applicant joins the subteam for the lead who accepted him, and the application is locked and filed for reference as per rejection.

Throwing people out is simpler - as with recruitment, it can either be done solely by a team lead senior to (and in line with) the person, if they have full permissions; or, it can be initated by one such person and then 'signed off on' by another person with the relevent permissions who is more senior.

Quote:Original post by superpig
The key component here is the team system. A complete team is composed of a hierarchy of subteams, and each subteam has members, one of whom may be selected as that subteam's "lead." The person who initiated the team is automatically lead of the root subteam.


Permissions operate such that team leaders can be given the ability to recruit people into their teams, throw people out, reorganize their people into subteams, assign team leaders, assign permissions, etc. So the project leader could create an 'Art' team, add a person who he then selects as 'Art lead,' and gives that person permission to recruit and reorganize subteams. That art lead then has complete control over his own staff, and can run his section as he sees fit.

Recruiting is a mutual agreement process. An applicant submits a request to join the team/subteam; a new 'application' is opened for that user/team pair - a private thread tracking correspondence. The request is set to the team leader (teams without leaders cannot recruit). The team leader can correspond with the applicant via the application, or can hand it off to someone else - one of his subordinate team leaders, his line manager, or sibling team leaders (so the art lead can pass to the testing lead without needing to bother the project lead).

The application can be viewed at any time by anyone higher up than the person who currently 'holds' the application. The applicant can also close the application from their end, if they wish to withdraw from negotiations.

This continues until the application is closed with either a rejection or an acceptance; this closure can either by done by the person handling the application on his own, or as a joint effort between this person and someone more senior (if the permissions are set as such). If rejected, the application is locked and filed, to be accessed by the applicant and by the team member (or those senior to him) who rejected the application. If accepted, the applicant must also signify his acceptance, and when he does this the applicant joins the subteam for the lead who accepted him, and the application is locked and filed for reference as per rejection.

Throwing people out is simpler - as with recruitment, it can either be done solely by a team lead senior to (and in line with) the person, if they have full permissions; or, it can be initated by one such person and then 'signed off on' by another person with the relevent permissions who is more senior.

This looks like a procedural administration of HR policy, what other kind of tools and functions in addition to the ones you originally described, as an aspect of the GDNet application would you include in this to add value to the Team Manager capabilties? What I am thinking of is maximum utilization and toolsets to make the service offering a real value as a premium service.

Adventuredesign

Yup, I said there'd be more to come :)

Firstly, Subversion services. Each whole team gets a repository in which they can store both code and assets; permissions are connected to the team system such that the art team can only be granted write access to art assets, etc. Web-based interface, plus secure access through Subversion's native interfaces. Space would be limited for the entire team, of course; subquotas could also be imposed (i.e. allowing the team to break up the space as they see fit, and to enforce that).

Secondly, bugs database. As always, this can be controlled to allow varying levels of access across the team, and can also be opened up to the public, for public beta testing.

Thirdly, communications services. A private forum, maybe a private IRC chat room as well (with a bot to record and file logs, and provide other team services). Plus, the scheduling system; people can schedule events for themselves and their subordinates, such as chat room meetings, teleconferences, milestone deadlines, etc. Reminders are displayed to users as they browse the site, and the runup to an event can be controlled on a per-user basis (users can set at which intervals they want reminders).

Lastly, direct publishing to the rest of the site. Games can be published into the GDNet Showcase when finished, and into a project-specific 'testing area' for public betas. Screenshots and media shots (concept art, renderings, etc) can be published to a project-specific gallery, and from there are fed into the IOTD system.

What we're selling here is a specially targetted version of Sourceforge, really. We have two major advantages that I see:

1) No open-source requirement
2) Specific to games

We want to be providing development features specific to games. This is why things like testing, demos, and media need a fairly strong focus; we also need good handling of non-text assets (don't know how well Subversion provides this). What else?

Well, our audience is gaming-related, of course. You can guarantee that a person looking at your project will have some interest in gaming and game development, while at sourceforge they may well be looking for a nice boring text editor to join up with instead.

We should consider assisted delivery routes - partnering with one or more online publishers to provide expidited routes for projects to publishing (if they don't wish to do it themselves, which I guess they could). In any case it's the best we can do in lieu of opening our own publishing arm.

We could provide technology - engine components, tools, etc.

A certain amount of legal help - boilerplate NDAs and contract agreements, etc (Of course, we'd have to watch our own liability in this.. IANAL).

Hmm... now it's sounding more like a cross between SourceForge and Garagegames. That may be a good thing [grin]

As far as money's concerned, I know you asked for technical/functional stuff rather than business, but I could envision it being that only GDNet+ members can start new teams; and also, if all projects start off with say 20mb of space on the Subversion server, we could sell extra space in 25mb chunks for $3-4 dollars a month. I think that's particularly apt because if someone's developed 21mb of project they're less likely to throw it all away because they don't want to pay for the extra space.