Rethinking Toggl projects to get better insights

International Processes
1

Hello everyone, stemming from the discussions that we had back in the gathering, I make a proposal having two things in mind:

  • We won’t never track it all and there’s little value on trying to do so
  • We need to know the main areas of work and how they relate to our budget so we can take more informed decisitions

For that, I’d go with a first simple step of tidying up the projects and start tracking the basics. Here is the list and what I understand by them, please share your ideas/additions:

Sysadmin: anything related to ofn-install plus server management such as provisioning, deployment or dealing with incidents (what we called operations). For now, I don’t think we’ll need to differentiate between them.

Bugs: I didn’t know this one existed until the gathering. I started using it when I’m dealing with a bug either fixing or investigating its issue, or even when discussing it with product. I propose we keep it that way. It’ll shed some light on how much time we spend on them.

Dev: obviously programming hours but also any other task that requires dev know-how like answering questions on Slack, debating on community, etc. But those that are not included in the categories above. This leaves us with features and general tech discussions.

Testing: pretty clear I think. Any time we spend testing.

Release: I heard some people suggesting this. It makes sense since it is one of the areas we want to improve.

In any case, it’s important we state the id of the PR or issue always. AFAIK most of us have been doing it so far.

These are the tech ones (and we could start creating/cleaning these) but I’d like others to share their ideas on ATAP stuff. I can think of: funding, communication, instances support, but I’m sure there are others.

What I don’t find an easy solution for is tracking specific features like PI or subscriptions. Tags? Do we need it at all?

So, I’d say we start with an agreed list for tech stuff and iterate from there. Then, I will document them.

1 Like
2

awesome, sounds good.
we will have a list of the epics, right? like PI, Subs v1, API, Mobile, etc

Some thoughts you may want to incorporate:
I’d keep “Code Review and Merge”.
I’d add “Tech Debt” as a separate entry.
I’d remove “Dev” or maybe call it “Dev Other Features” because all dev should fall under “Bugs” or tech debt or one of the tech epics right?
And I’d divide sysadmin in “Ops” and “DevOps”, it’s very different to spend money on maintaining the servers running and up to date (ops) from improving processes and tools like ofn-install (devops). Ops is something that could be managed by local instances, devops is not.

3

we will have a list of the epics, right? like PI, Subs v1, API, Mobile, etc

that’s exactly the doubt I have. How we keep track of this but still having the other axis: sysadmin, regular development, testing, etc? the only way I know of is using tags. This way we can know how much time is spent on testing for instance, across all epics.

Agree on all the other suggestions (I totally forgot about code review and merge). I wasn’t sure if it was worth splitting sysadmin in two but it does make sense. I also like to have more visibility of the ops side.

4

yeah, I’d keep testing as separate thing and for development/developers we can create tasks for every big epic, otherwise we use the default “Dev - Other features”

5

I’d like to know other’s opinions @Rachel, @danielle, @MyriamBoure, @Kirsten, @Jen? If we go with this it has to make sense to all of us. We want to have meaningful and actionable data not just something else to care about.

Another question I have is, where should this be documented?

6

I think it is great but if I remember correctly we are paying toggl per user right?

I’m tracking my time testing on the French free toggl account so it is stored somewhere (the data exist).

But if I’m joining the global account, that means the toggl licence is more expensive. Would this be worth, although we don’t pay tester?

I mean I can also download my time entries on excel if we need to know how much time we spend on testing.

7

@Rachel Kirsten created an account for you and me some months ago… and yes we are paying on a per user base. I think you should track the testing time on the global Toggl as it’s definitely global team time.
Also @luisramos0 if I remember well you were tracking your time on your own Toggl, are you on the global one ?

If you feel like you need to track time on dev stuff I definitely understand, and I had the same comments as Luis (rename Dev “new features” and add tech debt, as bugs also involve devs…).

About tracking time for ATAP, as I said I think I am personally not able to track my time as doing 10 things at the same time all the time… and things are so entangled, when I participate to an event for OFFrance to network, my intention is to try to raise funds for OFFrance to fuel the global pipe, is it time I would put on fundraising on global ? … this is just one among thousands of examples IMO… and I’m just bad at tracking my time, the way I work doesn’t fit that… I’m not closed of course if others thing we really need to go in that direction, but I might be on the side of the “laggards” on that one :wink:

When @Kirsten gave me and Rachel access to global Toggl that was when we were trying to better track our time and organize our tracking, but when trying the process I just realized it doesn’t work for me, so I think it might be better to remove me access to global Toggl, no ? We might have tried some categories, etc. so maybe we need to clean a bit the tags we added in global Toggl (do you remember @Rachel ?)

8

@MyriamBoure back in Drome we agree with @Kirsten to remove my access as my time was not taken into account as a paid time. So currently I don’t have access to the global toggl.

I still think it is a good way to go: we should all track our time so that we can say we spend XX time on research and development etc. Some specific funds will need precise invoices. But to do so we can all download our time from our own toggl accounts rather than paying for this feature. I’m not sure I understand the value of the global toggl account.

Tracking your time is not about launching a timer each time you work on something @MyriamBoure it is about knowing by the end of the week how much time you spend on main topics and then be able to change your habits or share the load. It is not something that needs to be precise by the second :wink: If you are able to do this without a tool, good for you! I’m really impressed :slight_smile:
But if a developer ask to not track his time, would we agree as well? I know that on the other project I work on, having this data is a must to help me manage the project.

9

Ok, so as I see it’s more about pipe stuff, what it takes to deliver the software, as it’s we want to improve first. To me, if there’s no data about time spent on bugs, operations, feature dev, etc. we won’t base our decisions on facts but intuition and we can’t afford that IMO given our limited resources. To me, that includes testing @Rachel.

So unless someone disagrees I’ll keep things lean and implement my proposal plus @luisramos0 considerations and doc it (incuding the reason why we want each of those) in OFN’s wiki. Better ideas?

Although I’d like to see everyone in the core team (remember that is everyone involved in the delivery pipe, not only devs) to stick to it, I’m ok if only devs start tracking this way. cc @Matt-Yorkley @maikel @kristinalim

10

@Rachel I understand your point but I stand from another perspective, as I was saying I see more my income as a basic income allowing me to contribute full time and I do my best to be productive as much as I can all the time and we discuss about priorities so I don’t decide alone what I work on but I do use my time the most efficiently possible on things adding value to the project… we had some conversations in Drôme about that… So I’m not tracking my time with another tool, I’m just not tracking my time.

I understand the value it can have theoretically (to be able to transfer task, know what we spend time on to see if the value it gives worth it, etc.) but emotionally it brings about some other feelings, that Matt shared for instance, like “spending a whole day checking my mails can I count that time ? Is it productive time ?”, etc. My personal answer is trust that we do the best of our time. It’s maybe more philosophical… If the community decide every contributor on any task concerning the OFN should track his/her time I guess I will consent to it and do my best… I don’t want to block that process if you all feel it is the way to go.

But I really would like to have some deeper conversation in some next global gathering on this. You know, between the industrial / optimized models where we start to track time to optimize everything we do to cut cost, separation of work, specialization of work, etc. Vs the “handcraft man” spirit, being fully into what he is doing without even being conscious of the time that pass…

Sorry to bring that conversation to another space… feel free to ignore what I’m saying, and move forward in the operational aspect of it.

@Rachel raised a point you didn’t answer @sauloperez about do we need a global Toggl or just personal Toogls and aggregate reports somewhere ? If we added to a global Toggl all the non-tech stuff that will start to cost a lot… I have no opinion but maybe worth investigating.

11

I have been tracking my time on the global toggle, at least I can see the categories there :slight_smile:

12

I’m tracking my time on the global Toggle. It’s okay when I focus on one bit of work and I don’t have to touch the timer for hours. When I’m switching tasks and contexts all the time, I find it difficult and it’s a waste of time to switch the timer every 30 seconds and wonder: “Where does this task belong?” I’m probably taking ten minutes now to write this post and it’s still counted as pull request review of #4047 because that’s what I did last and I don’t even know where to put this time. It’s important though.

Philosophically, I agree with Myriam. I’m able to track my time but it’s not fun. It’s an overhead. But I also know that it’s difficult to trust sometimes and if I’m only paid for certain hours then I have to count them somehow.

Technically, I understand Pau’s desire to use the data we already have and make it more useful with some consistency. And the more detail we want, the more overhead it creates. So we have to find a balance in between. Averages work quite well with fuzzy data as well.

The main question for all data collection is: What do we do with the data? Pau said that he wants to optimise how we work. But how does that look like? Would you review the data once a quarter and if we spent 40% of time on new features then you would tell the team that it’t too much and we need to spend more time on fixing bugs? Where does this data fit into our decision process? Which difference does it make?

I’m not asking these questions to say it’s all useless. The data can be very useful. But I think if we work out first what exactly we want to achieve with the data then we know exactly which data we need to collect for that purpose.

Pau, can you share more thoughts about the decisions you would like data for?

13

In my previous company we started tracking our time because we were doing research and development and we were certified by special grants. Those grants require detailed info : how much time you spend during a year writing scientific articles, networking, code reviewing etc

The first year I had to be able to justify those hours for my company without people tracking their time regularly and it was a huge pain. I’m just mentioning it because this is something that someone can ask us someday for Datafoodconsortium @MyriamBoure so we will need to create this data somehow.

@maikel I don’t know if it helps but I don’t think we need to know the time spent per PR. I must say I don’t track my testing time per PR currently, let me know if I should @sauloperez .

I think that using a timer is too complex and will never show the reality… but we don’t need reality. We need to know per day the average time spend on those categories. Don’t we?

14

That’s exactly it.

IMO tracking code review per PR it’s way too much however, I started doing it recently in very particular and long reviews. Still, I don’t think it provides much value.

To answer your question @MyriamBoure

do we need a global Toggl or just personal Toogls and aggregate reports somewhere ?

IMO that misses a bit the point since we’ll have to spend countless hours trying to mix them and make sense of the numbers.

And to answer you @maikel

Pau, can you share more thoughts about the decisions you would like data for?

Simply put, I’d like to understand how much time it takes to:

  • prepare a release to then decide if it’s worth considering continuous delivery (not continuous deployment)
  • deal with all instances operations in the core team
  • deal with ofn-install
  • how much we spent with bugs vs. new features.

My hypothesis is that having rough numbers for each of those will help make better decisions for the success of the project.

Also, are we all aware that Toggl has browser extensions that make very easy to track tack from almost any app? Github, Trello, Google calendar, Google docs, etc.

My personal view, given my experience with it at Coopdevs, is that no matter how we feel about it, we are still developing OFN in a context where the money is key. I wish we had all the resources of the world but they are quite finite while at the same time we want it to succeed. That being said, I’m happy to stop it here the team decides it. No hard feelings.

15

Ok, so to move things forward, I created the project Tech Debt, Testing, Release, Operations (which I’ve been usin for a few days already) and DevOps following the proposals shared so far. At least this way whoever wants to differentiate this areas while tracking time can do it.

I have the feeling that it’ll be hard to diferentiate between Operations and DevOps @luisramos0 as sometimes the former leads you to opening a PR on ofn-install. We’ll see how it goes though.

1 Like
16

I can try my definition: it’s all Operations up until your git diff shows something, that’s where DevOps start :slight_smile:

1 Like
17

@sauloperez can you add me again to the global toggl account? :slight_smile:

18

Done with your OFF email @Rachel

19

@sauloperez thank you! I think we need also @lin_d_hop and @danielle on toggl to have a full overview of the testing side.

20

This all seems good to me. I agree that we need some data. I am happy that we no longer need to track by specific project in OFN as the prioritisation is happening elsewhere to ensure we are making best use of money (and I no longer need to keep track of who’s money is paying for what - YAYA!)!) I would still ‘like’ to be able to see how much we spend on particular things, as I would like us to have a better management process for blow-out i.e. when something gets in the pipe as a quick win, and six months later we’re still haemorrhaging! But if is too much overhead to have projects differentiated I accept that