Sounds like a workaround for a missing feature that would clutter your issue tracker quite a bit?

Anyways, OneDev has an API so you could create a project within OneDev, define a OneDev build and let it run regularly (cron). That build then executes a shell script which controls OneDev via its API. That way you should be able to replicate the workflow.

However I think a better solution would be to create lots of issue boards. At least that is what I do. I have one board per developer which allows the developer to manage their assigned issues (with columns like "open", "assigned/reserved", "working on", "on hold", "done"). Then you can define an "overview" issue board which has one column per developer and shows the issues all developers are working on. This could also be done on a team basis (one "overview" per team), if you are willing to define a custom issue field describing the team the issue is assigned to. Maybe that custom field can also be automatically prefilled using a groovy script which uses the user group of the assigned developer to fill the custom field.

Next you can create weekly milestones, so that issues can be assigned to a "week". Once you do that issue boards are filtered based on the milestone selected and have a backlog which contains everything that is not part of the selected milestone.

I think with milestones, creating additional custom fields and issue states you can build a great overview and workflow using issue boards. That way everyone always has an up-to-date view of what is going on without constantly creating/closing issues week after week. At least give it a try.

Thank you for your comments and suggestions. We already do what you suggested. However, this is more for a project progress tracking. But this does not give me a quick way to see what is team working on right now.

The thing is, we have lots of projects running in parallel, each project has a list of tasks and issues of other type. On top of this, we have quite a few customers to whom we provide support. This is also all tracked in the system. Typically one support project per customer, sometimes additional projects for customers tracking custom development and a helpdesk project to track support requests for users and others.

As you can see, there is lots of going on and no matter how clever summary board you have, you cannot have a quick overview. Let's say, one developer planned to work on a new feature for our iOS app but for 2 days he is stuck helping a customer. This cannot be easily extracted from all the issues but affects project progress. I would like to be able to find this out with a quick glance in our system.

So, I got this idea from BaseCamp about the weekly plans and daily reports. These plans and reports are really brief, 30 seconds to write. So these do not impact on team time or anything, Instead they actually help each team member to focus on the right thing and help management to see what is going on.

Also, the element, that this questions are sent out as email, to which a team member responds to "fill his plan/report" makes it even more effective and less disruptive.

jbauer's build approach combined with api is the way to go. You may create a report project, and setup three CI jobs:

1. weekly runs automatically at start of each week calling the api to create todo in this week issue for every developer, and close all weekly/daily issues last week
2. daily runs automatically at end of each day calling the api to create done today issue for every developer
3. report runs every 10 min to generate markdown report based on weekly and daily issue and get the report published.

Instead of calling restful api which is quite verbose, you may call groovy script to do the job in the job via @script:scriptname.

This way everything is automated, and you get an updated report of what is to do and what is being doing.

Every developer only needs to reply the issue via email, and report job collects todo/doing information from comment of corresponding issues.