Managers bible #73
Managers bible #73
Conversation
kavuong
requested review from
JasonL24,
QuantumOverture,
jeffchhen,
mxthu313,
ojgao and
sarahg500
mxthu313
left a comment
mxthu313
left a comment
There was a problem hiding this comment.
don't take any i say personally
|
|
||
| ### Pre-approval: What To Do | ||
|
|
||
| * [ ] For each module,create a document that outlines the planned curriculum\(make sure to format it properly and according to the example\) |
There was a problem hiding this comment.
formatting that first point (the indentation is off)
|
|
||
| ### Role of Epics + Assigning Epic Points | ||
|
|
||
| Epics represent long-term \(in the form of GitHub issues\) that will keep you on track to finish weekly assignment,activities & labs, and entire modules. These epics should be assigned points not based on how long they will take to complete but the overall, implementation based difficulty. Activity,Lab ,and workshop epics are assigned different points and they add up to represent the total weight/points of an entire module. |
There was a problem hiding this comment.
that is an awkward place to put an aside/reflexive clause
There was a problem hiding this comment.
"weekly assignments" – p sure it's supposed to be plural
There was a problem hiding this comment.
just write out and in place of the ampersand
There was a problem hiding this comment.
"...but on the overall..."
There was a problem hiding this comment.
the spacing after your commas are incorrect in some places
There was a problem hiding this comment.
so is your capitalization. and i would not mention "weight" the first time in the last sentence without any prior preface. Also you make it seem as if weights and points are interchangeable. are they? @kavuong are they tho?
There was a problem hiding this comment.
@mxthu313 Weights do not exist anymore, just points
|
|
||
| ### Explanation of Role of Issues \(curriculum issues\) | ||
|
|
||
| Issues are assigned weekly to developers and represent a week's work that will help you reach your epics. These issues should help you push yourself further down your Epics. They should be succinct enough\(and must also follow the given format on GitHub\) for developers to understand but not get overwhelmed by too many details or work. |
There was a problem hiding this comment.
i would say "complete epics" instead
the second sentence is redundant to the first.
the "they" is ambiguous (is it referring to the epics or the issues?)
you can end the sentence at "for developers" (i think the second part is implied)
There was a problem hiding this comment.
"sufficient enough" spelling error
|
|
||
| ### Explanation of Role of Milestones | ||
|
|
||
| Milestones represent a person's and a team's weekly goals. They are comprised of curriculum issues and represent how much progress a team or person has made during a week. They will help you keep track of everyone's weekly work quota and your own work. |
There was a problem hiding this comment.
can you be more explicit about "a person's and a team's weekly goals"? how are a dev's milestones related to the team's milestones? does every team need their own individual milestone? does every individual need their own milestone? do new milestones need to be made every week? how do we know that there is "enough" in each milestone?
also the word "deliverables" sounds fancier than "goals"
|
|
||
| ### Adding Issues to Epics \(Modules + Activities + Labs\) | ||
|
|
||
| Issues\(GitHub\) should be added to Epics. On a higher level, they represent what things need to be down in order to take down an Epic and will help you breakdown your goals into more tangible ideas and tasks. Module,activities, and lab Epics will be given smaller issues that break them into more ,as previously stated, bit-sized chunks that you can further break down into weekly issues and Milestones. |
There was a problem hiding this comment.
your sentence structure is unnecessarily wordy and needlessly confusing
|
|
||
| These specific changes should all contribute one way or another to the "Pull Request Checklist" as shown above. This checklist has to be pasted into each pull request. When reviewing, it is important to focus on both the "macro" and the "micro" issues that need to be resolved. This check list helps reviewers raise issues and review in a more efficient manner. | ||
|
|
||
| Stemming from an effort to be more transparent and let developers be aware of how their work contributes to the organization as a whole, this list both ensures proper workflow and a more stylistically workflow. As more and more of the list is checked off, the developer is able to see their progress. Ideally, the list for a specific PR is completely checked off by the end of the week. |
There was a problem hiding this comment.
- "and more stylistically consistent content"
- typo on "next"
|
|
||
| ## _Quality Assurance Procedures for Managers and Developers \[Jason\]_ | ||
|
|
||
| We want to the developers and the managers to provide give their input for each aspect of our projects. Therefore, we need procedures that allow the developers to quickly and effectively work together to complete tasks while maintaining a standard of quality. |
|
|
||
| ## _Revision by Head of Developer Relations and President \[Jeff\]_ | ||
|
|
||
| Here at Bit, we place heavy emphasis that all content and material developed by Bit is up to our standards. In addition to material being reviewed by respective managers, the material will undergo further review by the head of Develop Relations, Kevin Vvuong, as well as the President of Bit Project, Daniel Kim. We have many developer teams at Bit and this process is necessary to ensure all material is synchronous and consistent. |
|
|
||
| Kevin will occasionally audit a random Pull request from a developer to a manager and ensure proper feedback is being provided. While Kevin is auditing, he will be looking to ensure the content matches Bit Project's long term goals and is consistent with the other material. | ||
|
|
||
| Daneil, as president, will also audit Kevin's pull requests to ensure quality is consistent through all curriculum by Bit Project. It will conducted in a similiar process to Code Reviews performed by managers. |
There was a problem hiding this comment.
I think we shouldn't say Kevin or Daniel, since we will be replaced eventually. Say President and Head of Developer Relations
| * [ ] Every checkbox must be addressed with a comment by the reviewer | ||
| * A comment can acknowledge that the developer did something correctly or give constructive feedback. | ||
|
|
||
| ## _Revision by Head of Developer Relations and President \[Jeff\]_ |
There was a problem hiding this comment.
Can you be consistent as to whether you use "Bit" or "Bit Project"?
Also I can totally imagine a white lady in a pant suit walking slowly and gesturing with her sightly wrinkled middle aged hands in the foreground of who knows where because it may as well be a stock photo of some generic nature or car dealership.
|
|
||
| ### Role of Epics + Assigning Epic Points | ||
|
|
||
| Epics represent long-term \(in the form of GitHub issues\) that will keep you on track to finish weekly assignment,activities & labs, and entire modules. These epics should be assigned points not based on how long they will take to complete but the overall, implementation based difficulty. Activity,Lab ,and workshop epics are assigned different points and they add up to represent the total weight/points of an entire module. |
There was a problem hiding this comment.
@ismaildude I have provided comments on your entire section here:
Role of Epics + Assigning Epic Points
Should be emphasized that epics are just GitHub issues and that Epics give hierarchical structure to GitHub issues which let us keep track of project progress within GitHub.
- "Story points" not just "points"
- emphasis that story points represent relative difficulty (i.e. one story point does not necessarily equal a certain amount of time needed)
- all that is needed to determine story points is how hard the projects are relative to each other
Explanation of Role of Issues
- should talk about relationship of micro-issues with epics
- emphasize that issues focus on the card by card changes
- should involve this link
- there should be a couple examples (with a screenshot)
Explain of Role of Milestones
- screenshot would fully illustrate it
- milestones just represent an entire team's goals per week
Adding Issues
- document and visualize process of adding an issue to epic
ZenHub
- there should be screenshots illustrating the process
- Talk about the point of ZenHub: letting everyone see the bigger picture on how their Epic projects affect the bigger picture
- overall project deadline is set by me (or Director of DevRel)
- drag and drop start and end date
|
|
||
| ### Deadlines: | ||
|
|
||
| Friday: Friday deadlines are the fist draft deadlines for your team. This means that your team members should have finished their issues and submitted a pull request to your branch for review. You should take the next few days to work on any problems that come up after review. |
There was a problem hiding this comment.
There should be an explanation of the developer and manager branch process.
There was a problem hiding this comment.
also "next few days" is just Saturday (to give developers ample time to implement changes)
|
|
||
| Friday: Friday deadlines are the fist draft deadlines for your team. This means that your team members should have finished their issues and submitted a pull request to your branch for review. You should take the next few days to work on any problems that come up after review. | ||
|
|
||
| Sunday: Sunday deadlines are the final draft deadlines for you team. This means that you should submit a pull request to master with your team's completed work for the week. There will also be a form that documents your team's work for the week that is due. |
There was a problem hiding this comment.
There should be a mention for both Friday and Sunday that PRs should follow the given pull request template in GitHub, with an example of the text and a screenshot of a completed pull request before making it.
|
|
||
| Sunday: Sunday deadlines are the final draft deadlines for you team. This means that you should submit a pull request to master with your team's completed work for the week. There will also be a form that documents your team's work for the week that is due. | ||
|
|
||
| Tuesday: Tuesday deadlines are for the issues that need to assigned to your team. |
There was a problem hiding this comment.
The issues should be raised by Monday, under our new remote paradigm.
|
|
||
| Issues are unresolved problems that developers need to address. As a manager, it is your job to raise issues for your developers and assign them each week. You should make sure that there are enough issues each week to be worked on, raising issues as you review your developer's work as well as in line for your long-term goals. | ||
|
|
||
| There are also other issues that should be raised and given as first-timer issues. These issues are generally less complicated resource wise compared to other issues. This does not mean that they are less difficult content wise. |
There was a problem hiding this comment.
there should be examples of first-timer issues.
also, there has to be two first-timer issues set per week. These issues carry over to the next week if no one joins the team. The first-timer issues are for the new people to a team filling in vacancies.
|
|
||
| * [ ] Managers and Kevin conduct code reviews through GitHub | ||
| * [ ] Checking Issues and contributions | ||
| * Each time a developer makes a Pull Request, they need to provide a list of check boxes of items they addressed for their work that week. |
There was a problem hiding this comment.
these checkboxes are from the overall development checklist
| * Each time a developer makes a Pull Request, they need to provide a list of check boxes of items they addressed for their work that week. | ||
| * When managers review each Pull Request, they must check to ensure that all assigned issues in the milestone were completed and the checkbox contributions match the assigned issues. | ||
| * [ ] Every checkbox must be addressed with a comment by the reviewer | ||
| * A comment can acknowledge that the developer did something correctly or give constructive feedback. |
There was a problem hiding this comment.
examples of positive/constructive comments should be given here
There was a problem hiding this comment.
as well as an entire code review on a couple paragraphs of curriculum, also supplemented with checkboxes addressed
| * [ ] Every checkbox must be addressed with a comment by the reviewer | ||
| * A comment can acknowledge that the developer did something correctly or give constructive feedback. | ||
|
|
||
| ## _Revision by Head of Developer Relations and President \[Jeff\]_ |
There was a problem hiding this comment.
grammar throughout the section is shaky
|
|
||
| Here at Bit, we place heavy emphasis that all content and material developed by Bit is up to our standards. In addition to material being reviewed by respective managers, the material will undergo further review by the head of Develop Relations, Kevin Vvuong, as well as the President of Bit Project, Daniel Kim. We have many developer teams at Bit and this process is necessary to ensure all material is synchronous and consistent. | ||
|
|
||
| Kevin will occasionally audit a random Pull request from a developer to a manager and ensure proper feedback is being provided. While Kevin is auditing, he will be looking to ensure the content matches Bit Project's long term goals and is consistent with the other material. |
There was a problem hiding this comment.
not occasionally, every week.
Also I am checking for the pull request template being followed, all items from the "Pull Request Checklist" being followed, and that positive/constructive comments on all checkboxes are being given. this needs to be more specific
| * [ ] Every checkbox must be addressed with a comment by the reviewer | ||
| * A comment can acknowledge that the developer did something correctly or give constructive feedback. | ||
|
|
||
| ## _Revision by Head of Developer Relations and President \[Jeff\]_ |
There was a problem hiding this comment.
generally don't mention our specific names, mention titles with our names being in parentheses the first time and no other time.
|
|
||
| ### Explanation of Role of Issues \(curriculum issues\) | ||
|
|
||
| Issues are assigned weekly to developers and represent a week's work that will help you reach your epics. These issues should help you push yourself further down your Epics. They should be succinct enough\(and must also follow the given format on GitHub\) for developers to understand but not get overwhelmed by too many details or work. |
There was a problem hiding this comment.
"sufficient enough" spelling error
|
|
||
| ### ZenHub Calender | ||
|
|
||
| You should use ZenHub as a visual deadline guide and reminder. You will create Epics that will represent blocks on ZenHub. You will then adjust their size according to their perceived start date and deadline. You will also create sub-epics\(i.e activity,workshop labs, etc.\) that will also have their own deadlines\(that will build up the main module epic\). |
There was a problem hiding this comment.
I think you should talk a bit more about the point of all this- letting your developers see the big picture
| Every week, there are a couple essential things that every manager should take care in pull requests. This checklist applies to both pull requests from developers' branches to managers' branches and from managers' branches to `master`. | ||
|
|
||
| * [ ] **Branch updated from `master`** | ||
| * [ ] Resolving all Merge Conflicts |
There was a problem hiding this comment.
I think you should talk about ways to avoid merge conflicts with your team in the first place; making sure people update to master/your branch every week, etc, ensuring that your team members are always using GitHub correctly
| 2. Approval by Head of Developer Relations | ||
|
|
||
| 3. Approval by President of Bit Project | ||
|
|
There was a problem hiding this comment.
I feel like there should be a section just about maintaining good communication with your team members (through slack?) and the importance of keeping track of everyone's progress throughout the week
Hi managers: please provide a review on just the Managers README. (Gitbooks updates every branch every time a commit is made to master for some reason)
teams/developer-relations/guide-to-being-a-manager/README.md@vkxu657 please review and edit this when they have finished editing and providing their input (I will let you know).
Reviewing Guidelines
Dates to look out for
Review of each section should be done by Thursday, 4/2
Follow-up work on your section should be done by Friday, 4/3
Please let @kavuong know if that could pose an issue.
Issues Closed
Please make one new line for each issue, otherwise not all issues will be accounted for!
...
Changes proposed in this pull request: