Sheriff week

A sheriff on top of things

Being sheriff is a great way to figure out where the project is going. I found out what people are working on, what has been implemented, what new technology is getting integrated.

I enjoyed the most having people explain what they are working on and to share it with the team. Instead of reading the comments and trying to figure out the code and documentation, having an actual person explaining is a big difference.

Presenting, planning, communication

The most time I spent was on planning the meetings. Perhaps I spent too much time on that even. However, my main task being to be on top of projects, and being aware of all the subtasks we have in Telescope - it does sound similar to what a sheriff does. It helped to catch me up to speed with the whole project. Honestly, after this experience I find that we have surprisingly little new projects left to document. Sure, the ones I defined already need details and structure to them, but except those details... I really struggled to find any more new directions. Most that's left is the documentation for the older stuff.

Project for management

For the planning meeting on Tuesday I used a Project system to organize the issues I want to go through. It turned out to be a great tool! I'm not sure how well it will stick with next coming sheriffs, but at the very least to me it proved to be extremely helpful.

I first grouped issues that I didn't know a status of. Meaning, I didn't know if the work was being done, if it will be completed in time for 2.6 release, or maybe the creator dropped out. Therefore, they needed to be addressed, to figure out if the deadline works out, or they need more time.

As the time went on, we went through PRs. It was mostly Anayoliy who did the reviews. I wish I done more, since that would help me learn the code. In any case, at the very least I was aware of the PRs status and direction, even if not of the code itself.

After the planned PRs and issues were sorted out, during Triage we had a bunch of issues under 2.7 already there. We went through them to see what they are about, if people needed help and if it will be done for 2.7.

Deadlines

Something about management I learned this week is how to set and stick to deadlines. Personally I would rather people do their work if they can, unrelated to dates as much. I'm not a big fan of schedules myself. However, for the project it was important to have those lines drawn somewhere, and if you make one, you gotta stick to it. It might suck having to rush your work for a deadline, but it sucks more to have the deadline shift and be fluid.
You didn't make it to 2.6? You didn't make it.

Interesting issues

I went through each issue to see if I could find anything interesting. And that's exactly what I meant. Something new, refreshing, unusual. I found three. I added them to the project, but might as well showcase them here:

1366 - Slack integrations for failed or successful builds.

You know those terrible moments when master breaks? You'd expect there to be an alarm with people panicking and running to fix the thing ASAP. But that doesn't happen, it's just a small red x near the commit hash... The issue would do exactly that - the alarm, since people check Slack and people can panic on Slack. If you panic on GitHub, nobody will know.

1608 - Improve Accessibility Standards.

Why is accessibility interesting? Because it's a new concept. It's something that will help to learn the underlying code and will bring some positive changes at the same time. It brings that professionalism feel to the whole project and includes a bunch of steps and new technologies. Maybe the idea itself isnt' as exciting, but the process of learning and integrating it might be.

2225 - Support email notifications to users.

This is a completely new direction to learn and figure out. Having dealt with an email API before myself, it's not specifically that difficult. But there's a lot to be done there potentially, all the ways we could customize those emails and make them look cool.

A lacking area

Something I also noticed amongst those issues is how we have a bunch of tests to write. Look how many issues there are!. Sure, not overwhelmingly a lot, but I haven't seen any specialists on testing so far. It's definitely a potential area to focus on.

Notes

After the Triage I went through the recording and put everything that was talked about in the text form. I find this both a useful and a useless task. It is useful to have a record of what has been done. It is useful for those who can't attend a meeting. However, most that was done during a triage was just "is this good? - Yes. - Ok cool". Not a lot of fresh or useful infromation.

Streams?

That made me think of making a better format, some sort of a recap. Having a new format to present and overview what's been done... yea, that would be cool. I was going to have a stream about Telescope today. However, I expected to have more energy. So, not today. Maybe on weedends?

My idea is to go over what Telescope is, to overview the current projects and to go deep into just one of them. That might include an interview with a person who knows about that topic the most. Might also include fixing an issue myself on stream. I wanted to start with Satellite, but now I see we don't have many issues left there. I also know some people don't have good mics, or even if they are able to solve issues, they might still not be able to talk about them. Those are some things I'd have to figure out as I go. In any case, I will announce the stream and my plans once I have them all set.

Docs here and there

This week I didn't have much time to work on actual issues. Some work in the wiki, some labels, some meetings, project infromation here an there.. Nothing major though.

The only concrete thing - I added a template for a project.
The whole idea is to have a single system of documentation that makes sure we cover everything that is needed to know about a project. For example, I introduced an idea of teams. Commonly when you want to get into a new topic, you need someone to introduce it to you and help you out in the beginning. Having a list of people that are familiar with the topic helps with that question of "who do I ask?".

Another problem this solves is delegating new tasks to people. Now that we know people's specialty, we'd want to route similar issues to them.

A main role

As I work on Telescope, I find myself enjoying maintaining the little things. I kind of wish I had a distinct role of planning for the whole time, not just the week of being a sheriff. To be fair tho, I am already going into that role. Streams for updates, projects, ideas... yea, sounds close enough. I just don't yet have a clear definition of what it is that I do. I keep having a feeling that I'm doing nothing, and at the same time that I'm doing a lot. I still haven't written any substantial code. Which worries me.. Every time I get interested in a topic, I'm unsure if the area I want to explore is even interesting or will be good to specialize in. As I proceed with those streams, hopefully I'll find out. My current target is to start with a single microservice.