I assigned myself as a reviewer, but if someone wants it more, feel free to reassign.
Circling back to the topic of whether projects could replace accounts in Huly:
Based on the testing I’ve done so far, it looks like that won’t be necessary.
We can build on existing Classes and enums to add Account and Account category fields to issues.
I’m out of time for today but I’ll post a screen recording of how it works here soon.
Here is a screencast showing how to replicate Tempo accounts in Huly:
As I mention towards the end of the video, what the platform is currently lacking is support for showing time-based reports about time logged against a set of tasks.
Someone from the community asked about that here: Time sheet or time reporting · Issue #6357 · hcengineering/platform · GitHub
6 Likes
The Enum system is quite powerful, but also a bit limiting. I think it would be nice if we could further map each account itself as billable, non billable etc instead of having that be two fields in each ticket. For that I think it would be a good if we can consider having Accounts be an object like Company or Issue so that if needed we could add an account type Enum to an account for our specific categorisation.
2 Likes
@kshitij That would be a great solution, too 
How would we extend the set of existing classes, is that something that can be done at configuration level when setting up a self-hosted instance of Huly? (Maybe I’m missing something, but I just double-checked and couldn’t seem to find an option for adding a new class via the UI.)
I don’t know yet, if it’s possible with just config. If we can do it with just config that would be great. However, I’m proposing that we look into adding this feature because I feel over time it’ll probably justify the cost of implementation.
1 Like
@kshitij Agreed It would probably end up helping with a bunch of other use cases that we’re not even thinking of right now 
Just wanted to post here that I’ve completed the orientation guide for Huly. It won’t answer everything, but it should save you hours of time getting started.
4 Likes
@tikr It seems Huly has recently added a feature called “Cards” that could solve this issue for us. It’s worth checking out here.
It essentially allows you to create custom data types, and objects of that data type.
For instance, we could create an “Account” type with properties like name, and description, and add a reference to the company it belongs to, and an “Account type” enum. Right now, I don’t see a way to reference this new card type from an issue, but I’m hoping that will be a future enhancement. Or maybe I’ve just missed something.
1 Like
@kshitij Looks promising! I played around with it a bit, too, and couldn’t figure out a way to link a card to an issue either. Might be worth opening an issue for that feature to figure out if it’s something they’re planning to add?
I watched the relevant videos and this is part of their new “process” module that is also supposed to bring support for sprints etc, so I think this is just the first step in that direction.
I’ll keep a look out of this and update here when I know more.
1 Like
Huly has just released their roadmap and from I understand they are looking to make “Cards” the foundational data-type for all content, so that issues, and epics etc. all could be implemented that way. In that case, links between accounts and issues would just be links between two card types.
They are now working on “Processes” which is their mechanism for supporting sprints or other processes for managing tasks. It seems to be what they are working on right now for release in this quarter, so it might be ready before we need to work on it at all.
2 Likes
Just an update here. We’ve completed a discovery on the self-hosting element of getting Huly running and the results are here.
At the moment we’re now waiting on ArgoCD to be added to our infrastructure so that we can deploy it using the included Kubernetes manifests in a maintainable way. The main ticket for tracking ArgoCD’s addition is available here.
3 Likes
I think @gabor raised some important concerns in the epic regarding the timeline and nature of this Epic. Mainly that:
- The Epic is owned by Serenity but the Discovery is by Bebop.
- There are still parts of Huly we are evaluating, so is the decision on Huly final or not?
- What are we waiting for?
As @Fox posted above, we’re currently looking into having our own deployment of Huly which will allow us to test app and the deployment mechanism so we can start contributing the changes we’d like to see.
Some of the missing feature I mentioned in my initial post about Huly have since been somewhat implemented. Huly’s data structure is becoming even more flexible so we could soon have support for Accounts, Clients etc.
The biggest missing feature was Sprints. However, Huly is now working on Processes which is their feature that would allow us to have Sprints. Their timeline stretches across the year, but with our current budget levels (or even with unlimited budget) it would be hard for us to implement it any faster.
Implementing small features was one way to understand how good Huly is to work with and that should come from some of the deployment changes we’ll need. We’ve also found issues with the documentation and API tools that we can contribute to after the deployment work.
So is the Huly decision set, what would make us reconsider? I think that’s not something I feel as comfortable answering. Huly is still a very active project, its features meet most of our needs and the missing ones are being addressed. It’s open source, not open core; it can be deployed using kubernetes, etc.
What we still need to evaluate is how friendly is upstream. But then what? What if the huly upstream is hostile to our feature PRs? Do we then pivot to something else or accept that as a cost of an open source? If we pivot, what to?
The split of this epic across Bebop and Serenity is also unique, and if it’s better to consolidate this into Serentity then that’s worth looking into as well.
2 Likes
To clarify some of my concerns:
I have absolutely no issues with having the epic split. My main issue is lack of transparency on what’s happening right now, what is the timeline on our end, what is the plan for implementation. So, basically, that I cannot see clearly what’s going on right now and what will be done in the future.
I understand that currently we are waiting for the infra to be able to deploy Huly (I’m working on it as I write this message), but after that… what? What and when will we try contributing to see the behavior of maintainers?
This is very important. Could we set aside some budget to schedule a task (soon) to either submit a couple of bug fixes, contribute a small feature, or at least discuss contributions with upstream ? Also, why don’t we try to sit down and have a chat with one of their devs ?
For reference, both @kshitij and I have spoken with their devs on separate occasions. They seem helpful and friendly to me. The trouble we’ve had with finding a thing to contribute is mostly one of not yet identifying something.
We had a couple of ideas in mind previously–for example, we were looking at contributing a helm chart. However we decided to use a different deployment method since that effort would be too large. Another was contributing sprints, but they seem to have that underway.
I remember some annoyances when setting up the project locally. For instance, it was a bit of a pain to completely reset the state of the local install-- the volumes and containers it creates do not have an obvious way of destroying them to start over. I could take a task to revisit that, add some commands to clean stuff up, attempt upstreaming it, and report back.
2 Likes
I’m glad to hear the infra is going to be in place soon, because I agree that it’s been very unclear what the status is.
It seems like our plan has been to do a huge customization and migration project, then cut over at the end? But I now think we should aim to get vanilla Huly deployed as soon as possible so we can start trying it out. Maybe we can track the Huly deployment/configuration/customization work itself mostly within Huly once it’s deployed? And then we can start getting experience with using it, deploying updates, and contributing back to the project. I’d suggest starting with contributing documentation, especially related to deployment or anything else we’re figuring out as we go.
Even if we’re not able to switch our sprint/issue tracking over yet, could we maybe start using it for CRM functionality? I really don’t like our current CRM.
I think current status is what was reported last on this forum post here, which is that we’re aiming to do our own deployment of Huly which as @braden suggested we can use to familiarise ourselves with the deployment and update process.
The timeline is harder to estimate. If we had to implement sprints in Huly, I cannot imagine it being anything less than a 20-30hr discovery leading to 200-300 hrs of work, especially since we are entirely new to this codebase. Perhaps @tikr can correct me on this but I don’t think we have the budget for this. Since I learned that their team is already working on it it made sense to wait for their implementation.
Yes, that is the blocker for that particular task. After that, we can start using and testing and updating Huly to learn how that works, but other than that, we might just need to wait till the sprints feature lands.
I was hoping that there will be something that will come out of the deployment ticket that will require changes that we can upstream.
I think @Fox has a good idea for improving their devstack that sounds like a start. We would also like to see GitLab support, but I think that would be a pretty large task. Or we can just take some bugs from their tracker.
The idea isn’t to do a huge customisation, we might need configuration, but I don’t expect us to be running our own fork.
That is definitely the plan :-)
I think this is a good idea. The idea for the stage deployment was to familiarise ourselves with the deployment, configuration and update process, and get some on-hand experience. You’re right that it’s also probably the best way to check the current state of the project.
Contributing docs is a good idea but I think it won’t give us as good an idea of upstream as contributing code. I don’t see people rejecting free documentation, but code migth cause more issues.
@tikr How much budget can we spare for contributions here. Also if we’re eventually working with two upstreams we probably need two “Contributions” accounts since this isn’t something that would count towards CC hours.
2 Likes
Re: budgets
@kshitij You’re right. We (you, @Fox and I) talked about budgets for the Huly migration during the coworking week, and what I posted on the epic afterwards is still true:
- All tickets related to the Huly migration should live in the SE project. (At least until the end of this year: Depending on how things go in terms of both sustainability and progress with the migration, we might decide to allocate some non-billable budget for Bebop to help with remaining work next year. For 2025, Bebop doesn’t have a budget for the migration).
- When it comes to other team members taking tasks from this epic, you can determine the budget for that by looking at the number of leftover hours from the previous month. (So if total non-billable time logged against SE tasks was x in May, for example, you could give 208 - x = y hours of work to @Fox or another team member in June.
- I check budget usage 2-3 per month and record the results in this spreadsheet. (Mentioning it here because referencing the numbers from that sheet might be faster than running Tempo reports yourself.)
This should also answer the question of whether or not the epic should be split right now.
–
There’s no specific number – as long as tickets for Huly contributions are scheduled and budgeted for based on the guidelines quoted above, we should be OK sustainability-wise.
At this point, I think we might only be relying on the CoreContributor label to track time spent on upstream contributions to Open edX. So if we were to link tickets for Huly contributions to the Contributions account it might not actually interfere with calculations for CC stats. (Is that right @Fox?) And if it were, we could probably fix that relatively easily by introducing another label for
Huly contributions 
We could also consider introducing a new non-billable account as you suggested. But in terms of resulting overhead for sustainability management, it would be best/most efficient to do that towards the end of the year, when we work on setting non-billable budgets for Q1-Q2 of 2026. (If it ends up being necessary at all.)
–
Re: documentation
Huly’s GitHub repo might not have all the docs we’d want to see, but it looks like there’s an AI that knows everything there is to know about the code:
