Skip to content
This repository has been archived by the owner on Aug 21, 2024. It is now read-only.

Github Workflow

Josh Field edited this page Mar 6, 2023 · 2 revisions

Feature Workflow

  • an initiative is an entire category of feature, such as "AR Support"
  • epics describe the various parts and the an initiative and describes the 'why' of the feature
  • this begins as a collection of checkmark dot points describing all the 'what' of the feature
  • these dot points then can be clicked to made into their own issues (called stories)
    • there should be no more than 8 stories per epic
  • each issue will have included all relevant details, including time estimate, test cases and broken down into checkmarks that describe the 'how'
    • all sub-tasks have a time estimate included:
      • 1 equates to a half day
      • 2 to a whole day
      • 4 to two days
      • 8 to four days
    • no sub-task should take more than 4 days. if a task does take more than 4 days, it should be broken down into smaller parts. this is to ensure a sub-task and review/QA can be completed in a single working week
    • each time a sub-task is completed, tick the checkmark and post the progress in the #team-dev-updates discord channel including any difficulties or notes
  • at the end of a sprint, a sprint review is conducted in which a form will be filled out by each engineer to improve future estimates and processes

epics-vs-stories-agile-development

Bug Reporting

  • submit bug report with bug report issue template
  • add to sprint board, 'To Do' as high priority, 'Next Sprint' as medium priority, 'Future' as low priority
  • post the issue link into the bug-reports channel on discord
  • Stewards assign issue to a contributor with time estimate points tag

Release Process

  • Merge dev into qat & ensure it passes
  • Create new release https://github.com/etherealengine/etherealengine/releases
  • Click Draft a new release
  • Click Choose a tag, then in the text box that says 'Find or create a tag', enter the version number in the format v1.0.0 The leading v is required. Make sure to click the option Create new tag: v<version> on publish that appears underneath the text box.
  • Put v<version> into the Release title text box
  • Click Publish release, and it should succeed
  • Wait a couple of minutes, and there should be a PR that bumps the version number in all the packages. Merge this into dev.
  • To push to master, just make a PR to merge dev into master. Make sure to change from squash and merge to Create a merge commit if squash is selected when merging
Clone this wiki locally