At CDISC there are many types of developers. Different developers may have differing needs for workflows. In this document we will try to lay out the various workflows we have identified. Hopefully, one of these will fit your particular needs. If not, work with your team to develop a new one and submit it to the Wiki for inclusion.

By 'internal', we mean to say those who are CDISC employees or contractors, or those volunteers who are heavily involved in CDISC projects, strongly committed, and brought on as members of the team. In other words, these are software developers directly contributing to CDISC-run projects as members of the team.

A workflow for an internal software developer will probably look like this ZenHub based workflow:

1. If you have not yet done so, clone the project repository locally.
2. Create a branch for the feature or other work you are developing.
3. Create a draft PR containing the work you are proposing (the PR can come before the completed code).
4. Continue the discussions with your team members in ZenHub. Because we are using Scrum to work as a team discussions belong in our Scrum tools. External developers (those not on our team) will do things differently. See section for external developers below.
5. When coding is complete request a review from one of your team members.

External developers are those who want to contribute to one of the CDISC open source projects that we are hosting in GitHub. These developers might be independent devs who simply have an idea they want to offer. Or they might be devs who are supported by another firm that has an interest in seeing certain updates to a CDISC open source project.

In either case the workflow will look something like this:

1. The developer will first become comfortable with the platform. If the dev is certain about their involvement, they will likely want to fork the CDISC repository and create their own repository for development.
2. In their own repository, create a branch to represent and hold any future changes they want to submit.
3. Create a draft PR back to the CDISC repository. This PR will be the central location for any discussions about the feature or change they will want to submit for consideration. Notice that this is different from how the CDISC team is managing their internal PRs.
4. Once coding in that branch is complete, submit a review request tied to the PR.
5. Iterate over any reviews, updates or fixes as requested, and re-submitting for review.
6. Assuming that the CDISC team approves the PR through its review process, they will then merge the branch into the CDISC repository.

It is sometimes the case that development is not happening in source code. Some examples might be:

• Excel or other proprietary non-text formatted files.
• Images (artwork, photographs, vector drawings, etc)
• Audio
• Video
• Branding assets

Git's and GitHub's history are as platforms for managing source code, primarily. Many tools and abilities have been developed specifically for this purpose. For instance, github and git both have tools for helping merge code changes easily and safely.

However, non-text files are not so easily supported. Changes aren't as easily described and merged. Also, not all developers necssarily feel comfortable working with the plethora of developer tools built into Git and GitHub. Therefore, we will suggest here some possible alternative workflows for contributing to open source projects at CDISC.

For non-coder contributors new to working in GitHub, the GitHub Desktop can be a non-intimidating way to submit contributions to a CDISC open source project.

1. Download the GitHub Desktop
2. TBD