search

peakshift / playbook

Peak Shift Improvement Proposals
2 stars 0 forks source link

Logging internal work #4

Open J0o0 opened 6 years ago

J0o0 commented 6 years ago 
Title: Internal work -logging guideline
Author: @j0o0
Status: Draft
Type: Process

Abstract

Motivation

Specification

Please suggest #meta-tags for the issues you most frequently log for internal work.

The current main categories of work and suggested meta-tags are:

  1. Communication : #team-call #client-call #team-discussion
  2. Administrative: #accounting #documentation #README #document-management
  3. Technical: #code-push #code-test #code-inspect #code-creation #code-fix
  4. Research: #research-[topic of your research]
  5. Design:
  6. Planning: #personal-plan #client-tasklist
  7. Other:
johnsBeharry commented 6 years ago

@J0o0 there's many benefits to us having a standardised way of recording work activity so I'm happy to see this proposal, thanks!

I would recommend simpler tags to be used for #call instead of #team-call then we can use @ symbols to reference a person or group of people. This way we can compound the tags however we feel makes sense for the work being logged.

Defining too strict tags may also have the disadvantage of being difficult to remember exactly as it was defined.

We can have a directory of contacts for each project too - and be able to run more granular statistics on who calls occur between.

Examples

  1. I sometimes have calls with other teams, which we collaborate with so we can reference that group as @acmeinc or an individual on that team like @jane

  2. #team-discussion could be a #call or #chat so we can have #call with @team, @team #call, or some kind of work #discussion with @team #call

OFF-TOPIC

One of the standards we'll be implementing is in-fact the standardsiation of the way proposals are written - could you have a look at #1 for the specification which details the structure of a proposal (meta, abstract, motivation, specification, and rationale).

This proposal would still be in draft mode - which is fine as we'll add more details to what you wrote above(you or someone else can edit), when we discuss in the comments, and as we come to consensus.

Comment on #1 if you have any questions about how to format your proposals - don't want to go off-topic on this thread even more.

J0o0 commented 6 years ago

yes @johnsBeharry I agree with you on the simpler tags, as it will make it easier for the team to use.

Is there an estimate in regards to time line as to when we should finalize what tag should be used? or are these current tags in your opinion sufficient? or when you think we should try implementing the tags?

Also just to confirm you want me to use the #1 for the formal proposal when we finalize the logging procedure for internal work, correct?

johnsBeharry commented 6 years ago

@J0o0 well since there's no development time needed to use these tags people can start experimenting with them right now -- I'm already using some of them when I'm doing time tracking.

We just need to have a specification that everyone can follow so when we start to develop the automated reports we have some real data to work with. The longer we don't use a unified format the less we're able to test if it works -- short answer would be ASAP.

All issues in this repo should follow #1 specification wether formal or in draft - have a look at the other issues for reference.

selimira commented 6 years ago

Good outline @J0o0, agree with the points about simplification of the tags you mentioned @johnsBeharry. I suggest for simplification we always put the #action first then #project-name then #issue-number (@name to specify who are we talking to etc. if applicable) and then add any other meta if needed. For example I am now working on the stellar wallet UX so I write:

12 #research [research on stellar multisignature wallet]

P.S. I will start using the hashtags mentioned about from today and inform how I find them and if I can suggest any improvements for them.