Repositorys benefit form having tracked items that aren't tasks. Where would a feature request or a bug sit in your structure?
Discussion
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.