Incorperate improvments from Resource Jam Retro

[jonathandavidlewis]

What went well - Keep doing

• Design process: Spending time designing milestones. We took time to write out milestones to cover the scope of the Jam.

  • We captured game design in a game design document.
  • We translated the game design into a sequence of events in a player experience timeline.
  • We Organized the events in the timeline by the most probable gameplay, in chronological order.
  • We turn the events into issues/tasks.
  • Identified overarching game loops and turned them into milestones.
  • We attached issues to their corresponding milestones.

• Individualized Kanban boards per person. Allowed individuals to stay on task. Allowed others to see what each has up next.

  • Makes effort: past, present, and future for all people on team to facilitate collaboration.

• Asset upload: This was simple for creatives. Open the link, add assets, describe it, and click submit.

• Taking time to give others feedback/reminders about the process.

• Meeting everyone together on a call early.

• For this 2 week project, Creating pull requests that were usually seen, "approved" / acknowledged by other developers.

• Distinct artistic vision that was different from the mainstream.

What we can improve

Goblin Armies issues

• [x] These tasks can be added to the "GoblinArmies" project and repo:
  • [ ] #266
  • [ ] #267
  • [ ] #268

New Repo: Boilerplate Documents

• [ ] loteque/boilerplate-docs#1
  • Document the creative asset upload process add to boilerplate readme
  • Fewer DMs, Use threads and mention the user instead (As long as it's not personal). Makes the conversational demand on an individual more clear to all (rather than DMs that are not visible to others). policy in the contributor readme
  • Create an accessibility issue template. Includes (for now) other player experience issues related to game design.
  • the github documentation shows how issue tmplates can be written in YAML.
  • https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository

New Repo: Process Decision Record (PDR)

• [ ] loteque/Process-Decision-Record#1
  • Intentionally schedule a call early, specifically for people to get to know each other (Maybe consider the "what you want out of this" format) Role...
  • Define (at some point) art specifications (technical requirements and design language) for artist.
  • Define a concept art phase.
  • Define a deadline for art specifications.
  • Define responsibilities that normally belong to a technical artist and art director so that they can be accounted for and ideally "owned" by a willing person.
  • If someone has a concern, give space for it, hear it. Goal: The person who raises the concern can express that they understand the reasoning behind the decision. Ideally, the concern is "resolved". The team should put a "good, honest effort" into resolving the issue.

[loteque]

• This task can be added to the "GoblinArmies" project and repo. We should create a task to document the creative asset upload process.

* [ ]  Improve asset upload: Reference task number. Create an upload template (if possible) with text. Add an upload link into the issue text so the artist gets a link specific to where the assets for that task should belong.

---

• This could be a policy in the contributor readme. This task should belong to a repo that tracks changes in a boilerplate readme for projects. maybe the repo could house all boilerplate cocuments and be pulled into a project repo as a submodule.

* [ ]  Fewer DMs, Use threads and mention the user instead (As long as it's not personal). Makes the conversational demand on an individual more clear to all (rather than DMs that are not visible to others).

* [ ]  Remind people to use the channel with threads and mentions when they reach out over DM.

---

• We could document process design decisions/changes. This seems like its own repo?

* [ ]  Intentionally schedule a call early, specifically for people to get to know each other (Maybe consider the "what you want out of this" format) Role...

* [ ]  Define (at some point) art specifications (technical requirements and design language) for artist.

* [ ]  Define a concept art phase.

* [ ]  Define a deadline for art specifications.

* [ ]  Define responsibilities that normally belong to a technical artist and art director so that they can be accounted for and ideally "owned" by a willing person.

* [ ]  If someone has a concern, give space for it, hear it. Goal: The person who raises the concern can express that they understand the reasoning behind the decision. Ideally, the concern is "resolved". The team should put a "good, honest effort" into resolving the issue.

---

• also an issue belonging to "process"

* [ ]  Create an "Accessibility" label

---

• issue templates seem like they belong to the document boilerplate repo
  • the github documentation shows how issue tmplates can be written in YAML.
  • https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository

* [ ]  Create an accessibility issue template. Includes (for now) other player experience issues related to game design.

[jonathandavidlewis]

@loteque - This all looks fine to me!