Add a motivation section #6
Conversation
|
See also #2 |
github-process.md
Outdated
| processes are owned by the developers themselves and everyone should feel | ||
| empowered to suggest improvements on an ongoing basis as we figure out what | ||
| works and what could be improved. The aim of this document is the set out the | ||
| basics and ensure that there's a common understanding of all the moving parts. |
There was a problem hiding this comment.
Maybe "set out the basics for "?
github-process.md
Outdated
| processes are owned by the developers themselves and everyone should feel | ||
| empowered to suggest improvements on an ongoing basis as we figure out what | ||
| works and what could be improved. The aim of this document is the set out the | ||
| basics and ensure that there's a common understanding of all the moving parts. |
There was a problem hiding this comment.
Maybe we should be more precise about which "moving parts" we want to help understanding. For instance, is tracking of (teams and tasks) dependencies among these "moving parts"?
github-process.md
Outdated
| empowered to suggest improvements on an ongoing basis as we figure out what | ||
| works and what could be improved. The aim of this document is the set out the | ||
| basics and ensure that there's a common understanding of all the moving parts. | ||
| Teams that require should overlay this document with any tweaks or changes that |
There was a problem hiding this comment.
Does this mean that there will be multiple custom flavors of this document?
There was a problem hiding this comment.
No - more that there will be conceptual overlays for different teams. So a new joiner can be told: "We use this process, with the following changes/additions ..."
There was a problem hiding this comment.
So then, there will be different flavors of the process described in this document :)
| to the main process. | ||
|
|
||
|
|
||
| Github has in built tooling for developer centric project management. We can |
There was a problem hiding this comment.
Do we know which information management wants? Do they care about having some issues and boards in YouTrack, and some boards and issues in Github? I'm all in for "developer centric" but I don't want this feature biting us in the back ;)
There was a problem hiding this comment.
The key takeaway from the process the @vincenthz et al have built is having a well defined line where the software process starts. Below this line external parties from the software dev team shouldn't need to know too much. The delineation point I'm aiming for here is the milestone. Project managers shouldn't care too much about issues/PRs - their interest should stop at "how complete is this milestone" and what is its due date.
We do need to capture this in the document somewhere - but I want to avoid too much of how things are done now seeping into a set of documents for how we do things in future if that makes sense?
There was a problem hiding this comment.
Below this line external parties from the software dev team should need to know too much.
Should or shouldn't?
There was a problem hiding this comment.
Project managers shouldn't care too much about issues/PRs - their interest should stop at "how complete is this milestone" and what is its due date.
I asked this, because I was asked by managers "which issues do you worked on" (which sounded a bit like micro-managing, but anyway). However does this assumes that management will look at our milestones in Github? I wouldn't like having to enter this information in some other system, since it is error prone and duplicates effort.
There was a problem hiding this comment.
We do need to capture this in the document somewhere - but I want to avoid too much of how things are done now seeping into a set of documents for how we do things in future if that makes sense?
Sure! That makes sense. I guess we want a very short document describing our super lightweight process. However we might need to mention somewhere (like in an appendix or separate document) what are the requirements for a development process and why, so that we have some references in case somebody asks why the current methods are not good enough.
But of course, we don't have to do this in this PR.
There was a problem hiding this comment.
That was shouldn't I've changed it.
The intention here is that PMs should be able to get an accurate idea where things are from the milestones and really shouldn't care about which issues have been worked on (or in the case of the less technical PM even what those issues really mean)
github-process.md
Outdated
| We have a pretty large development team spread across several teams. These teams | ||
| have somewhat different focuses, from formal methods engineers developing proofs | ||
| and executable specs, to more implementation focused teams. We also use several | ||
| different programming languages now. |
There was a problem hiding this comment.
Is having different PL's a problem? Why? And if so, how does the github process can help us?
There was a problem hiding this comment.
I don't think it should be a problem. I'll pad this out with a note that the process should unify across different programming cultures where possible. I.E. You should be able to come here as a programmer from language X and not have to make too huge a jump from how you've been used to doing things.
There was a problem hiding this comment.
Sure, that makes sense! Maybe this (universal?) should be another of the desirable characteristics of our dev process (together with lightweight and overseeable).
* Added a principles section and some more depth to the motivation section
dnadales
left a comment
dnadales
left a comment
There was a problem hiding this comment.
Looks good. Thanks for putting this together!
|
BTW, should we use squash and merge by default? |
No description provided.