Workflow document update #377

0xc0170 · 2018-01-23T13:12:27Z

There are lot of changes (I can split some restructuring from this if that would make it easier but the changes are not that significant to the text itself). I can rebase after the review (squash fix typos and similar commits).

Rendered file here

The new structure is:

gatekeepers (maintainers + stakeholders)
contributions
pull requests categories and states
additional labels

New additions here:

introducing feature branches
stakeholders (feature owners or module owners)
time boxes for each pull request stage

Please assign for review maintainers (@theotherjimmy @adbridge @cmonr )

@studavekar (there is one reference to CI that is currently empty and would like to have a page that explains our CI. I can remove the reference for now, but should be added later).

sg- · 2018-01-23T15:18:39Z

docs/reference/contributing/guidelines/workflow.md

-Please create separate pull requests for each concern; each pull request should have a clear unity of purpose. In particular, separate code formatting and style changes from functional changes. This makes each patch’s true contribution clearer and therefore quicker and easier to review.
+The current maintainers are:
+
+* Anna Bridge (adbridge).


Can we link to os.mbed.com developer accounts rather than github?

I can do. The full name and link to os.mbed.com profile only, no github profile link here?

Fixed in 9e39249 commit

sg- · 2018-01-23T15:21:00Z

docs/reference/contributing/guidelines/workflow.md


-Please see the [code contributions chapter](/docs/v5.7/reference/guidelines.html#style) for the guidelines to GitHub pull requests and the coding style guide.
+All Mbed OS is on GitHub; please use GitHub's [issues mechanism](https://guides.github.com/features/issues/) to open a bug report directly against the relevant GitHub repository.


Can we delete this line or point all issues to be opened under bugs and suggestions or Questions on os.mbed.com and use a specific tag?

fixed 2226b6e. The reporting bug is quite brief, is that sufficient ?

AnotherButler

Please address my initial comments before a perform a complete copy edit.

AnotherButler · 2018-01-23T16:38:39Z

docs/reference/contributing/guidelines/workflow.md

@@ -1,42 +1,60 @@
 ### Workflow

-#### Contributions
+#### Gatekeepers


I don't think it makes sense to go straight into Gatekeepers without any sort of introductory paragraph. Could we move this down?

OK will add here or move it

AnotherButler · 2018-01-23T16:40:37Z

docs/reference/contributing/guidelines/workflow.md


-#### Reporting and fixing bugs
+* Anna Bridge [adbridge](https://os.mbed.com/users/AnnaBridge).


Query: If we're linking to the os.mbed.com profile, does it make sense to use the GH username?

Good point. I think we should either link to the GH user page, or use the os.mbed.com profile username.

I'm personally more of a fan of the former.

The reason I left github name is that pull requests are via github so that name is visible to contributors, however name might be sufficient and then link to mbed OS?

AnotherButler · 2018-01-23T16:44:52Z

docs/reference/contributing/guidelines/workflow.md


-Before submitting a bug report or a bug fix, please [discuss it on the forums](https://os.mbed.com/forum/bugs-suggestions/) to avoid duplication of work, as we or others might be working on it already.
+##### Stakeholders


Query: Is this a new official term for lead engineers for new features and modules? I think it's vague because there are many stakeholders who do not fit this description.

This was the name I could come up with to merge tech leads with feature leads.

The groups as I see them:

Gatekeepers:

maintainers

tech leads/feature leads (often they match but not always)

I think the second group could be tech leads group, better?

AnotherButler · 2018-01-23T16:45:16Z

docs/reference/contributing/guidelines/workflow.md


-##### Bug reports (issues) on GitHub
+They are responsible for a specific mbed OS module or feature.


They are responsible for specific Mbed OS modules or features.

AnotherButler · 2018-01-23T16:47:00Z

docs/reference/contributing/guidelines/workflow.md


-A member of the Mbed team must verify bug fixes before we pull the fixes into the main branch. You must therefore use GitHub to fork the repo and then submit a pull request with your changes.
+All code changes and additions to Mbed OS are handled through GitHub. If you want to contribute, either by adding features or by fixing bugs, please follow the guidelines for [new features](#contributing-new-features-to-mbed-os) and [bugs](#reporting-and-fixing-bugs). In both cases, please follow the [code style guide and GitHub pull request guidelines](/docs/v5.7/reference/guidelines.html#style)</a>. Please also read the [CLA](/docs/v5.7/reference/guidelines.html#cla) guidelines because we will immediately close pull requests submitted without a CLA.


Please fix the first two links because they're now broken.

I did not change those links, only moved this paragraph. Any help to make it right if they became invalid? don't know how to yet

cmonr · 2018-01-23T22:28:09Z

docs/reference/contributing/guidelines/workflow.md


 #### Guidelines for GitHub pull requests

 Pull requests on GitHub have to meet the following requirements to keep the code and commit history clean:

- Commits should always contain a proper description of their content. Start with a concise and sensible one-line description. Then, elaborate on reasoning of the choices made, descriptions for reviewers and other information that might otherwise be lost.
+- Commits should always contain a proper description of their content. Start with a concise and sensible one-line description. Then, elaborate on reasoning of the choices made, descriptions for reviewers and other information that might otherwise be lost.
 - You should always write commits to allow publication, so they can never contain confidential information, reference private documents, links to intranet locations or rude language.
 - Each commit should be the minimum self-contained commit for a change. A commit should always result in a new state that is again in a compilable state. You should (if possible) split large changes into logical smaller commits that help reviewers follow the reasoning behind the full change.
 - Commits should follow [Chris Beam’s seven rules of great commit messages](http://chris.beams.io/posts/git-commit#seven-rules):


Add a new line after the image. The rendered text starts on the same line as the image.

Wrong spot. The problem line is 99, not this one.

Can we have pull request titles follow these rules too?

I'll add it there

0xc0170 · 2018-01-24T08:27:45Z

Updated , I responded to all feedback, see new 4 commits

AnotherButler

Thanks for the updates. I've performed another copy edit and left some more queries. This is looking good.

AnotherButler · 2018-01-24T15:48:39Z

docs/reference/contributing/guidelines/workflow.md


-#### Further reading
+We can only accept patch contributions through GitHub if you create a pull request from forked versions of our repositories. This allows us to review the contributions in an easy-to-use and reliable way, under public scrutiny.


Query: What do we mean by "patch contributions"? Patch release contributions? Or all PRs? Or something else? Please clarify.

a patch - series of commits, another name?

AnotherButler · 2018-01-24T15:49:53Z

docs/reference/contributing/guidelines/workflow.md

-* Sam Grove (sg-).
+##### Changes and additions
+
+Backward compatible changes (refactoring, enhancements) or new target additions are considered to be part of the patch release.


Query: What does this mean? That we don't include these in feature releases, we only include them in patch releases? Or something else?

they are in patch releases and by default in the feature releases

AnotherButler · 2018-01-24T15:50:28Z

docs/reference/contributing/guidelines/workflow.md

+
+##### Features
+
+New features should initially be implemented on a separate branch in the Mbed OS repository. The naming convention for a feature branch is: "feature-".


Query: Who should initially implement new features on a separate branch? Can anyone in the community do this?

Will add info, that this branch is created on request (community can do once branch is created, send pull requests)

AnotherButler · 2018-01-24T15:51:41Z

docs/reference/contributing/guidelines/workflow.md

-All pull requests must be reviewed. The Mbed OS maintainers determine the most suitable person to review the pull request and tag that person accordingly. If a pull request requires a review from partners, the maintainers tag the corresponding GitHub group instead.
+All pull requests must be reviewed. The Arm Mbed CI bot determines the most suitable person to review the pull request and tags that person accordingly.
+
+Time: 3 days for reviewers to leave feedback after the label is added.


Query: Would it still be accurate to rewrite this as "Time: 3 days for reviewers to leave feedback after the maintainers add the "needs: review" label" for active voice?

AnotherButler · 2018-01-24T15:52:07Z

docs/reference/contributing/guidelines/workflow.md

+
+Time: 1 day for CI to complete and report back results.
+
+The CI workflow can be found [here](tbd)


Please complete this section.

@studavekar - I either to remove this for now, but would like to have it soon in

AnotherButler · 2018-01-24T15:54:01Z

docs/reference/contributing/guidelines/workflow.md

+
+##### Work needed
+
+The pull request requires additional work due to failed tests, changes requested.


Query: What does this mean? Could we rewrite this as "A pull request in the work needed state requires additional work due to failed tests. If a pull request is in this state, our maintainers request changes from the pull request author." for clarity?

AnotherButler · 2018-01-24T15:54:19Z

docs/reference/contributing/guidelines/workflow.md

+
+The pull request requires additional work due to failed tests, changes requested.
+
+Time: 3 days to respond to the review comments.


Query: Could we elaborate by saying "Time: 3 days for the pull request author to respond to the review comments."?

0xc0170 · 2018-01-25T11:48:11Z

Fixed all the comments, please review

0xc0170 · 2018-01-26T11:53:48Z

@cmonr @theotherjimmy Happy with this ?

0xc0170 · 2018-01-29T08:52:13Z

@AnotherButler When this can be integrated and the docs updated?

AnotherButler · 2018-01-29T15:05:40Z

As soon as all tagged reviewers approve it.

sg- · 2018-01-29T17:31:52Z

docs/reference/contributing/guidelines/workflow.md


-Before submitting a bug report or a bug fix, please [discuss it on the forums](https://os.mbed.com/forum/bugs-suggestions/) to avoid duplication of work, as we or others might be working on it already.
+##### Mbed OS tech leads


Can we remove this section. Seems to blur internal organization with an open project and not provide much usefulness.

The goal was to define what a team responsible for a module/feature should be doing.

I removed it for now.

From experience, we are not always aware what is the release version planned for PR (this can come specified in PR ) plus helping with reviews (they know who would be the best to do a review)

theotherjimmy · 2018-01-29T19:31:00Z

docs/reference/contributing/guidelines/workflow.md

@@ -50,53 +68,69 @@ Pull requests on GitHub have to meet the following requirements to keep the code
 - Because we use GitHub and explicit CLAs, special commit tags that other projects may use, such as “Reviewed-by”, or “Signed-off-by”, are redundant and should be omitted. GitHub tracks who reviewed what and when, and our stack of signed CLAs shows us who has agreed to our development contribution agreement.
 - Prefixing your commit message with a domain is acceptable, and we recommend doing so when it makes sense. However, prefixing one's domain with the name of the repo is not useful. For example, making a commit entitled "mbed-drivers: Fix doppelwidget frobulation" to the `mbed-drivers` repo is not acceptable because it is already understood that the commit applies to `mbed-drivers`. Renaming the commit to "doppelwidget: Fix frobulation" would be better, if we presume that "doppelwidget" is a meaningful domain for changes, because it communicates that the change applies to the doppelwidget area of `mbed-drivers`.
 - All new features and enhancements require documentation, tests and user guides for us to accept them. Please link each pull request to all relevant documentation and testing pull requests.
+- Avoid merging commmits. (Always rebase when possible.)
+- Pull requests should fix a bug or add a feature or refactor.


thing or thing or thing -> thing, thing or thing

theotherjimmy · 2018-01-29T19:32:15Z

docs/reference/contributing/guidelines/workflow.md

-4. Run pull requests through the CI systems.
-5. Merge pull requests into the requested branches.
-6. Make periodic patch and feature releases.
+The last line in your commit message description should say “Fixes #deadbeef”, where “deadbeef” is the issue number in GitHub. This allows GitHub to automatically close the issue when the commit merges into the default branch.


Specify master branch? "default branch" is vague

It's not always master, often it is. I'll edit this to destination branch rather

theotherjimmy · 2018-01-29T19:34:37Z

docs/reference/contributing/guidelines/workflow.md

-Labels that the Mbed OS maintainers add to a pull request represent the pull request workflow states. The Mbed OS maintainers are responsible for moving pull requests through the workflow states.
+The Mbed OS maintainers add labels to a pull request that represent the pull request workflow states. The Mbed OS maintainers are responsible for moving pull requests through the workflow states.
+
+Each state is time boxed. In most cases, this is sufficient time to move to an another state.


What happens when this time expires? this is not explained in the following sections. I don't think that the second sentence adds any value to the reader.

The actions will come as another update with more specification (once bot comes to play). For now, should be sufficient to explain that if an update is not provided within the time frame, pull request can be closed

theotherjimmy · 2018-01-29T19:38:48Z

docs/reference/contributing/guidelines/workflow.md


 ##### Releases

-Once we merge a pull request, we tag it with a release. This is the release in which we first publish this pull request. For patch releases, we allow only bug fixes, new targets and enhancements to existing functionality. New features only go to feature releases.
+Once we merge a pull request, we tag it with a release. (This is not applicable for feature pull requests.) This is the release in which we first publish this pull request. For patch releases, we allow only bug fixes, new targets and enhancements to existing functionality. New features only go to feature releases.


Don't we tag features with the next applicable feature release? Why would we omit that step? Why is this in parenthesis? If we want to omit tagging things that go to feature releases it would be less confusing to word it as:
"When we merge a pull request that will be published in a patch release, we tag that pull request with that patch release version."

I haven't noticed us tagging a feature PR with a target release.

+1 for the updated text.

"When we merge a pull request that will be published in a patch release, we tag that pull request with that patch release version."

Will fix

0xc0170 · 2018-01-30T09:52:31Z

Addressed all the comments

cmonr · 2018-02-01T19:44:09Z

@theotherjimmy Good with the updates?

adbridge · 2018-02-07T10:41:33Z

docs/reference/contributing/guidelines/workflow.md


-Before contributing an enhancement (new feature, new port and so on), please [discuss it on the forums](https://os.mbed.com/forum/bugs-suggestions/) to avoid duplication of work, as we or others might be working on a related feature.
+##### Mbed OS maintainers


Why do we have a Gatekeepers heading immediately followed by a Mbed OS Maintainers heading, think the gatekeepers one should go?

adbridge · 2018-02-07T10:46:08Z

docs/reference/contributing/guidelines/workflow.md


-#### Further reading
+Please submit all Mbed OS bugs [on the forums](https://os.mbed.com/forum/bugs-suggestions/).


Is this right? Are we now asking people to do this rather than directly raise issues? Is this so the support team can pick these up and raise the issues themselves ?

That is correct, more update will come from support team

adbridge · 2018-02-07T10:49:20Z

docs/reference/contributing/guidelines/workflow.md


-Labels that the Mbed OS maintainers add to a pull request represent the pull request workflow states. The Mbed OS maintainers are responsible for moving pull requests through the workflow states.
+Each state is time boxed. In most cases, this is sufficient time to move to an another state. The pull request can be closed if no update is provided within the time frame.


Superfluous 'an' there

adbridge · 2018-02-07T10:50:53Z

docs/reference/contributing/guidelines/workflow.md

-All pull requests must be reviewed. The Mbed OS maintainers determine the most suitable person to review the pull request and tag that person accordingly. If a pull request requires a review from partners, the maintainers tag the corresponding GitHub group instead.
+All pull requests must be reviewed. The Arm Mbed CI bot determines the most suitable person to review the pull request and tags that person accordingly.
+
+Time: 3 days for reviewers to leave feedback after the maintainers add the "needs: review" label.


As this is going to be the bot adding this label we should re-word this to:

Time: 3 days for reviewers to leave feedback once the "needs: review" label has been applied.

I would like to do an update to this once bot is implemented and ready for action (thus it is manual at the moment)

I wouldn't like us to commit to 3 days, we may have other things on our plate and big, unrelated PR may not be a priority. I'm trying to go through my github feed twice a week, but doesn't always happen. Unless it's a guidance not a deadline.

adbridge · 2018-02-07T10:51:48Z

docs/reference/contributing/guidelines/workflow.md

+
+##### Work needed
+
+A pull request in the work needed state requires additional work due to failed tests. If a pull request is in this state, our maintainers request changes from the pull request author.


failed tests or rework as a result of the review

adbridge · 2018-02-07T10:52:29Z

docs/reference/contributing/guidelines/workflow.md

+
+A pull request in the work needed state requires additional work due to failed tests. If a pull request is in this state, our maintainers request changes from the pull request author.
+
+Time: 3 days for the pull request author to respond to the review comments.


Time: 3 days for the pull request author to action the required changes.

adbridge · 2018-02-07T10:54:23Z

docs/reference/contributing/guidelines/workflow.md


 ##### Releases

-Once we merge a pull request, we tag it with a release. This is the release in which we first publish this pull request. For patch releases, we allow only bug fixes, new targets and enhancements to existing functionality. New features only go to feature releases.
+When we merge a pull request that we will publish in a patch release, we tag the pull request with specific patch release version. This is the release in which we first publish this pull request. For patch releases, we allow only bug fixes, new targets and enhancements to existing functionality. New features only go to feature releases.


with the specific patch release version.

0xc0170 · 2018-02-07T11:15:27Z

@adbridge Updated, all comments were addressed

adbridge

One last minor typo :)

adbridge · 2018-02-07T13:39:44Z

docs/reference/contributing/guidelines/workflow.md


-Time: 3 days for the pull request author to respond to the review comments.
+Time: 3 days for the pull request author to action to the review comments.


you didn't remove the superfluous 'to'. Should say 'to action the review comments'

bulislaw · 2018-02-09T21:23:49Z

docs/reference/contributing/guidelines/workflow.md


-##### Bug reports (issues) on GitHub
+* [Anna Bridge](https://os.mbed.com/users/AnnaBridge).


Wouldn't it be easier to get an alias/group and not have to maintain that list?

Not sure if they can do that on the os.mbed.com site...

We will have a group soon (not on mbed.os though). Once done, we can update it separately. This will come in the following days

bulislaw · 2018-02-09T21:24:06Z

docs/reference/contributing/guidelines/workflow.md

+1. Ensure the relevant stakeholders review pull requests.
+1. Guide contributors both technically and procedurally.
+1. Run pull requests through the CI systems.
+1. Put label version.


That probably doesn't mean much to an external reader.

It's a description of our process, this documentation is for internal use as well as external

Exactly, I would say anyone reading it should be able to understand what's the process (external or newstarter).

bulislaw · 2018-02-09T21:27:13Z

docs/reference/contributing/guidelines/workflow.md


-Please see the [code contributions chapter](/docs/v5.7/reference/guidelines.html#style) for the guidelines to GitHub pull requests and the coding style guide.
+The bug report should be reproducible (fails for others) and specific (where and how it fails). We will close insufficient bug reports.


The bug report should be reproducible (fails for others)

If it's an intermittent issue it may not be readily reproducible.

Should we put more details what we expect to be in a report? Like versions, steps, example, expected and actual outcomes,...

There should be enough information captured so that anyone trying to reproduce the bug can replicate the environment and code versions used

Should we put more details what we expect to be in a report? Like versions, steps, example, expected and actual outcomes,...

Having how to report a bug would be nice to have, currently there is something in github template issue (not sufficient though). I'll talk to the team who will be handling issues

bulislaw · 2018-02-09T21:28:49Z

docs/reference/contributing/guidelines/workflow.md

-4. Run pull requests through the CI systems.
-5. Merge pull requests into the requested branches.
-6. Make periodic patch and feature releases.
+The last line in your commit message description should say “Fixes #deadbeef”, where “deadbeef” is the issue number in GitHub. This allows GitHub to automatically close the issue when the commit merges into the destination branch.


Couple of lines above we are mentioning not to use github for bugs, but use forums instead. It's conflicting info.

Agreed, there are two different areas here and I don't think it has been fully thought out how this is going to work in practice..

Good catch, will fix this line

bulislaw · 2018-02-09T21:31:31Z

docs/reference/contributing/guidelines/workflow.md

+
+##### Changes and additions
+
+Backward compatible changes (such as refactoring and enhancements) or new target additions can go into patch and feature releases. We only consider features and new functionality additions for feature releases.


We should describe something what a patch or feature release is. Also I'm not sure what a feature release is we should probably just stick to versions nomenclature: major, minor, patch.

We started off with semantic nomenclature but were told by the powers that be to use feature and patch instead

bulislaw · 2018-02-09T21:33:44Z

docs/reference/contributing/guidelines/workflow.md

-Labels that the Mbed OS maintainers add to a pull request represent the pull request workflow states. The Mbed OS maintainers are responsible for moving pull requests through the workflow states.
+The Mbed OS maintainers add labels to a pull request that represent the pull request workflow states. The Mbed OS maintainers are responsible for moving pull requests through the workflow states.
+
+Each state is time boxed. In most cases, this is sufficient time to move to another state. The pull request can be closed if no update is provided within the time frame.


In most cases, this is sufficient time to move to another state.

Not sure what does it mean

The pull request can be closed if no update is provided within the time frame.

Should we either define it or reword it to something like "The pull request can be closed if it's not actively maintained"

Another state in the workflow. ie go from needs review to needs ci.

We need some kind of time frame that people are aware of . If it is ambiguous and we start randomly closing PRs then people will complain. If it is a clear cut rule then there can be no complaints. After all, the time limits should be for responses not necessarily to completely fix something. This is to prevent open PRs just sitting there with no response from the authors for weeks at a time...

bulislaw · 2018-02-09T21:35:36Z

docs/reference/contributing/guidelines/workflow.md

-All pull requests must be reviewed. The Mbed OS maintainers determine the most suitable person to review the pull request and tag that person accordingly. If a pull request requires a review from partners, the maintainers tag the corresponding GitHub group instead.
+All pull requests must be reviewed. The Arm Mbed CI bot determines the most suitable person to review the pull request and tags that person accordingly.
+
+Time: 3 days for reviewers to leave feedback after the maintainers add the "needs: review" label.


I wouldn't like us to commit to 3 days, we may have other things on our plate and big, unrelated PR may not be a priority. I'm trying to go through my github feed twice a week, but doesn't always happen. Unless it's a guidance not a deadline.

0xc0170 · 2018-02-12T11:23:06Z

I cant reply to the above:

I wouldn't like us to commit to 3 days, we may have other things on our plate and big, unrelated PR may not be a priority. I'm trying to go through my github feed twice a week, but doesn't always happen. Unless it's a guidance not a deadline.

It's a guidance to begin with (3 working days). Someone should find time to go through changes. If not reviewed, a reminder will be sent.

0xc0170 · 2018-02-16T10:45:38Z

Any more reviews or all fine with all reviewers?

cmonr · 2018-02-16T19:48:19Z

Before this is merged, looks like it'll need top be rebased :(

0xc0170 · 2018-02-19T11:45:20Z

I fixed the conflict, squashed the history. @AnotherButler Please review

This update contains: - maintainers addition - issues should point to os mbed forum - time box each stage - feature branches

0xc0170 · 2018-02-22T10:24:01Z

rebased on top of the new engine

sg- reviewed Jan 23, 2018

View reviewed changes

AnotherButler reviewed Jan 23, 2018

View reviewed changes

cmonr reviewed Jan 23, 2018

View reviewed changes

AnotherButler reviewed Jan 24, 2018

View reviewed changes

AnotherButler approved these changes Jan 25, 2018

View reviewed changes

cmonr approved these changes Jan 26, 2018

View reviewed changes

sg- suggested changes Jan 29, 2018

View reviewed changes

theotherjimmy reviewed Jan 29, 2018

View reviewed changes

sg- approved these changes Feb 1, 2018

View reviewed changes

adbridge requested changes Feb 7, 2018

View reviewed changes

0xc0170 force-pushed the dev_workflow_impr branch from 5e3ce2e to a898fe4 Compare February 7, 2018 13:42

adbridge approved these changes Feb 7, 2018

View reviewed changes

bulislaw reviewed Feb 9, 2018

View reviewed changes

theotherjimmy approved these changes Feb 16, 2018

View reviewed changes

0xc0170 force-pushed the dev_workflow_impr branch from 07cbf51 to afc978c Compare February 19, 2018 11:41

0xc0170 force-pushed the dev_workflow_impr branch from afc978c to c3934ce Compare February 19, 2018 11:43

workflow: update (stage time, issues)

c64da10

This update contains: - maintainers addition - issues should point to os mbed forum - time box each stage - feature branches

0xc0170 force-pushed the dev_workflow_impr branch from c3934ce to c64da10 Compare February 22, 2018 10:23

0xc0170 changed the base branch from 5.7 to new_engine February 22, 2018 10:23

AnotherButler merged commit 67e4aac into ARMmbed:new_engine Feb 22, 2018


		Please see the [code contributions chapter](/docs/v5.7/reference/guidelines.html#style) for the guidelines to GitHub pull requests and the coding style guide.
		All Mbed OS is on GitHub; please use GitHub's [issues mechanism](https://guides.github.com/features/issues/) to open a bug report directly against the relevant GitHub repository.


		#### Reporting and fixing bugs
		* Anna Bridge [adbridge](https://os.mbed.com/users/AnnaBridge).


		Before submitting a bug report or a bug fix, please [discuss it on the forums](https://os.mbed.com/forum/bugs-suggestions/) to avoid duplication of work, as we or others might be working on it already.
		##### Stakeholders


		##### Bug reports (issues) on GitHub
		They are responsible for a specific mbed OS module or feature.


		A member of the Mbed team must verify bug fixes before we pull the fixes into the main branch. You must therefore use GitHub to fork the repo and then submit a pull request with your changes.
		All code changes and additions to Mbed OS are handled through GitHub. If you want to contribute, either by adding features or by fixing bugs, please follow the guidelines for [new features](#contributing-new-features-to-mbed-os) and [bugs](#reporting-and-fixing-bugs). In both cases, please follow the [code style guide and GitHub pull request guidelines](/docs/v5.7/reference/guidelines.html#style)</a>. Please also read the [CLA](/docs/v5.7/reference/guidelines.html#cla) guidelines because we will immediately close pull requests submitted without a CLA.


		#### Further reading
		We can only accept patch contributions through GitHub if you create a pull request from forked versions of our repositories. This allows us to review the contributions in an easy-to-use and reliable way, under public scrutiny.


		##### Features

		New features should initially be implemented on a separate branch in the Mbed OS repository. The naming convention for a feature branch is: "feature-".


		Time: 1 day for CI to complete and report back results.

		The CI workflow can be found [here](tbd)


		##### Work needed

		The pull request requires additional work due to failed tests, changes requested.


		The pull request requires additional work due to failed tests, changes requested.

		Time: 3 days to respond to the review comments.


		Before submitting a bug report or a bug fix, please [discuss it on the forums](https://os.mbed.com/forum/bugs-suggestions/) to avoid duplication of work, as we or others might be working on it already.
		##### Mbed OS tech leads


		Before contributing an enhancement (new feature, new port and so on), please [discuss it on the forums](https://os.mbed.com/forum/bugs-suggestions/) to avoid duplication of work, as we or others might be working on a related feature.
		##### Mbed OS maintainers


		#### Further reading
		Please submit all Mbed OS bugs [on the forums](https://os.mbed.com/forum/bugs-suggestions/).


		Labels that the Mbed OS maintainers add to a pull request represent the pull request workflow states. The Mbed OS maintainers are responsible for moving pull requests through the workflow states.
		Each state is time boxed. In most cases, this is sufficient time to move to an another state. The pull request can be closed if no update is provided within the time frame.


		##### Work needed

		A pull request in the work needed state requires additional work due to failed tests. If a pull request is in this state, our maintainers request changes from the pull request author.


		##### Bug reports (issues) on GitHub
		* [Anna Bridge](https://os.mbed.com/users/AnnaBridge).


		##### Changes and additions

		Backward compatible changes (such as refactoring and enhancements) or new target additions can go into patch and feature releases. We only consider features and new functionality additions for feature releases.

Workflow document update #377

Workflow document update #377

Uh oh!

Conversation

0xc0170 commented Jan 23, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnotherButler left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 Jan 24, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 commented Jan 24, 2018

Uh oh!

AnotherButler left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

0xc0170 commented Jan 23, 2018 •

edited

Loading

0xc0170 Jan 24, 2018 •

edited

Loading

0xc0170 Jan 30, 2018 •

edited

Loading

theotherjimmy Jan 29, 2018 •

edited

Loading

theotherjimmy Jan 29, 2018 •

edited

Loading

theotherjimmy Jan 29, 2018 •

edited

Loading