Contributors Monthly Time Reporting

As part of the SubDAOfication process, we have implemented the process of Working Group (WG) budgets and time reporting.

The Problem

Giveth has not had in the past any manner of fiscal accountability or rational limits in budgeting working groups, products and projects. There were also not any clear boundaries of where and how contributors spend their time, this led to many contributors starting their own initiatives or spending their time working on projects that didn’t have consensus with the rest of the DAO.

With a limited budget and many contributors, the Giveth DAO absolutely needs to put some guard rails in place on how we spend and understand the cost of different aspects of Giveth’s operations.

Purpose of Time Reporting

Following this forum post, these changes aim to achieve multiple objectives: Firstly, clarifying WG’s budget; secondly, gaining a better understanding of Giveth’s current spending and improving our ability to forecast future expenses; and finally, enhancing accountability in how contributors spend their time contributing.

When we have the budget and can fully decentralize our accounting then we can let each WG handle it’s own budget and time reporting (or not do time reporting at all if it so wishes).

From September 2022 to January 2023, we used Typeform to gather time reports. From February to April 2023, we switched to Coda. However, after receiving feedback regarding the challenges associated with these platforms, we transitioned to Clockify. Clockify provides us with greater flexibility and better project and WG categorization management. Check out this video tutorial on how to add time reports in Clockify.

Notes on Chapters and Miscellaneous Hours

  • To recap, these are the Chapters: Development, Communications, Design, DevOps

  • We encourage chapter contributors to allocate their work to a WG with an approved budget whenever possible. To simplify reporting, we’ve replaced the previous IDK/Miscellaneous tags with specific tasks and projects which can be found under each Working Group (WG):

    • Admin Tasks
    • Working Group Calls
    • New Contributor Onboarding
    • Development
    • DevOps
    • Communications
    • Design
  • Chapter Leads have a dedicated category where they can create tasks on their own for work that doesn’t necessarily fall under a WG but can be associated in their role as a Chapter Lead such as coordination and management within the Chapter.

  • The remaining IDK/Miscellaneous tags will be proportionately allocated to the relevant WGs based on contributors’ time allocation for the current month.


Hours Reported WG/Project Allocation of Hours* Final Hours Charged to WG
60 DApp WG 60 hours for DApp + 2.4 hours Community Call + 6 hours PTO 68.4
40 Quadratic Funding WG 40 hours for QF + 1.6 hours Community Call + 4 hours PTO 45.6
4 Community Calls Allocated proportionately to WGs they contributed for the current month 0
10 Paid Time Off Allocated proportionately to WGs they contributed for the current month 0
Total 114 hours Total 114 hours

*Allocation of Hours Computation:

Working Group 4 Hours Community Call Allocation 10 Hours PTO Allocation
DApp WG 4 x (60/100) = 2.4 hours 10 x (60/100) = 6 hours
Quadratic Funding WG 4 x (40/100) = 1.6 hours 10 x (40/100) = 4 hours

We highly encourage everyone to properly account their hours because it is crucial to the budgeting and cost estimation.

Please share your comments, suggestions, and concerns in this forum post so that we can collectively address them. If you have more questions and wish to engage in further discussions, you can also join the Governance call.


Thank you Freshelle for giving us more clarity on time reporting and Clockify :hugs: I know that this, being effectively used in Giveth, will provide us with a lot of valuable data, especially during the Subdaofication process. I am excited to see more of what we can benefit from this process! :grinning:


Awesome work @freshelle !

In general it’s easy to navigate these categories in Clockify and I try to be as accurate as possible. There’s one case that it’s complicated for me sometimes which is User Support/Non-user support.

User support it’s under two different WG’s (Dapp and GIVeconomy) and Non-user support is under Communitas. My problem here is that I usually give support whenever I can in Discord, but it’s not a lot (usually a few hours a month) and it just seem like over bureaucratic for the little time put in to classify it into three different categories that sometimes it’s difficult to differentiate.

Thanks for bringing this topic on the forum!


Hello Giveth, the DAO Ops crew would like to acknowledge that a few contributors are still not using Clockify. Despite posting this forum topic to open up a discussion and providing space to discuss in many Governance calls it looks like it hasn’t had the desired effect of resolving this issue.

We strongly assert that using Clockify should be mandatory within Giveth. We have offered as much support as possible to contributors who have concerns or hesitations and given people ample time to adjust and begin using the Clockify app. Some measure of budget/expense tracking is important for all of the reasons outlined in the post above.

In order to convey the importance of time reporting and using Clockify the DAO Ops team will begin penalizing contributors who refuse to use Clockify. Despite numerous attempts to accommodate and negotiate, there still seems to be a problem.

We propose that effective immediately contributors who have not been submitting time entries at all into Clockify will be deducted 20% of their quarterly GIV token vesting distribution. That will include the vesting distribution pending for Q2 2023.

If you have comments and concerns this is the place! Please speak up!

I’ll also leave this poll to get a signal from everyone:

Should Clockify be mandatory and should we enforce these penalty conditions?

  • Yes! I agree to all the above.
  • Clockify should be mandatory, but I don’t agree with this penalty.
  • No, I disagree with everything.
  • Abstain

0 voters

I have been using Clockify because it helps HR. I don’t love it, but I do it. I don’t have a better idea, and I want to respect not only the consensus but my actual colleagues who are responsible for managing the entire HR process. However, penalizing folks, I don’t know if that is ethically correct.

I also think Clockify is now way convoluted with way too many choices. We will be spending our whole work day in there splitting hairs, picking out the exact topic for every action we do all day long. It is just not practical to ask everyone to keep track of every moment of their work lives with such a detailed list of options. It is demoralizing and counterproductive.


How is it not ethically correct?

I don’t understand how it is demoralizing and counterproductive. Perhaps from your perspective it feels that way but honestly I do it daily and it takes me about 5 minutes at the end of each day to log what I did.

I agree that Clockify is kind of crazy right now with all the details and choices, we take any feedback on that part to make Clockify simpler to fill out but still maximize it’s benefit for DAO Ops.

The system is still changing and hopefully improving.

It seems unethical to me to withhold financial gains from contributors simply if they are not using a preferred tool by others.

As for being demoralizing and counterproductive, everyone works differently and enjoys and appreciated different aspects of their personal and collective work environments. You seem to enjoy engaging in a lot of administrative tasks. I personally do not. Therefore, spending time on how I spent my day hour by hour is a extremely demoralizing to me. It is also counterproductive because I feel like I am wasting my time and skills on something is not necessarily necessary (sorry about that construction, heh heh). In other words, there is probably a better way, but I have admitted not knowing that better way at this point. BUT I strongly believe (and it’s awesome you’ve recognized it as well) that the task micro-tagging in Clockify has gone a bit too far.


Sorry for typos:

…everyone works differently and enjoys and appreciates…

…hour by hour is extremely demoralizing…

…wasting my time and skills on something not necessarily necessary…


i dont like the entire HR stuff hehe. but beyond that if you goto a factory/hospital to work with a timeclock if you dont clock in/out you dont get paid .

1 Like

I understand both sides of the coin, but agree with Suga that the penalty is too much. As much as we need financial control, I do not think a penalty of 20% is something fair. We should try to see what are the concerns of those not willing to fill the numbers in Clockify, if it is a matter of being lazy, I understand it should be done but if there is a different reason we should try to work it around.


I was asked by some members to engage and vote here as well. So here’s my take:

I personally have always been using Clockify since I started with Giveth, even before I knew there was a system in place. I believe it’s the best and most honest way to track and compensate part-timers fairly.

For core/full-time members, I don’t think this is a fair system as it might discourage the full-timers to do more or invest more hours as they normally are required to.

In our company, we only require freelancers and part-timers to clock in so they can be paid fairly. And our core members always put in more than they are (officially) required with the full-time hours in order to keep up with targets and company goals. If we ask them to track hours, it may have an adverse effect as they will only stick to the required hours anyway.


I can understand these points but I still don’t think many of you are understand the perspective and importance of using Clockify and WHY is this important.

Firstly to your point @santigs - the DAO Ops crew - namely @freshelle and @Nicbals have been working for months, MONTHS accomodating all the requests and doing extra accounting work to accomodate people who simply refuse to use Clockify - they just simply refuse for certain principles they believe in.

So what’s going to be the final result? What happens when people flat refuse to participate in something that is very important to keep the DAO on track financially and hold contributors accountable? The penalty is a last resort but the context is that DAO Ops has already been at this for months around this issue.


I understand your point regarding core contributors - but since this is an organization with many working groups and each working group is responsible for managing it’s budget it is important to have the categorization of time spent.

The main misunderstanding most people have around how we use Clockify is this:

It’s not so much as important for you to report how much time you spent on certain tasks, but more how much time you spent working for each working group.

We don’t have any idea how much we spend on our products and working groups - not a clue. We have no accountability on how much time people spend working for a WG and if it justifies the perceived results from the perspective of the WG lead.

This makes it really hard for us to do any sort of financial budgeting and also very hard for WG leads to make decisions on how to lead their working groups.

In a traditional organization each employee would only work for a single department - each department could then easily know its costs. However this is not the case since many contributors spend their time in several working groups.

I know for most contributors this is just a drag - you get no benefit out of having to do Clockify. But for the organization’s accounting, transparency and financial planning I don’t see any other way than using Clockify to get us on track.


I absolutely understand measuring expenses is crucial for any project to keep under budget and know about the treasury flows to be able to react and I have no problem using Clockify or any other tool for that purpose. My take is we should understand why there are people who do not feel comfortable with it and try to put a solution in place instead of punishing them.


So far 10 votes against this but so far only 1-2 people have commented why they are against this.

If you have a disagreement this is the place for discussion!

I don’t enjoy logging things but I do it because I know there are times in an organizations development where we need to gather useful data on how we spent our time, skills and money in order to make better decisions as an organization on how we will use such resources in the future.

Deciding how to track something is a challenge but I just, pick something in what I believe to be the right group and, perhaps on analysis the information I entered will be wrong, but my doing it wrong actually helps us get it right later or simplify it further.

If I get hung up on whether I’m doing enough or too much, tracking it right, took too long or forgot to track some things here or there, I let that $h!t go… because the health and success of Giveth is more important than my comfort around providing the information. When we review it, if something pops up, GREAT! Let’s give constructive feedback and make changes and keep on building the future of Giving.

In the reality of my own roles and responsibilities, it is really helpful for ME to see how much time certain tasks actually take - I think I can “just do it” … then I look at the Clockify and realize, it took several hours that seemed to flash by in a few minutes.

For others, the reality might simply be “I DEV for X Hours This Month”. Period. Whomever you commit to getting the job done for, either says yes you did or oh no you dint, and pays you accordingly.


Docking GIVtoken vesting feels horrible. That’s just weird. It’s going back on your word, we did not put such conditions on GIVtoken vesting before, it’s a clunky hack and my gut just says YUCK. I would much prefer to see a few options of solving this discussed more transparently in this advice process… establishing penalty conditions as proposed in this way comes off authoritarian and dehumanizing in a way.


Say, the number of hours you want to be paid for must be entered into system X (Clockify now) in order to get paid because that’s what we use to calculate and distribute payroll… that’s a now forward kind of governance decision that, when we understand how much of Freshelle’s time is being expended, makes good sense for the organization as a whole to help stop that from happening.

You put your hours in for the month by date X, your accountable approver reviews by date Y, and Accounting pays out on date Z. For some it should be able to be that easy, I think?

Clockify categorization purpose is simply for payroll, budgeting, forecasting… there is a fine line though into micromanagement that we need to heed for sure, so let’s hear more on where the resistance comes from a bit more before leaping to “Some people aren’t playing the game the way we want them to, so we have to implement a new rule for everyone that means if you don’t follow it you get punished.”

PS. This post was clocked as 15 minutes of Forum Post Advice Process under Contributooors :wink:


Voted against ( although I agree we should do this for part timers and contributors )

So here’s my point of view and why I say this is unfair for core members.

Since the GM agreement We devs are often spinning multiple plates, so it kind of relates the multiple WGs scenario. Every Monday, we break down how we’re splitting our time across projects - like 60% on Giveth, 20% on Dappnode, and the leftover on Regenscore. We let our PM know it and do our best to stick with it and get our deliverables out by week’s end. It’s dynamic and relies on our ability to deliver on time and eyeball our efforts. Time estimation in software development most of the times become astrology you know… so it’s better to do it in hot with short time frames, some call it agile.

So, Isn’t it a bit of a stretch to pin down exactly how many hours and minutes we spend on a task or in a meeting? Our job isn’t a strict 9-5 thing. Some days, my brain’s on fire and I’m killing it with thousands of lines of code. Other times, I’m dying with a problem and zero lines. Weekends might also be the time, or I might not feel the work vibe at all. It’s all over the place. But still pushing to deliver on time.

And that’s why I scratch my head when we wanna say things like, “I spent 28 hours on Y project doing Y tasks.” Is that really more helpful or accurate than saying, “About half my time’s been on X project?” and “I’ll be free next week for X or Y” I’m not convinced. If I’m stuck with a project till December, you’ll know it. If I’m freeing up next month, you’ll know that too. Yes, managing resources is tricky and needs numbers, but are these hour-counts genuinely reflecting our work and creative process? also for a fixed rate on us core members, even if we worked 60 hours a week or 35 hours a week realistically we’re still getting payed what we “signed” on our agreements, no extra times, no micro-management, responsibility and deliverables. I’m a bit skeptical. It’s quite a different thing for part timers or collaborators.

Here’s a thought so I don’t come all whiny: What if we just stick to sharing our availability instead of clocking hours? Let’s keep it flexible and let the WG leaders check if our deliverables and time estimates are in the same frequency each month or whatever timeframe we’re looking at. It’s a bit gentler on our mental peace, especially for those of us feeling the stress when work doesn’t fit neatly into hourly boxes. Maybe we can try this out as a small experiment in one of our projects and see how it goes? It might not be a “one size fits all” solution, but it could offer a bit more breathing room and adaptability in our schedules. And hey, if it doesn’t work, we iterate, adapt, and try something new. We’re all about innovation and adaptation, and perhaps our time management strategies deserve a fresh look too. Let’s find a path that respects both our work and our wellbeing.

Would love to know your thoughts

PS: I didn’t mention why the penalty is a bad idea, but yeah… don’t think that’s the way


That’s really great insight into the developer problems. Most of the push back I have heard in other areas has been related to developer concerns but this was very well thought out feedback.

I agree with your point - time estimation is sort of like astrology - I totally get it. But simply not collecting any info on where time was spent after the fact doesn’t help us find the actual cost for a product or a project.

For example:

Say the EF pays us $50k to do Account Abstraction and we say sure. We make the assumption we won’t spend more than that to build it. How would we actually have anyway to know? If there’s no way to find the cost of these things how are we supposed to make good decisions in the future?

Say we get paid $50k and we spend $75k on getting it done - we would probably know to ask for more for future grants of similar size.

I agree it is tedious trying to sort your minutes and hours and blah blah into all these projects and tasks - but I think we can make it simpler.

What about at the end of every sprint (2 weeks) you gave a percentage to how much time you spent in project X Y and Z - you then divided those percentages by the total hours you worked?

Example Hours Logging

finish 2 week sprint - do a little personal retrospective in clockify. You know you spent about ~75 hours working and you estimate your time already spent in each project was:
20% dapp
20% GIVeconomy
20% QF
40% Regenscore

Then multiply each percentage by your total hours worked and just bulk log the hours into clockify, no need for day to day, minute to minute tracking!

This is already a massive improvement, and it could take you 15 minutes every 2 weeks!

Also, getting stuck on a problem and writing zero lines of code still counts as work! :stuck_out_tongue:


Thanks for everyone’s feedback. I just want to add that I totally agree with @yass and @mateodaza and others like @Danibelle and @santigs because ultimately full timers should not be tracking hours. I repeat: demoralizing and counterproductive.

And I do not agree with @Giantkin ’s analogy: we are not a factory or hospital. And everyone knows that being forced to clock in and out does not promote an enjoyable work environment. (Ever seen Charlie Chaplin’s Modern Times?)

Moreover, in the 21st century, web3 work environment, we pride ourselves on the importance of self-care, community, trust, and all the feel good concepts to do with mindfulness, autonomy, non-hierarchy and whatnot. It is archaic and counter-mission to revert to logging hours as standard business practice, and studies show it produces negative effects on contributors (and if we look at the history of this subject, we will find that significant transformations have taken place in the last century and that indeed highly skilled workers have ceased such an activity for many, many decades now). It is indeed authoritarian.

All that said, for a time it could be useful for budgeting. But this should not be the future of the way it is.

So we have two issues at work here: 1) how we feel about being forced to log hours and the philosophical implications of that, and 2) how logging hours (for a time?) can be helpful for budgeting.

To recap: 1) bad to force workers to log hours based on 150 years’ worth of reasons. 2) can be useful to get accounting organized.

I have opinions against this procedure for companies that practicing agile, which are the result of my 10 years of experience in software teams, and many times I have insisted on realizing them in organizations. Because there are a lot of reasons, I will comment them one by one.

1- Impact on management and work execution inside the teams
The purpose of Agile and Scrum frameworks is to create and build self-organizing teams, the working methods of self-organizing teams are defined by themselves, if a force outside the team tries to change the procedures, the framework and how to control it will be destroyed. You may ask why? I will try to specify it in an example:

We have to demo a special feature next week, people have committed to the team and have an estimate for their work, the complications are not clear, it may be fixed in two hours and they rest the rest of the day, and it may take 12 hours a day and they will stay up at night and finish the work. What is important is to deliver quality work and help others. I don’t care if a person do some research for 3 hours and then code, or non-stop code the whole12 hours, people are different. Someone may consult with his colleague for 1 hour, play a little video game, to let his subconscious mind solve the problem and then finish the work in an hour, I prefer to ask how the work is going instead of asking how you spent your day. Actually, I could ask how you spent your day, but I’d put him at the disadvantage of lying to me about his video game hours. This is not necessary at all.

Now, with the work sheet method, instead of trying to be creative, people go to occupy themselves to fill the form and actually report to that entity outside the team rather than to their other teammates. And rest assured, you won’t find anyone who spends eight hours a day on those categories, they practically have to lie to hide their time on social media behind those categories in a way that makes sense.

This is another example:

As a backend developer, might be embarrassed to help the front team (which is blocked by backend for a release) because it effectively prevents me from filling the hours that I could be on my current task assigned to my new project. I’m actually unintentionally will be shown ineffective by helping, because this bug could take days or hours to fix, and I can’t come up with a better worksheet to show.

With this Clockify, we shift individual motivations towards better worksheets, and that’s what I mean by changing impact on management and work execution

Read More Here:


2- Complex categories, do we want to check the budget on projects or check how they work?

Some studies have shown how different roles in the team spend their days, if you look at the pictures below, you will notice that they don’t seem to work very well. There are many jokes that a developer sometimes spends more time choosing the name of a package than the code of that package.

What is the purpose of time reporting? Is the purpose of work study or is the purpose of tracking budget allocation on projects? What I see from defined categories is to study the type of work, because categories are not feature-based, and due to the changing nature of features, releases, and team campaigns (like OPs or even comms campaigns) they cannot be consistently classified in Clockify. Many activities are spread between these work teams and cannot be divided.

I have my doubts about the effectiveness of these categories for the purposes that @freshelle mentioned.

  • Is tracking how each person spends their time in detail and on an hourly basis really useful for workgroup budget planning?
  • Isn’t it better for a work group leader to at least keep track of how to allocate time for what he planned and what actually happened?
  • Wouldn’t it be better for DAO OPS to get these numbers from the leader of the working groups, or even with a simpler questionnaire asking how time is allocated between different projects?

To better understand this issue, I will try to give an example:

I am a senior front developer, I have been involved in updating some packages for a feature on the DApp for almost a month, QF WG asked the team to make the QF for the OP round next week, due to dependencies, I have to work for at least 24 hours to fix the existing errors, to remove the blockers of QF release. I might make some hacky decisions to make temporary changes to how the DAPP works just for the sake of QF so that the team can reach its short term goal. In addition, many interactions with testers and frontends are required, which may be related to the requirements of other working groups. After spending 24 hours, with the hope that a quality product will be launched, if they ask me which work group you allocated your time to and what you did, I will definitely be stuck with the challenge of how to announce my time between these groups. I can say that it was all for the QF launch, but at the moment I was fixing the Dapp bug because of the packages, and I might have fixed other bugs for the requirements of other teams.