Hey Scott, … just following up on the action I took from the PTG, Here’s the URLs and notes on contributing to StarlingX: StarlingX Contribution Guidelines are documented here: * https://docs.starlingx.io/contributor/index.html * https://docs.starlingx.io/contributor/development_process.html * https://docs.starlingx.io/developer_resources/code-submission-guide.html * https://docs.starlingx.io/contributor/doc_contribute_guide.html * https://docs.starlingx.io/contributor/api_contribute_guide.html * https://docs.starlingx.io/contributor/release_note_contribute_guide.html My summary of this is as follows: * Need to set yourself up with the required accounts for contributing to a project hosted by OpenDev ( https://docs.opendev.org/opendev/infra-manual/latest/developers.html ) * Create a STORY in https://storyboard.openstack.org/#!/project_group/starlingx with a brief description of the feature/contribution you are proposing * Start attending the StarlingX Release Team Meetings * to let community know of your proposed contribution * add your STORY into the STX-R# Release Planning Spreadsheet * with info on forecasted SPEC Date, CodeComplete Date, TestComplete Date, etc. * AND report on progress of STORY/Feature over the course of the STX Release * Meeting info * Bi-weekly meeting on Wednesday 06:30AM PT / 09:30AM ET / 02:30PM UTC * Zoom Link: https://zoom.us/j/342730236?pwd=N21CUXNXVlJXMlcyZjZ0SE96cVNjQT09 * Meeting agenda/minutes: https://etherpad.openstack.org/p/stx-releases * Start attending the SubProject’s Meeting(s) that are most relevant to the contribution you are doing (e.g. if it’s some wireguard enhancement … maybe Networking or Distro/Kernel SubProject ?) * good place to ask for detailed specific help in the area * good place to let community members ( who are ‘cores’ of the code repos you are changing ) be aware of the your upcoming contribution … so that SPEC REVIEWS and CODE/GERRIT REVIEWS go more smoothly * good place to NAG community members (especially cores) to review your SPEC and CODE/GERRIT REVIEWS * Write your spec and submit it for review in GERRIT * ideally do this before you start (or are too far along) on the design/development of your contribution … in case there is a lot of discussion around your approach * Develop and Test your code before submitting in GERRIT for REVIEW * address comments from review * Full integration testing on your update * explicit testing of your functionality * make sure your update works (and doesn’t break) system operations such as upgrades 😊, controller switchover, backup & restore, etc. * raise launchpads and fix any issues found * Update StarlingX DOCs and submit for GERRIT REVIEW * address comments from review ( … I likely forgot stuff … any one in community feel free to update anything I’ve said … ) let me know if you have any concerns/questions, Greg.