September 2011

Revisiting Drupal's "New Project Application" Process (Part 3)

Submitted by jthorson on Wed, 09/28/2011 - 12:30

Once again, it's been a few weeks since my last post on this topic, where I promised to outline a new vision of how a revamped process might look. But before I dive into it, I should mention that this is just one person's view of what the process could be, based on experience with the current process and a number of individual conversations with other members of the Drupal community. It is not intended as a definitive version of the new model, but rather as a base for further discussion.

I'll provide a flowchart of the full process proposal at the bottom of this article ... but for now, I'll break it into individual concepts in the interest of keeping things easily digestable.

"Race" Entity

Submitted by jthorson on Wed, 09/21/2011 - 23:22

The ‘race’ entity represents a competition between two or more opponents, where the result is a ranking of participants as opposed to a simple win/loss state.

COMMON SCHEMA

id: Id (primary key)

BUNDLES

GAME

SET

MATCH

SERIES

FIELDS

"Position" Entity

Submitted by jthorson on Wed, 09/21/2011 - 21:15

The ‘position’ entity represents a sport-specific ‘position’ for a player (and may include admin (coach, etc))

COMMON SCHEMA

  • Schema: id: Id (primary key)
  • Schema: id: name
  • Schema: id: sport (reference to a sport)

BUNDLES

PLAYER POSITIONS

NON-PLAYER POSITIONS

FIELDS

"Player" Entity

Submitted by jthorson on Wed, 09/21/2011 - 21:00

The ‘player’ entity represents an individual player or administrator involved with a team and referenced by the team’s roster or lineups.

COMMON SCHEMA

  • Schema: id: Id (primary key)
  • Schema: type: Bundle Type
  • Schema: uid: uid of the player (if a user)
  • Label/Title/Name

BUNDLES

Player

Represents a 'player' on a team

Staff

Represents a non-participating team member (admin, trainer, coach, etc.) with no stats.

"Roster" Entity

Submitted by jthorson on Wed, 09/21/2011 - 20:57

The ‘roster’ entity represents a list of the players associated with a given team.

Typically, a roster should be attached to a team ‘Instance’, as opposed to a team ‘definition’ ... which supports archiving of roster history.

"League" Entity

Submitted by jthorson on Wed, 09/21/2011 - 20:52

The ‘League’ entity structure must be flexible enough to support both the ‘promotion and relegation’ and ‘franchise’ models of organization.

The ‘league’ entity can represent the parent container for a given league organization, the hierarchy of the actual league (including division/conference/tiers/etc); and a container for teams/games/results/etc within that league.

The top level league entity type is an ‘Organization’. Organizations represent the parent organization or association for a given league.

Pages