Skip to content

Review Process

JoseEmilio-ARM edited this page Nov 7, 2019 · 5 revisions

Reviewers should consider the following:

  • Is this sample aiming to provide guidance on API Usage, API Extension Usage or Best Practice and Performance?
    • Each of these comes with different considerations, for example a sample aimed at explaining how to use an essential part of the API does not necessarily need to be perfectly optimized.
  • Taking into consideration the above point, is this sample displaying good Vulkan practice?
  • Could or should this sample be using the framework?
  • Does this sample work on our platform or hardware?
  • Could this vendor specific sample be made to work on our platform or hardware? (Vendor Specific Samples only)
  • Is the issue I am about to raise something that must be fixed before approval or could it be resolved after?
  • Can I or someone else at my company submit a fix for this issue in the future?
  • Does this sample add value to the repository? Is it doing something new, interesting or showcasing good practice?

Approval Process

For external contributors

Key Points:

  • 3 unique approvals required to publish to GitHub
  • 1 disapproval will cause the sample to be held back from progressing until it is resolved
    • You must state why you are holding the sample - Approvals must be stated clearly in a comment with "Approved" and rejections must include the word "Rejected". This will ensure that the repo bot behaves correctly.

For Khronos members

Key Points:

  • 2 weeks to review newly added samples
  • 3 unique approvals required to publish to GitHub
  • 1 disapproval will cause the sample to be held back from progressing until it is resolved
    • You must state why you are holding the sample - Approvals must be stated clearly in a comment with "Approved" and rejections must include the word "Rejected". This will ensure that the repo bot behaves correctly.

Vendor Specific Samples:

  • If a sample is marked Vendor Specific:
    • Only supporting vendor must approve
    • Other vendors can request changes during the review period
      • e.g. If the sample could be changed to run on their hardware as well

Multi-vendor Samples:

  • Only relevant vendors need to approve
    • e.g. A sample makes use of a feature or technique applicable only to 2 vendors. Only those 2 particular vendors need to approve, others do not need to vote.

Full Flow

  1. Draft sample is submitted
  2. Draft sample is checked it follows basic guidelines laid out by the Working Group (should be automated)
  3. Email goes out to all representatives for 2 week review period
    1. Representatives may ask questions, comment and vote during this period
  4. After 2 weeks
    1. Approved - if the draft sample has the necessary votes as per above voting guidelines, it is merged
    2. Returned - if the draft sample does not have the necessary votes as per above voting guidelines, the submitting party is notified and can view the comments + feedback. They can then make necessary changes.

Clone this wiki locally