[Private Beta] Tasklist Feedback

[omerbensaadon]

This is a feedback discussion for the Tasklist Private Beta. Rolling out to all GitHub users this year! See docs: https://docs.github.com/en/issues/tracking-your-work-with-issues/about-tasklists

If you include a screencap or video of errors/feedback, it would be a massive help to the team

[csadorf]

The task list is currently not rendering code markup correctly. Example: NVIDIA/cuml#4960

[trallard]

Can confirm that markup (links, inline code, etc.) is not being rendered at the moment

Source: nebari-dev/nebari#1478

[omerbensaadon]

hey this shipped, forgot to update you all here

[rock-it-with-asher]

Currently looks like a solution for lack of rendering would be maintaining a single crriage-return between a previous paragraph and the current tasklist block

[sharwell]

It would be nice if it was possible to collapse this comment as resolved/fixed. Perhaps a task list at the top?

[JulienHe]

Something that will be great is to be able to change all the task into issues.
When the tasklist is getting bigger and bigger, you have to click a lot of time to change all the task into issues.

[itwasmattgregg]

Would also love bulk editing of issues. I thought I could do this by searching for issues based on tracked-by but I don't seem to be able to search issues with that.

[mtcA6]

Where are you searching? In the gh project or someplace else?

You can filter and search using the tracked by feature within a project. Now I'm curious if that same search works elsewhere I'll check and revert back w some screenshots

[mtcA6]

@itwasmattgregg in the GH issue search thing you can't search by tracked by, but in the GH project I use that to filter and that allows me to then drag and copy labels and other project related metadata across multiple issues. Let me know if that doesn't make sense and I can attempt to make a gif showing you what I mean

[miklem]

Also would be nice to apply a label pattern to the tasks. Lets say I want all the tasks to be a "TASK-# Label I set on creation" where the # is taken from the actual task #

[rzaharenkov]

Would also appreciate bulk actions and ability to customize fields displayed (e.g. I have a custom fields for estimates and it would be really handy do display them in tasks list). Maybe we can at least have an action to open an issues search in a new tab?

[itwasmattgregg]

It would be amazing when a list item was converted into an issue, if that issue automatically had the project assigned if the tasklist issue was in a project.

[CalvinWilkinson]

@TeeThais Knock it off. This isn't the place for this crap. Please stop.

[developer2112]

No it is not very complex and you have to stop hit persons if we have interest in that matter we can this is all that I want to tell.

[blairlong3]

Nudging this one, we would love to have this too. When we add task issues, we then have to add them to the project. It would be good if the task items can inherit the project from the "parent" issue.

[nasquasha]

hi there, we have stopped development on this feature but this is something we'll support in the next iteration!

[iainlane]

You can't edit linkified entries without going to the full editor. It'd be nice if the whitespace to the right of them (if any) let you edit the entry when you click it.

[iainlane]

Maybe this image helps. (I think you understood it correctly though.) The green area (actually the entirety of that line) can be clicked to edit the entry. The red bit can't though. I find it a wee bit jarring to think about the lines differently if they're issue/PR links or just text.

[omerbensaadon]

Oh interesting, so upon clicking that red area you want to be able to edit the Issue link?

To be honest, we probably won't do this. When Issues have meta-data on them (Labels, Assignees) the click area is quite crowded. Perhaps an edit option to reduce # of clicks (from remove -> add to edit) but to be honest it isn't near the top of the list.

Really appreciate your feedback, please keep it coming! Hopefully this isn't discouraging

[iainlane]

It's alright, not a huge deal. Adding an edit option to the "three dots" context menu (alongside Remove) would be better than having to reload the page to edit the markdown, that'd already be a great improvement if it could go somewhere on the backlog!

[lfrancke]

I'm with @iainlane here. In cases like in the screenshot it'd make sense to be able to click in the red bit because it'd be consistent.
If there is stuff there (labels, assignees etc.) then that's fine. I believe Iain is asking for the whitespace to the right of the last bit of content in a row to be clickable everywhere.

[iainlane]

This is a bit of a niche bug I think, feel free to move/remove

If you have a task list like

### Tasks
- [ ] https://github.com/myorg/myrepo/issues/1234

and then you add the same issue again

### Tasks
- [ ] https://github.com/myorg/myrepo/issues/1234
- [ ] https://github.com/myorg/myrepo/issues/1234

the task list stops being rendered as a task list, it reverts to being a verbatim code block.

[omerbensaadon]

not niche at all! A real bug! I have opened an issue for this :)

[big-andy-coates]

Is there a valid reason for having the same task in the list twice? Maybe the list should auto de-dup...?

[omerbensaadon]

Now this breaks in a fun new way where the tasklist just silently fails operations, we're going to get this fixed fixed sometime in the next few weeks.

We don't plan on supporting duplicate issues in a tasklist

[developer2112]

hahaha!! it is funny but if there is joke there is an interesting matter in that discussion

[shayfrendt]

I have a silly question @omerbensaadon ...

How does one close out the issue in this list without leaving the task list?

There's this great checklist flow at the end of the week like:

• did that
• did this
• *HAHA I AM THE UNCHECKABLE BOX! GOOD LUCK HOMIE! 📦 *
• next week's task
• future box I'll never check

---

As a sidenote, I love not having to switch into markdown edit mode to add new tasks. Freedom!!!! 🎉

Keep going!!

[omerbensaadon]

Woah it's a wild @shayfrendt!

You can't, we made the decision that it would be far too destructive for folks to be able to close issues from this view (for now).

If you use projects, you can actually click into the child issues with the side panel, quickly close them, and navigate back. Here's a video:

Screen.Recording.2022-12-16.at.3.01.07.PM.mov

[shayfrendt]

Thanks for the fast feedback. I hear you, and appreciate the clarity!

[turadg]

The Preview pane renders a code block. With this new feature, seeing how it works before saving the issue body would help users experimenting with it. I don't expect any mutating operations to work, but at least seeing inert controls would help.

[farmaazon]

Indeed, it works in "normal view", but preview while editing it in one of Github Projects still shows a code block.

[omerbensaadon]

this shipped today!*

* = but we still have a bug in projects 😅

We'll get this fixed!

[bebosudo]

Still seeing the tasklist as a code block in the preview unfortunately 😢

[omerbensaadon]

@bebosudo I think this fixed now!

[lfrancke]

Transferred issues are not unfurled it seems.
I kinda understand why but it'd still be nice if it worked.

[omerbensaadon]

yup this is near the top of our list, thank you for the feedback as always Lars!

[tay1orjones]

I wish "tracked by" on the project board/views could traverse the entire hierarchy and show all sub-items instead of only one level deep.

I know child items deeper than one level aren't technically "tracked" by that issue and within a tasklist, but what I'd like to see in a board/view is every issue relating to a workstream, all the way to the bottom of the hierarchy.

A couple example use cases:

• With an effort field for estimation, I could filter a board view by a single 'tracked by' issue to understand how much work is left for an entire workstream.
• Update stakeholders as to the status of workstreams at a glance by creating a view scoped to a single workstream/'tracked by'

[tay1orjones]

@omerbensaadon Yes, sorry for the confusion

[figadore]

specifically seeing to the bottom of a hierarchy

would this include seeing the full task tree from the issue view?

[omerbensaadon]

@figadore some version of that yes, sorry for the delayed reply, lots of feedback to get to here

[ElijahLynn]

This is going to be key in really nailing the problem of "observing all the work". Until then, I still need to track issues in a google doc with sub-bullets and links to the issues. Really looking forward to you solving that!

[ElijahLynn]

Hi @omerbensaadon - I'm sure your team has thought a lot about this. And I'm wondering if you have any updates to share?

[tay1orjones]

The truncation applied to issue titles could be improved. This is a ~2/3 wide window on my 13" MBA

[omerbensaadon]

I... think this is fixed now? We made some improvements to truncation

[turbolent]

Now the labels are truncated, but it is not indicated there are more labels. Maybe add an indicator.

[omerbensaadon]

@turbolent hmmm that should show up on refresh, especially if you made those edits from the Tasklist itself.

[BillChirico]

@tay1orjones How did you add labels to the task list like that?

[blaet]

When saving, a lot of whitespace seems to be generated around the task lists. That seems like a bug.

[omerbensaadon]

Also near the top of our list! Expect a fix early in the new year 👍🏼

[omerbensaadon]

Fixed!

[iainlane]

Usernames are not @-completed or linkified either in the inline editor or the rendered task list.

[omerbensaadon]

on the way! 👍🏼 , this is currently in flight

[omerbensaadon]

hey this shipped actually :D

[omerbensaadon]

hope that cat got petted

[lfrancke]

I'm sure I reported this or something similar before in the Alpha but just adding it here again because it's easier to track.

I just edited this issue stackabletech/issues#300 and it deleted some of my content.

In the edit history (I can't find a way to link to an entry in there) you can see that the tasklist should contain an entry like this:
- [ ]~~Spark on K8s operator fixed or confirmed working~~ [Spark is not affected](https://github.com/stackabletech/spark-k8s-operator/blob/main/rust/operator-binary/src/spark_k8s_controller.rs#L280); the Operator does not use Roles/RoleGroups

I understand that there is a space missing (maybe?) and the syntax might be invalid but I believe silently deleting invalid entries is definitely the wrong thing to do.

[omerbensaadon]

Ah I think this is related to the fact that we don't yet support "advanced" Markdown capabilities like links and crossed out text are coming next year but aren't yet available.

As for silently deleting invalid entries, we've got a refactor in the works which should preserve Markdown

[ElijahLynn]

I think links are working now, I just used one the other day.

[omerbensaadon]

yup this works now :)

[joepeding]

In the editor it seems like you'd be able to add text to the task list block for something like a short description of that block:

General description
```[tasklist]
It really seems like you could write stuff here, but that gets silently ignored.
### Tasks
Or here, and that is ignored too.
- [ ] Task 1
- [ ] Task 2
``` . <- dot is here to make the backticks render for this comment

This renders as:

And if I refresh and go back to the editor, that extra text is also just gone.
I'm not exactly sure how (or whether) I expected that text to be rendered, but not that it would disappear from the 'raw' input.

[joepeding]

Also, if I do:

General description
```[tasklist]
### Supertasks
- [ ] Task 1
- [ ] Task 2
``` . <- dot is here to make the backticks render for this comment

It nicely renders the list with the header 'Supertasks'. Now, I edit again and add the extra lines I had above around that and save, it just shows 'Tasks' again. And looking at the 'input', my old header is just gone and replaced by a regular ### tasks

[omerbensaadon]

you mean adding new lines before ### Supertasks clears out your original title?

[omerbensaadon]

Also, Tasklist block descriptions are very interesting... thanks for the insight

[joepeding]

you mean adding new lines before ### Supertasks clears out your original title?

Adding text on the line before and/or after ### Supertasks clears out the original title in addition to clearing out the extra added text.

[omerbensaadon]

aye, that's a "oh no we found incorrect formatting! Ah! Make sure this renders correctly!" thing on our end.

We expect these will get more resilient overtime

[AndreasWalthesVolue]

When checkbox items have a longer text that would require a line break, they are simply cut off when the first line is full.

[omerbensaadon]

Those should actually be wrapping... You may have had this before we made the change, can you edit and re-save?

[AndreasWalthesVolue]

Works now, thanks a lot!

[Souleimenblh]

Thank you

[nate-dipiazza-shopify]

Can task have a history in case you delete or click by accident.

[Wiliam8]

The Gith tub discovered some memory and created new code, but it's still inadequate.

[alex-page]

Deleting task lists freezes the GitHub UI for a good 5-10 seconds. There is no indicator that something is happening while the task list is being deleted.

[richy486]

Can we add a quick option to send a task to the top please?

[gavindidrichsen]

Hi @azenMatt. One of the things I loved about tasklist was that I could create simple lists of tasks very easily. Only some did I want to convert to an issue actually. Now with "create sub-issue" I can only create issues. Can you please give us the option of a "draft" non-issue?

[CodyALohse]

Adding the ability to create "draft" issues seems like it would be the best middle ground for those of us that used the Tasklist to track non-issue/minor related items. I'd like to avoid creating sub-issues for these minor items and I also don't want to have to edit the comment each time I want to add a check list item. My organization is also setup so that each task/sub-task that gets created sends a email notification to the entire team, I'd prefer to not have to spam my co-workers each time I want to create a sub-task. I think "draft" issues is the way.

[justyn]

@CodyALohse @gavindidrichsen what if issues could be at the level of the Project itself, rather than a specific repository? Then you could create an issue type "Draft" and use that as you describe, without having to assign it to a repo.

The bonus would be the "Draft" issues would have the full capabilities of normal issues if needed (eg custom fields).

To be clear, Github will need to support Project-level issues for this to work, but that has been discussed before. See also here.

[zolotokrylin]

The tasklist solution is much better and solves ops problems much better than that sub-issue solution.

I hope you will never deprecate Tasklist, as we already have access to it. We don't want to move to Subtasks.

[FSDKO]

I love(d) the tasklists an in my opinion it has some advantages over the new sub-issue solution.

• place it somwhere inside the issue text
• place multiple instances of them in one issue
• add/remove/edit items directly (not possible with checklists)
• add simple "text"-tasks before you convert them to an issue

All in all the taskslist is/was a great feature for structuring complex (epic) issues and we learned to love it. 😢
We work(ed) with it every day.

[zolotokrylin]

100%!

[zolotokrylin]

Now with sub-issues it is just becoming another Jira :(

[jameslamb]

Seeing this in a repo I work on:

Tasklists will be sunset on April 30th, 2025
We encourage you to migrate your issue tasklist items to sub-issues. Learn more in our Changelog.

That links to a page that does not exist:

[nasquasha]

sorry about that, fix with correct link is on the way!

[Stanly-Rodriguez]

Please, don't deprecate this feature!!!

[evi-liu]

👋 GitHub PM here. Unfortunately, we had to make the tough call to sunset tasklists in favor of sub-issues. Candidly, our reliance on markdown for tasklists made it very difficult to scale.

Tasklists give us the flexibility to choose whether to create an issue or not
Another advantage is that we can place Tasklists anywhere in the issue description—not just in one place, but multiple times

Checklists should still support both of these use cases! Plus, we now offer a convert checklist to sub-issue feature, so you can choose to keep items as simple checklist tasks or turn them into full issues.

We've also seen many issues structured with multiple checklists in different sections, like the screenshot below. While I know this may not be as polished as the tasklists UI, it should still help with organization. We’re also actively exploring ways to introduce sections for sub-issues to improve this experience.

[TWiStErRob]

With the sunset, is it possible to find all the places with task lists? We have thousands of issues, and only some of the have task lists. Some already converted to sub-issues. It's impractical to open and see each.

Also related to sunset: please increase the allowed number of sub-issues, there's no migration path when an epic has more than 50. We awkwardly had to resort to overflowing the sub-issues list into a task lists.

[evi-liu]

is it possible to find all the places with task lists?

Unfortunately, I don't think there's any way. The idea is that as you come across issues with tasklists, you can convert them to sub-issues. After task lists are deprecated on April 30th, you'll still be able to see them in raw markdown—they just won’t be rendered as interactive tasklists anymore, so no data will be lost.

please increase the allowed number of sub-issues, there's no migration path when an epic has more than 50

The current limit for sub-issues per issue is 100.

[tklaas]

Hi @evi-liu

• Subissues are great for epics or simply sub taks that will be done later
• Checklists are great for lists what has to be done when issues are created
• Tasklists are great for quick notes during development to track what has to be done.

What is the part that you want to get rid of?
The tracked by link? The % counter x of y completed?
Both is not needed but there are 4 other essential parts that I would like to see added to checklists:

• A button for adding a list
• A title with a card surrounding the complete list
• An "Add item to [title of tasklist]" input field
• Drag and drop items to prioritize the list

All 4 features are accessable right now without switching into edit mode for the issue.
Switching to edit mode (=Markup) distracts you from the actual context since you have to find the place where you want to add a new chekclist or add a checklist item in a different looking view (formatted issue vs. markup).
This can be used to structure the work for this issue in smaller parts or just to organize a developers thoughts without beeing distracted.

I would realy love to see these features added to checklists

Edit:
just saw your comment here, that you already added this as feedback to your backlog ❤️
https://github.com/orgs/community/discussions/39106#discussioncomment-12306208

[SanjayVas]

There's two cases that sub-issues absolutely do not cover:

1. Tracking code scanning alerts. Note that there's no guidance at all in the changelog entry how to migrate existing issues.
2. Two-way linking multiple PRs to an issue. Right now if you link a PR, it automatically closes the issue. There's no way to indicate all of the small PRs that may work towards closing an issue without filing a sub-issue for each PR. Note that tasklists wasn't really great for this either, but it was the best we could do.

Also for some reason I never saw the warning banner in this screenshot, so I had no idea this was coming.

[jay-cohen]

@azenMatt

We imagine this has already been explored by you and your team, but we wanted to share our thoughts, especially since we were disappointed to see TaskLists being phased out.

Our workflow: We typically have a single ticket that covers research, build, and QA/review, moving through our GH project board to release. TaskLists were a great way for us to create lightweight, visual to-dos that didn’t require full issues. Each area could check off tasks as they were completed without adding extra admin overhead, which is especially important for SMBs like us. Sub-issues, while useful in some cases, would add too much administrative burden.

Would there be a way to maintain that level of separation—similar to the example below—while still using regular checklists? The visual distinction TaskLists provided was a big win for us in GitHub, and we'd love to see something similar retained.

[evi-liu]

Thanks for sharing, @jay-cohen, and totally understand the value of the visual distinction that tasklists provided. Have you tried setting up separate checklists like in the screenshot from this comment?

I know it's not quite as nice as the tasklists UI, but will still allow you to create lightweight, visual to-dos that don't require full issues.

[MarkoVerbancic]

Thanks for sharing, @jay-cohen, and totally understand the value of the visual distinction that tasklists provided. Have you tried setting up separate checklists like in the screenshot from this comment?

I know it's not quite as nice as the tasklists UI, but will still allow you to create lightweight, visual to-dos that don't require full issues.

This solution works, but it introduces additional steps, as users now need to enter the editor to add a new task to the checklist. This increases dependency on Markdown, which wasn't previously required. TaskLists has been one of the most valuable features introduced in recent years for project management, making it easier to transition fully from other PM systems to GitHub. Unfortunately, this change feels like a step backward and may lead teams to reconsider their project management platform.

[jay-cohen]

@evi-liu We initially used checklists but very quickly found that Tasklists worked much better for us. The way each list is visually grouped made things simpler overall and we saw a clear boost in productivity. Plus, it helped cut down on issue/ticket creation by 50% in most cases.

Would there be room for a middle ground? Maybe a way to visually structure checklists to be more like Tasklists, but without the added "convert to sub issue" infrastructure?

[qodfathr]

Improvements to list editing that do not require going into the markdown editor would be very welcomed. Reorder/Add/Delete feel like key desires. Eliminating tracks and tracked-by functionality is fine and I suspect was one of the major development headaches of tasklists.

Sub-issues are great for hierarchies. Lists are great for, well, lists, so, +1 on hopefully finding some middle ground.

[evi-liu]

Truly appreciate all of the helpful feedback here! And yes, I'm hoping we can find a good middle ground. I hear you that it would be nice to not have to enter the editor to add, reorder, or delete checklist items. I will add this to our backlog to have our team take a look and see what we can do.

[sarahhobbs]

If I do not migrate my tasklists to sub-issues what will happen? Will it just be downgraded to a plain checklist? I have a substantial number of tasklists and I need to know how to update them accordingly.

[evi-liu]

It will just convert to the raw markdown. For example, it'll look something like this:

- ```[tasklist]
- - [ ] task 1
- - [ ] task 2
- - [ ] task 3
- ```

[sarahhobbs]

Thanks!

[taoliujun]

sub-issues is a complex feature for the simple module.

In the past, we focused on one issue, quickly see the task progress, and quickly see the title and description of each task.

And now, you need to go to each sub issue and look at the description. generate lots of issues in the issue list page.

IT IS A TERRIBLE UPGRADE.

[bigben79]

In our org, our engineers are really complaining about not having the task lists. After talking with them, what they miss the most is:

1. The ability to have a task list that is defined by markdown
   and
2. Can be manipulated outside of markdown (right now you have to edit the markdown to update, move or add any new tasks)

Sub-issues does a good job for project planning, but it falls short of a great developer experience. The current design of sub-issues will never cover the above developer experience with tasks list. If you brought back that functionality, I know of a lot of devs that would be A LOT happier 👍

[tklaas]

see: https://github.com/orgs/community/discussions/39106#discussioncomment-12344452

[ElijahLynn]

so true, what a backwards step in developer experience. I just found myself thinking about coding up an extension to at least take care of inserting a new task list, and adding new tasks without having to edit markdown. But, WHY am I even wasting time thinking about doing this. GH already coded it up, then took it away!!! It is GH's job to make the developer experience better not worse. Problem decomposition tooling is your job GH, do better.

What a PITA this change to sub-tasks has been. I'm so angry 😠 😡 .

[ElijahLynn]

Add back GitHub Tasklists Beta to Refined GitHub Browser Extension

Hi all. I created an issue on the refined GitHub browser extension to add back this critical functionality. Maybe GitHub could open source their code and contribute it back to the community. Or if any GitHub devs have some insight into the best way to do this, please leave comments on this issue.

• Recreate GitHub Tasklists Beta refined-github/refined-github#8455

[unitycoder]

unusable for small projects, i dont have time to start managing sub-issues and what not..
tasklist was simple for everyone to understand, if you want subissues sure you could have added them as additional feature, not to replace existing perfectly working todo list.