If you are familiar with Javascript and async programming, you likely noticed that code was processed serial, asynchronous, parallel, and not concurrently. It is similar in development.
You'll have serial process to develop a change, with concurrent development happening asynchronously in parallel. Wait, that does not help clear up the terms.
The literal dictionary definition is ambiguous and in software is used to mean sequential vs parallel tasks. A pull code change doesn't become asynchronous just because there is huge latency in waiting for approval.
No, it doesn't become asynchronous because of that. It is asynchronous because it doesn't require attention of all interested parties at the same time - instead they can do their part in the fitting time slow. The term is not ambiguous, in case of async/remote work it always means that.
I'm not sure how you can disagree with that
Well, as you see - I can. I mean, I don't disagree with what you said - of course these things are not visible in the code. But that doesn't mean I can't merge the PR.
I'm kind of tired with all this inventing new meanings of the words, just to bash branch-flow. It's not the kind of discussion I hoped for.
(Replying here, because replies to previous comments are closed - is it engine feature or deliberate action?)
The rule that, by default, merge of pull request should be done by a person who created it, is proper because that person has been most thinking on code and so sees all its peculiar: decisions made, peculiars, tradeoffs, etc. Reviewers, normally, shall approve or disapprove, but don't make final decision to merge. Anyway, the system keeps proposals and allows to get them later on.
There should be cases somebody other merges a proposal (pull request, etc.) but under special circumstances (author is on vacation / gone / sick, or there is a flaming need to merge for a release and team lead takes ownership on the merge).
For desynchronization issue (typical e.g. between USA, Europe and India team), well, in a normal situation, 1-day delay is not critical under well-established processes. But what I consider more important that
1) There shall be strict requirement on regular time band dedicated by each developer for review process. For example, up to 2 hours each working day when there are pending reviews. Only critical issues should be more important than peer review.
2) The need to review shall be easily checked by a developer. (Mail, dashboard, etc.)
3) Developer tools shall be adapted to alleviate review process as much as possible, including such cases as commit sequences, proposal versions, CI assistance.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you are familiar with Javascript and async programming, you likely noticed that code was processed serial, asynchronous, parallel, and not concurrently. It is similar in development.
You'll have serial process to develop a change, with concurrent development happening asynchronously in parallel. Wait, that does not help clear up the terms.
No, it doesn't become asynchronous because of that. It is asynchronous because it doesn't require attention of all interested parties at the same time - instead they can do their part in the fitting time slow. The term is not ambiguous, in case of async/remote work it always means that.
Well, as you see - I can. I mean, I don't disagree with what you said - of course these things are not visible in the code. But that doesn't mean I can't merge the PR.
I'm kind of tired with all this inventing new meanings of the words, just to bash branch-flow. It's not the kind of discussion I hoped for.
(Replying here, because replies to previous comments are closed - is it engine feature or deliberate action?)
The rule that, by default, merge of pull request should be done by a person who created it, is proper because that person has been most thinking on code and so sees all its peculiar: decisions made, peculiars, tradeoffs, etc. Reviewers, normally, shall approve or disapprove, but don't make final decision to merge. Anyway, the system keeps proposals and allows to get them later on.
There should be cases somebody other merges a proposal (pull request, etc.) but under special circumstances (author is on vacation / gone / sick, or there is a flaming need to merge for a release and team lead takes ownership on the merge).
For desynchronization issue (typical e.g. between USA, Europe and India team), well, in a normal situation, 1-day delay is not critical under well-established processes. But what I consider more important that
1) There shall be strict requirement on regular time band dedicated by each developer for review process. For example, up to 2 hours each working day when there are pending reviews. Only critical issues should be more important than peer review.
2) The need to review shall be easily checked by a developer. (Mail, dashboard, etc.)
3) Developer tools shall be adapted to alleviate review process as much as possible, including such cases as commit sequences, proposal versions, CI assistance.