[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: rapidsai/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

[wabbenhuis]

Option to hide completed tasks in a list

[wabbenhuis]

Option to upgrade a task list issue to an untracked/regular issue

[nstarman]

I believe this is now supported?

[plotner92]

Noticed that when adding a bunch of tasks in quick succession the list can't always keep up and overwrites some previous edits or removes the latest tasks entirely. It's a bit inconvenient to wait 3-5 seconds every time I edit/add a task before I can edit/add another!

[shmokmt]

It would be nice if reorder tasks with the task list by drag&drop.

Thanks!

[thompson-shaun]

I believe it does that already?

[shmokmt]

I didn't notice.
Drag and drop is possible by hovering over the icon to the left of the task name.
thanks!

[TWiStErRob]

With the addition of relationships and parent/sub-issues

Can we please have a menu item on the Task list to convert to sub-issues?!

Related: https://github.com/orgs/community/discussions/139932#discussioncomment-10831726

[azenMatt]

👋 Hi all, I am going to go ahead and close this discussion based on our recent release of sub-issues.

If you are interested, please sign up here to try out sub-issues which will eventually replace tasklists.

We are currently collecting initial feedback on sub-issues as we look into what a migration plan from tasklists -> sub-issues would look like.

Thank you again for all the feedback and support on this discussion!

[mawburn]

Thanks for the update on moving from tasklists to sub-issues.

Quick question: It looks like sub-issues can only have one parent issue, which works well for Epic-style Issues. But what about cases where we want to track related issues or have a task under multiple parents, like we did with tasklists? They seem to be limited to a one-to-one relationship.

Is the goal for sub-issues to cover all the same use cases as tasklists, or should we stick with regular checklists for those scenarios?

[azenMatt]

For the moment I would stick with regular checklists. In the future we would like to introduce additional relationship types to cover those scenarios

[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!!!

[tomo-kn]

I totally agree!! This feature is really useful.

[tomo-kn]

Unlike sub-issues, Tasklists give us the flexibility to choose whether to create an issue or not, which is incredibly convenient.

[tomo-kn]

Another advantage is that we can place Tasklists anywhere in the issue description—not just in one place, but multiple times—allowing us to structure sections more effectively. In contrast, sub-issues must always be linked under an issue, limiting their flexibility.

[Stanly-Rodriguez]

Another advantage is that we can place Tasklists anywhere in the issue description—not just in one place, but multiple times—allowing us to structure sections more effectively. In contrast, sub-issues must always be linked under an issue, limiting their flexibility.

Right on the money, @tomo-kn

[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.