Nostr Web Client

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

Niel Liesmons 7mo ago

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.

Reply to this note

Please Login to reply.

Discussion

DanConwayDev 7mo ago 💬 3

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.

Niel Liesmons 7mo ago 💬 2

Is there anything that wouldn't enable the same "parents"-based filtering with Tasks?

DanConwayDev 7mo ago 💬 2

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.

Niel Liesmons 7mo ago 💬 1

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": "..."

}

```

DanConwayDev 7mo ago

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.

Five 7mo ago 💬 1

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?

DanConwayDev 7mo ago 💬 1

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.

Niel Liesmons 7mo ago

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

Five 7mo ago 💬 1

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.

DanConwayDev 7mo ago

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.