teamniteo / handbook Goto Github PK

add to team page, 1P, heroku access to all apps, access to all repos, xero access, finance reports access on Intra, donations voting access, etc.

Another section with todo list on Onboarding doc?

Maybe add a list to whom was 1% donated?

https://github.com/niteoweb/handbook/blob/master/profit-sharing.md#1---donations

The Story

As a Nitean,
I want to update the quarterly donations policy,
so that it reflects the decision we made on IRL#4.

Description

Problem/Task

On IRL#4 we've voted on increasing donations from 1% to 10%.

Proposal

Update the Profit Sharing policy.

Pitfalls

/

Best Practices (DoD)

• Documentation is up-to-date:
  • Handbook pages

Expectations (AC)

• Updated Profit Sharing policy on Handbook.
• User Story Demo uploaded to Sprint release.

Include examples how to add issues, based on department the team member is from (dev, marketing, support etc.)

• A new groove page in apps-we-use with everything specific to using it. General stuff remains on EOS or support page.
  • For Groove [email protected] profile:
    • upload a 50x50px logo
    • first name only? (some security) (if same name use initial of last name?). Perhaps done already but should be detailed.
    • title empty?
  • more details on tagging with labels (use search feature) and signing off messages with canned replies
• The support.md need rearranging so important items are higher in list. Use bullet list not numbers.
• The general dealing with user text should be on the handbook support page. Leaving just the app-specific paragraphs

Not part of handbook but including here as a reminder:

• In support repo https://github.com/niteoweb/support/blob/master/README.md should link to https://niteo.co/projects and use the EBN and WooCart descriptions
• I don't think the word checklist is being used correctly in support docs. I shall consider alternatives, something like FAQ or common problems.

The Story

As a PeopleOps,
I want a structured interview and hiring process,
so that I don't miss anything vital and everything will go smoothly.

Description

Problem/Task

Our documentation for the hiring and interviewing process needs to be heavily updated: https://intra.niteoweb.com/people-operations/job-posting-and-interviews

Things needed to be added/consolidated:

• Workable (for job posting and managing applications).

• Hiring committee (decided organically, those who want to be part of the hiring process and has something to offer)

• Set job posting, pre-interview, and interview questions for each department (development, marketing, support, designers).

  • CBO posting: https://github.com/niteoweb/operations/issues/237
  • https://intra.niteoweb.com/people-operations/interviewing-marketing-staff
  • https://niteo.workable.com/jobs/463716/preview?show_description=true)
  • https://niteo.workable.com/jobs/587702/preview?show_description=true
  • Marbe's notes for pre-interview.

• Instructions once hired ie Trialist status and salary policy.

Proposal

Update and consolidate everything in our Handbook.

Pitfalls

Long document and can get messy.

Best Practices (DoD)

• Documentation is up-to-date:
  • Handbook pages
  • Intra docs or reports

Expectations (AC)

• Handbook includes documentation for interviewing and hiring.
• Intra documents for interviewing and job posting are archived.
• User Story Demo uploaded to Sprint release.

https://github.com/niteoweb/handbook/blob/master/onboarding.md

Make sure that no links are problematic - should we link to intra at all?

We run make linkchecker on every commit. This checks that links in our Handbook are valid.

However, some of these links are to private repositories and we have to skip the checking since the script does not have access to them.

It would be nice if it had though! So figure out how to have read-only access to those niteoweb repositories that we are linking to, and remove them from the ignore list on https://github.com/niteoweb/handbook/blob/master/Makefile#L17.

The Story

As an Nitean,
I want the handbook to be easier to navigate,
so that I can quickly look up company information.

Description

Problem/Task

The handbook is a flat-file structure so there is no grouping of similar topics making file-browser navigation harder.

Proposal

• Arrange the handbook pages into subfolders
• Update the index.md and other pages to point to new locations.
• Update templates to point to new locations.

Pitfalls

Break handbook links from places not considered

Best Practices (DoD)

• Documentation is up-to-date:
  • Handbook pages
  • Intra docs or reports
  • Sphinx technical docs

Expectations (AC)

• The handbook pages are organised into folders.
• Links to the handbook pages in templates are correct
• User Story Demo uploaded to Sprint release.

Remove docs that have been moved to Handbook.

Update first page.

The Story

Handbook documents: User story & Work process

As a Nitean,
I want my pull requests to pass/fail faster,
so that I can be more productive.

Problem

We currently use Travis CI to run tests. In teamniteo/pyramid-realworld-example-app#37 we found that CircleCI takes much less overall time to run all the test cases.

Proposal

Switch over to CircleCI.

Pitfalls

Don't see any.

Best practices (DoD)

• Documentation is revised:
  e.g. help articles, handbook pages or technical docs.
• Product users are informed. e.g. blog post describing a new major feature.
• Test coverage is 100%.

Expectations (AC)

• We have replaced TravisCI with CircleCI
• User story demo uploaded to sprint release.

For example:
Write/Update support docs. > Where (custom page) some subpage, template, what they need to include, style of writing (runbook or plain), review process, the person reviewing.

Write/Update Help Center article. > Where to edit, how to edit, what it needs, review process. Save as draft or publish at once...

Ref: https://niteoweb.slack.com/archives/C072KSRHP/p1498651301171720

Article on runbooks https://blog.softwareoperability.com/2013/10/16/operability-can-improve-if-developers-write-a-draft-run-book/ < more from dev/ops perspective not so much support.

This links to https://github.com/niteoweb/handbook/blob/master/support.md but that is customer support docs that has nothing to do with the Handbook.

Link from https://blog.niteoweb.com/how-we-work-in-niteoweb/ to https://github.com/niteoweb/handbook/blob/master/how-we-work.md

The Story

As a Nitean,
I want to add information about our open salaries policy,
so that it reflects what we've decided on IRL#4.

Description

Problem/Task

We've decided we'll have an open salaries policy. This means Niteans are able to review each others salaries, profit share and allowance.

There will be no list for simple comparing (because that is not the point) but manually one-by-one through Scrooge app for anyone who is interested so that they have better information on setting salaries.

Proposal

Update the Handbook salary policy with more information.

Pitfalls

Open salaries can cause different issues however, we've decided that the benefits outweigh the pitfalls.

Best Practices (DoD)

• Documentation is up-to-date:
  • Handbook pages

Expectations (AC)

• Add a section about our Open Salaries policy in the Salary Handbook docs.
• User Story Demo uploaded to Sprint release.

You will not fit in if you don't know about this. :P

• South Park - Underpants Business plan
• xkcd comics
• The Oatmeal, especially How a Web Design Goes Straight To Hell to remind ourselves about the nightmares of working with clients and why we went the SaaS route

@dmurko commented on Sun Jan 07 2018

The Story

As a Nitean,
I want to update our profit sharing policy,
so that the split is fairer and more motivating to newcomers.

Description

Problem/Task

With the existing profit sharing policy, we did two things poorly: we motivated overwork due to the points being based on hours worked; we rewarded team members who were longer with Niteo way too much (in practice Dejan and Nejc got more than half of the profit sharing).

Proposal

We propose to change the current formula to log(months_at_company) that will be used to calculate the points and based on those points each Nitean will get % of the total profit.

Hours also count, but only up to expected hours, no overtime counts. Vacation hours also count. We want to incentivize using vacation hours and disincentivize overtime. In other words, you receive less profit share only if you've used any unpaid vacation.

Pitfalls

/

Best Practices (DoD)

• Documentation is up-to-date:
  • Handbook pages

Expectations (AC)

• Updated Profit Sharing policy.
• User Story Demo uploaded to Sprint release.

The Story

As a Nitean,
I want guidelines on writing documentation in the Handbook,
so that documentation is consistent and readable.

Description

Problem/Task

From discussions at IRL4, it was decided to improve the Handbook: https://github.com/niteoweb/operations/issues/380#issuecomment-355834679

Proposal

The following are guidelines are to be included:

• Gender neutral language.

• Aim to use Simplified English not just plain English. I propose using this reference document: ASD-STE100-ISSUE-7.pdf

• Spelling and grammar is in American English.

• Add table of contents to pages to help navigation.

• Page length (under 200 lines) if longer consider splitting into separate sections.

• List should be sentence case as per wikipedia

• Headings should be sentence case. Sentence vs title case

• Any reference urls should be placed in the footer of the document to keep the raw text easy to edit.

• In order to standardise the letter case of terminology, it should be normal sentence case. Unless a recognized mark e.g. 'Scrum' and 'scrum master' but not 'Scrum master'.

Reference:

• gitlab handbook
• basecamp handbook

Pitfalls

Best Practices (DoD)

• Documentation is up-to-date:
  • Handbook pages

Expectations (AC)

• User Story Demo uploaded to Sprint release.

This paragraph needs to be rewritten as to not belittle our existing customers and project(s).

Our short-term mission is clear: bring the current SaaS projects to an exit or low-maintenance cash-cow mode. While in the meantime start on our long-term mission: find big problems that could be rendered a thing of the past by smart software.

removed

The Story

Handbook documents: User story & Work process

As a Nitean,
I want handbook to be ready to publish on https://docs.niteo.co,
so that we have an HTML handbook with a nice theme and can search it easily.

Problem

Currently, we point to GitHub whenever we need to link to the handbook and although this works publishing it on docs.niteo.co would be better with themed HTML generated by Sphinx.

We are also missing checks for spelling, formatting and URLs so by using Sphinx and pre-commit we can solve those issues as well.

Proposal

• Use Sphinx to generate the HTML
• Hyperlinks, both internal and external are checked by Sphinx
• Spelling is checked by Sphinx
• Add pre-commit checks for syntax and formatting issues:
  • Fix or warn about trailing whitespace.
  • Fix or warn about missing end-of-file newline.
  • Use check-symlinks to ensure not broken.
  • Perhaps use markdownlint.

Configure and publish the handbook on RTD

Pitfalls

By publishing on docs.niteo.co the handbook would not be available publicly.

Best practices (DoD)

• Documentation is revised:
  e.g. help articles, handbook pages, Intra reports or technical docs.
• Product users are informed. e.g. blog post on a new major feature.
• Test coverage is 100%.

Expectations (AC)

• Sphinx is being used to generate HTML
• Commit checks for spelling and other formatting issues are enabled.
• Handbook is published on docs.niteo.co.
• User story demo uploaded to Sprint release.

https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow

What are your ideas on where mockups should go: should they be part of defining a User Story, a separate User Story or part of the User Story that requires them?

I would not put them in the defining of User Story step because they require work that can go up to 2 SP or even higher.

My proposal:

• if 1 page mockup -> part of the User Story that requires them
• if 2+ page mockups -> separate User Story that is required to be done first

The Story

As a Nitean,
I want to make standups straightforward, quick and clear,
so that we do not lose precious time.

Description

Problem/Task

When we were 4-5, going off-topic with a few minor discussions was not that problematic. Now there are regularly 9-10 people on standups and we need to cut down on these discussions because then other people are idling.

Proposal

We had a discussion on IRL#4 and this is the summary:

• everyone on standup goes through just three questions:
  • what they've done yesterday
  • what they'll do today
  • if they have any blockers - and who they need to discuss them with
• following this general standup are specific standups for each department, scheduled when/if necessary and only with people who need to be involved: development, support, marketing, design

Pitfalls

Too many meetings for a few people.

Best Practices (DoD)

• Documentation is up-to-date:
  • Handbook pages

Expectations (AC)

• The Handbook section about standups is updated.
• Zoom alert on Slack contains this short list of questions.
• User Story Demo uploaded to Sprint release.

http://benbarry.com/project/facebooks-little-red-book

1. all names should be @mentions so they are linked to profiles
2. https://github.com/niteoweb/handbook/blob/master/how-we-work.md -> this should just be a link to the blog, let's not duplicate things
3. https://github.com/niteoweb/handbook/blob/master/standup.md -> needs to be rewritten for Zoom
4. https://github.com/niteoweb/handbook/blob/master/using-slack.md#notifying-away-time -> Needs link to Intra
5. All IRL#X should be links.
6. https://github.com/niteoweb/handbook/blob/master/using-slack.md#working-on -> strange text in parenthesis: (a very high altitude overview, don't go into too much detail. Keep it minimal.)
7. https://github.com/niteoweb/handbook/blob/master/work-process.md -> I would rename this to scrum.md
8. https://github.com/niteoweb/handbook/blob/master/history.md -> this should go on company website, and just link to it in Handbook

The Story

As a Nitean,
I want my coworkers to avoid private work conversations,
so that I'm not out of the loop on discussions that might interest me.

Description

Problem/Task

Often times people revert to private discussions between two people. We need to avoid that so that everyone knows what everyone else is doing.

Proposal

Write a section in Using Slack.

This only applies to work things. People can discuss anything else they'd like on private.

Pitfalls

We need to keep reminding people of the policy.

Best Practices (DoD)

• Documentation is up-to-date:
  • Handbook pages

Expectations (AC)

• Using Slack has a section about avoiding private work discussions.
• User Story Demo uploaded to Sprint release.

Having the company-wide Not-To-Do list is as important as having our To-Do lists. Propose items on the list as comments, the ones that get the most 👍 get published in the Handbook.

Interesting read:
https://slack.com/security
https://a.slack-edge.com/4c1ae/img/security_ent/Security_White_Paper.pdf

Slack’s personnel practices apply to all members of the Slack workforce (“workers”)—regular
employees and independent contractors—who have direct access to Slack’s internal information
systems (“systems”) and / or unescorted access to Slack’s ofce
space. All workers are required to
understand and follow internal policies and standards.
Before gaining initial access to systems, all workers must agree to condentiality
terms, pass a
background screening, and attend security training. This training covers privacy and security
topics, including device security, acceptable use, preventing malware, physical security, data
privacy, account management, and incident reporting.

The Story

Handbook documents: User story & Work process

As a Nitean,
I want to check every URL in Niteo Handbook,
so that everyone can avoid accessing broken URL when reading the Handbook.

Problem

There are several broken URL in our Handbook, e.g. onboarding process in this page.

Therefore, we need a system to find all URLs in Handbook and check the status of every URL, whether return response 200 live or 404 down.

Proposal

Add URLs checker step in local and Travis build so every PR will have its URL fixed when containing any broken URL.

Pitfalls

The URLs checker could not find the broken URLs.

Best practices (DoD)

• Documentation is revised:
  e.g. help articles, handbook pages, Intra reports or technical docs.
• Product users are informed. e.g. blog post describing a new major feature.
• Test coverage is 100%.

Expectations (AC)

• The handbook has URLs checker
• The handbook URLs checker is run locally
• The handbook URLs checker is run on travis
• User story demo uploaded to sprint release.

Discussions and technical documentation contain a lot of acronyms and a glossary would help with onboarding.

As a Nitean,
I want an extensive documentation of what we have produced so far (cronly, vortex, DMon, etc),
so that we can use them or extend them easily.

Description

Some things which are pretty ubiquitous are kind of black boxes right now.

For instance recently I didn't know how to call the cronly malware function from the command line to check ~40 blogs out of ~120, it was not documented anywhere.

Zupo evoked an idea a few months ago : having a documentation channel on Slack, we would ask application/process specific questions in there and if nobody could refer to a link to get that question answered, that would mean we were lacking documentation about that and should create it.

Definition of Done

• 100% test coverage.
• Write/Update tech docs.
• Write/Update support docs.
• Write/Update Help Center article.
• Write/Update Intra/Handbook docs.
• Deployed.

Acceptance Criteria

• Create a "documentation" channel
• Invite everyone in it

The Story

As a Nitean,
I want to simplify the Sick Leave policy,
so that I can better understand how to use it and then actually do use it.

Description

Problem/Task

I get asked all the time how to properly track Sick Hours. Apparently, something is wrong with the policy, it's too complicated.

Proposal

Move from Sick Hours to Sick Days. If you need to take two hours off, just do it, we have plenty of vacation hours, unpaid vacations, etc.

But if you need to take more than a few hours to get well, then just take the entire day to get good rest. Better to be safe than sorry.

Pitfalls

• Scrooge needs to be updated, but shouldn't be a problem.

Best Practices (DoD)

• Documentation is up-to-date:
  • Help Center articles
  • Handbook pages
  • Intra docs or reports
  • Sphinx technical docs
• Product users are informed (e.g. major feature Blog post)
• Test coverage is 100%.

Expectations (AC)

• Sick Leave policy in Handbook has been updated to reflect the move from tracking sick hours to sick days.
• Scrooge has been updated to support adding Sick Days to Niteans' data.yaml file.
• User Story Demo uploaded to Sprint release.

https://docs.google.com/spreadsheets/d/1qDPoaJ6DGBcSvgsVjZgVGRhGbasUmZ5wVZ5wUqw97HY/edit#gid=910258545

Add to full-time onboarding invite to this spreadsheet (and to offboarding).

When updating website.

https://github.com/niteoweb/handbook/blob/d21587c01b870cc23c72a8586c23e35b0a757636/people/nitean-recognition.md

In addition to peer recognition, we also have a basic reward system. Niteans can redeem the Holiday reward for 50 points and gain one day off from work, to put their feet up and relax.

IMO that comes out to too much. One option is to have once per quarter for the person that gets the most points. Or have it at a higher amount.