Agenda Next Meeting Deep Dive

Ongoing Discussion

Handling Incompatible Change

This is a discussion primarily rooted in replacing JEP as the formula system The first discussion took place at The June 6th Meeting.

This is an ongoing discussion to be picked up at the next deep dive session.

Future Discussion Topics

Selection User Experience

Request By: Tom

This is a strategy question for how we want users to make choices within PCGen. Right now we have various constructs (popup windows, pools (some that require certain items to be selected - see spells). While I'd like to keep the discussion away from data constructs, it's probably appropriate to point out that right now we have multiple methods of driving a selection (CHOOSE, ADD, Ability Pools, and a few others).

Especially for choices driven by the data, what is the user experience that we want? Specifically:

• How are selections deferred, if at all
• What types of choices are there (e.g. Archetypes, selecting a skill for Skill Focus, etc - this is a RULES question not a data token question) and do they justify different behavior?
• Should the data EVER be able to enforce a popup?
• Should data be able to provide a default choice if no other choice is made?
• How can selections be done efficiently without forcing popups?
• What specifically is the best user experience for a selection?

• Fantasy Craft - Rules Construct (First Base and Expert Selections)

Abstract Documentation

Request By: Tom

Requires: Eric

This is a strategy question around our documentation. We are getting to a point where there will be things transferred from code to data.

There are multiple examples of this situation:

• We expect with the new variable system that there are no longer built in terms
• The output system will be moving to Freemarker rather than the existing output tokens

What is required to address this issue in terms of proper documentation when the data is controlling features and therefore features vary by game mode? Specifically:

• Where are variable lists captured?
• Are variable lists consolidated?
• How does a user know what output functions are valid in Freemarker?

GIT/SVN Switch over for Development team

Request by: Andrew (Facilitated by James Dempsey)

Requires: Tom Parker, James Dempsey and Andrew Maitland

This is a discussion of the viability of moving the project developers to using GIT as our main code platform. If so, we would discuss potential work flows that GIT makes possible beyond SVN main usage.

This has two main parts:

• Developer Workflow Contract
• CI Usage

Atlassian (provider of our JIRA and Bitbucket) has a webinar on using GIT workflow strategies to develop their main product JIRA.

• They use a central bare repository (Like we have for our SVN) and all project developers have shared access to the repo.
• Each ISSUE a developer is working on has its OWN branch and once an issue is deemed fixed it is merged back into the DEVELOPMENT branch.
• There are several "Branches" - You have a Release Branch (Tagged with the version number); Development Branch (CI should be run and never come dirty here); Hotfix Branch (For High Priority Bug Patches that would merit another release revision); Feature Branches (Mainly named in a standard fashion to id the issue they belong too); and Bug Branches (Follows the same naming convention of JIRA ID).
• When each feature or bug is finished (you merge the development branch into it to test it if there are other commits ahead), and then it is merged to the development branch, and then that feature/bug branch is "pruned" or "deleted" from active use (Its history is still readily available).

I would definitely like the ability to run Jenkins on private branches. This would enable us to not clutter the development branch with broken builds. The idea is DEVELOPMENT is meant to stay "Clean" so we can branch from it for all features and/or bug fixes.

PROs:

• GIT does a much better job of Branching and conflict resolution. Unlike SVN which physical files are creating in another location, branching in GIT is much more intelligent allowing you to easily switch branches, commit locally, and switch again without losing your work.
• GIT Clients all handle loading Pageant with the correct KEY for SSH.

CON: A minor learning curve associated with a new system, learning the new terms.

• COMMIT in SVN is PUSH in GIT. GIT's COMMIT is a local saving.