If you have Tasks:
- like this in your Communities / Team groups
- that can tag Repos
Do you even need Issues?
Discussion
nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr nostr:npub13v47pg9dxjq96an8jfev9znhm0k7ntwtlh9y335paj9kyjsjpznqzzl3l8 nostr:npub16p8v7varqwjes5hak6q7mz6pygqm4pwc6gve4mrned3xs8tz42gq7kfhdw
nostr:npub1s3ht77dq4zqnya8vjun5jp3p44pr794ru36d0ltxu65chljw8xjqd975wz nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5
Nice UI btw. Issues and Tasks have different purposes. Issues are a forum for discussing a specific need (bug fix, feature, etc) which may lead to one or more task. They are also more tightly tied to a git repository.
Replies on repo ↔ Issues on repo ↔ Tasks on anything
This is the confusion weird space Issues are in from my point of view.
GitHub doesn't have replies, nor tasks, so it seems like Issues just map onto any discussion, idea, bug, feature request, etc...
Whereas here we already have:
Discussions: replies, zap messages, community/group chat/thread/forum
Tasks: nostr:npub13v47pg9dxjq96an8jfev9znhm0k7ntwtlh9y335paj9kyjsjpznqzzl3l8's general spec, we're using in #communikeys
I don't see what's lost if you just use the same event kind (Task) for Issues on a repo.
Benefit is huge for product managers that have to manage projects beyond just repos.
And anything that is not a Task, is better suited for the reply / forum / chat sections.
I'm really trying to step away from copy-pasting GitHub UX. We have more (specific) content types here and can channel them according to our goals more efficiently.
Repositorys benefit form having tracked items that aren't tasks. Where would a feature request or a bug sit in your structure?
Feature Requests, Questions, GMs, Encouragement, ... all have their place in the replies, zap messages, community forum/chat.
Bug Fix = Task.
And since it's a Task it can tag multiple repos at once. Very useful in my experience.
It can even tag the replies/notes/messages/articles of people that mentioned the bug (anywhere, not just on the repo).
As a product community manager I want to to see GMs and Feature Requests. As a developer of the product, I dont want to have to sift throug GMs, and questions to see feature requests and bug reports.
:110percent:
Anything that is defined enough to be a Task that can get done = Task.
Many "feature request" on the dev-side definitely fall into that category.
Anything that is social, open-ended brainstorming, discussion, fun interaction = Reply, Message, Forum, ...
Issues seems to have stood the test of time as it is a good shorthand for things that developers need to keep abreast of. Other things eg help and discussion seem to get moved into other channels.
I'm not sure what you mean by a reply? It seems strange to have a reply directly to a repository. There could be a chat stream for a repository that people could dip in and out of. or a reply to a discussion top or other entity.
> It seems strange to have a reply directly to a repository.
You could say the same for Zaps, Shares, Labels, Reactions, ...
This seems to be the main blindspot for most devs. I guess it's hard to imagine because GitHub deosn't have the stuff we have, by default, on **any** event.
With nostr:npub18stt78efprta2el02tzgnez6ehghzgtt000v58967wvkgezjmprs0n7h7u (and already now in nostr:npub1gm7gw8q6akeft2pjt270we35vlff0v9g2fene6cxkz2h68q5hl6qls0fte ) repos can and will get zaps, replies and reactions.
We are bringing that part together in one coherent, fun and conversational view.
My main point in this discussion is that next to that, all that's left is the "Get stuff done"-side.
For which I'd only need:
1) Tasks (which you can totally call Issues, if you will)
2) PRs
3) Docs
Zaps are a sign of appreciation. Shares are an invitation for others to check it out. Labels help people find the repo. Reactions are signal of an emotional response the repoistory. Mentions in kind 1, kind 1111, etc is bringing it up in converations. Replies seem a bit misc but with an expectation that the maintainers review the message. Help me understand what they are bringing to the party 😀
In the UI/UX we're building Zaps are more like "Superchats " that can be engaged with.
:pointright: In the Reply section (as the default)
So Zaps and Replies go hand in hand in the whole experience.
And they do indeed handle the "misc" category very well. Which is my main point.
So we can take the "misc" out of Issues and just have them be :110percent: productivity focused.
I think mixing tasks with traditional repo issues under the same kind will present a hard-to-handle filtering challenge on the app level.
Kind-based distinction should be more reliable but this is just my estimation, perhaps you could make it work.
I just know that as a dev I really don't want non-code related tasks to appear when I am sifting through repo issues. Maybe a unique tag could be assigned to distinguish them but at that point you might as well use different kinds with same or similar structures.
The same code can take care of rendering easily on the other hand
Worst case, I indeed just add the Issue event as a kind to fetch for in the Tasks section.
But to me, this is again the same debate as the one about Replies. Where the conclusion is that is using one kind (1111) for replies, on anything, is the most elegant. And you just fetch or the Replies that tag the event (or type of event) that you want to see the Replies for.
We don't use different kinds for Zaps on Articles, Zaps on Threads, Zaps on Repos, etc...
We don't do it for Replies, nor for Labels, nor for Reactions, ...
If it's the same exact event structure, with the same purpose → I'm using the same kind.
Nip-22 includes tags so we can filter based on parent kind so it makes it easier to find just what we are looking for.
Is there anything that wouldn't enable the same "parents"-based filtering with Tasks?
nip-22 isn't applied to tasks and it doesn't make sense for the repo to be the root event, the task should be.
Sorry yes, of course.
But I mean to understand why one letter tags in the Task event wouldn't have the same filtering advantages as we have with Nip-22 replies.
Would this be harder to filter than a Reply? :pointdown:
```
{
"kind": 35000,
"created_at": 1675642635,
"content": "This task is the description of the task.",
"tags": [
["d", "333e500a-7d80-4e7b-beb1-ad1956a6150a"],
["title", "Example task"],
["published_at", "1296962229"],
["t", "examples"],
["due_at", "1298962229"],
// Tagged Repo
["a", "30617:
["p", "
],
"pubkey": "...",
"id": "..."
}
```
this basically ties into the other other thread we are having with nostr:npub16p8v7varqwjes5hak6q7mz6pygqm4pwc6gve4mrned3xs8tz42gq7kfhdw about the interplay between projects and repositories. this would work if marketing.
the 'generic' critique of replies directly to repositories is that they need triaging for larger projects. This does happen anyway to some extent with issues.
If parents-based filtering is applied then the parent kind should be different for tasks and issues. But we only have repo kind I guess?
If we are filtering for the repo then non-repo related tasks won't be included. Unless the repo is also used as the root for other non-dev related related activity eg marketing.
> If we are filtering for the repo then non-repo related tasks won't be included.
Yes!
> the repo is also used as the root for other non-dev related related activity eg marketing
No. That should ideally be your project's private group or community.
Yes so in order to make parent-based filtering work in theory is to have some "project" kind that is separate from repo kind.
But if we did that, it would be equivalent to having issues and tasks separated.
The benefit I see on the side of having both projects and repos though, is that one project could encompass multiple repos and we don't yet have that afaik.
That would make it useful enough to assign a separate kind and all the non-repo tasks could refer to that instead of the repo as a parent.
I agree this is a big advtange. Just look at how tollgate has its project into 10s of sub-repositories. Its like the oposite of a mono-repo.
I agree with your take, the git issue kind currently feels narrowly scoped. I would prefer to use something more generic such as "tasks" (using a very a broad meaning), and then specialize using tags or references
Me too!
How would you reference the events (repo, figmastr file, 3D model, ...) the Task applies to?
Ideally with one-letter tags, for filtering.
Without running into the "p" tag you reserved for "assignee" etc...
And with the ability to tag more than one event.
Yes, an issue IS a Task, just more specifically tied to the repo, so basically the same format is applied. The problem would be that in some context you need to display *only* repo-issues related to the technical stuff, and other times you want to display only the broader project related stuff like tasks regarding marketing and promotion.
If you have the same kind for those, you're in trouble distinguishing between the two and are using much more resources than necessary.
Otherwise UI is mostly identical for them
Isn't that just a matter of filtering? (for tags mostly)
Current Issue spec = Issue event that tags a repo
My idea = Task event that tags repo(s)
At the Project / Community level, you can choose to filter with any of these:
- Labels: "Feature Request", "Bug", "Ideas", ....
- Repos
- Profiles
- Status
- Priority
- Activity: replies, zaps, ...
I'm used to issues being the entries on the user-facing interactions (support tickets), and if some further project action is necessary, they're linked to in a task and taken onto the Kanban board and planned into sprints. More often, the support just answers a question and closes the support ticket.
That's how we use issues in #GitCitadel, as well.
Issues are something different than discussions on the normal board, tho. What is rather useless, for a development team, is a running chat. Devs need topics with OPs, like Slack.