Is there anything that wouldn't enable the same "parents"-based filtering with Tasks?
Discussion
✅ EtherFi Airdrop Is Live!.
👉 https://telegra.ph/EtherFi-05-03 Claim your free $ETHFI.
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.