mitodl / handbook Goto Github PK

Assuming we have a page on the review process, we should mention that we our practice is to delete branches (from github) after merging.

Provide detailed instructions on integrating Touchstone authentication into a Django app via python-social-auth and SAML.

Based on a question I had today about the mitocw/edx-platform fork, it might be useful to have a list of ODL repos and a few words about how they are used.

I would value having a resource that provided annotated definitions of terms. Ideally it would focus on those terms that a Google search wouldn't turn up, like what RPC, or bees with machine guns. Also, for those terms that Google would find, annotations to provide ODL context.

This is only really passed on with experience, we should document it.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Lock file maintenance

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Related to #20 but I wanted to do a talk more focused on our history, about bugs that slipped through and tests that we wrote afterwards to test for them

I'd like to talk about writing more of our JavaScript in a functional way, probably talking about the advantages / disadvantages and looking at some code (maybe writing some code!).

@gsidebo commented on Thu Dec 22 2016

https://www.notion.so
KB discussion notes

Notion seems to tick off a lot of our boxes for a KB tool. We should take the free tier for a spin and get input from various disciplines within the team (ie: Rob, Peter, Tobias, Ferdi in addition to developers).

In terms of pricing, it is $8 per dev per month, which would come out to ~$80/month for ODL Engineering. They do mention this on their pricing page: "Schools, non-profits, and startups? Message us". We might be able to get a nice discount for MIT, so we should contact them as part of this exploration ticket.

Either way, we should make a general decision about the investment that we're willing to put down for a tool like this (@pdpinch)

Discuss tools and processes for building and maintaining a knowledge base and/or system of documentation for information that is not necessarily constrained to a single project.

I'm assuming we have standards for what "production ready" entails. I'd further assume that there are things that devs should know about, like taking configuration information in as env vars. Hoping someone could maybe write up some guidelines on what this means.

@bdero?

swiped from HipChat:

• sqaush all your commits and rename the comment to the PR title. The PR title should be in the past tense by the way so we can easily reuse it for release notes
• make sure all tests pass, you can see this with the green check mark from travis
• then it's up to you to merge the PR by clicking the merge button
• then delete the branch by clicking the button at the bottom of the PR

A brief overview of the fundamentals of building accessible websites. We would go over:

• Why accessibility is important
• What makes a website accessible?
• Using a screen reader
• Basic tips and tricks
  • alt text for images
  • labelled form elements
  • semantic HTML

from https://gist.github.com/pdpinch/961183685da2291f230e

(assuming it still works)

I'd like to discuss the benefits (and drawbacks) of pytest vs. the standard unittest library, with specific examples using the Micromasters codebase and a discussion on the steps we might need to take in order to 'migrate'. This would have a fair amount of overlap with #20 and possibly #21

Selenium can be sort of an optional topic for this one. The flexibility of the pytest framework gives us the opportunity to write and invoke Selenium tests in some really useful ways, so it may be worth discussing.

@gsidebo commented on Thu Dec 22 2016

https://www.nuclino.com/
KB discussion notes

Nuclino is another paid KB tool that looks good for our purposes. It does have a free tier which might actually meet our needs. We should test drive it with special attention to the free tier's capabilities vs. our needs. If the free tier doesn't work out, the pricing is comparable to Notion ($8.25 per user per month)

from https://mitodl.slack.com/archives/GG8B4C3JP/p1570715139029700

looks like in the case of hot fixes, we want to be sure we use the "rebase and merge" option under the merge button on github. It's probably good habit to just always use it to avoid the merge commits anyway, but I don't think github defaults to that unfortunately

When is CI used as opposed to RC?

There is Git and GitHub information that is specific to our team. For example, ODL Engineering uses a non-default branch scheme.

• mock.patch should include autospec=True
• possibly consistency around Arrange/Act/Assert
• Maybe referencing things here: http://confreaks.tv/videos/rubyconf2015-how-to-stop-hating-your-test-suite
• Set expectations around coverage (specifically testing str methods, which was new to me)
• Possibly pull information from https://github.com/sprintly/sprint.ly-culture/ ?

Discuss relative merits of squash-based merges, keeping branch history, using mercurial instead...

We have a process for this but it's not documented.

@gsidebo commented on Thu Dec 22 2016

https://taiga.io/
KB discussion notes

We can host Taiga ourselves, which is a big perk, but as a tool its top selling point seems to be its project management capabilities. We should take it for a spin to see what its knowledge base-specific features might give us.

@blarghmatey commented on Thu Dec 22 2016

After testing the wiki authoring in a virtualbox instance of Taiga it definitely doesn't seem like something that we should use for its documentation capabilities. The wiki is very rudimentary and doesn't have any good auto-discovery capabilities. We can create bookmarks into the content, but the workflow for creating a new page is to use markdown/wiki syntax to generate the link which will then create the blank page.

What are the best ways to engineer tests so that they are useful without being a hindrance. How do you write your tests so that a minor refactor doesn't result in half a day of fixing tests?

Keeping your tools properly maintained and making sure that you have the right tools for each job is important for any craftsperson. What are some tools that we are missing? What is your ideal workflow and are there pieces missing? What are your practices for maintaining and improving yourself and your workflow?