no partner label anymore?

[Keyrxng]

Devpool tasks are being created with no partner label anymore and it's not clear whether that was intentional or not

It's also not clear (to me at least) anymore the intended logic of the devpool and what the expected behaviours are now. I'm also still under the impression that there are critical issues with the devpool backend that have not been resolved yet which I'd imagine is a business priority to address since it's one of the most user-facing aspects of the DAO?

To get a clearer picture on things quickly I'm requesting comment on this spec, thank you.

@0x4007 @rndquu @gentlementlegen (should probably tag Zug if this repo is now his scope, dm'd instead)

[rndquu]

Devpool tasks are being created with no partner label anymore and it's not clear whether that was intentional or not

Not sure why it was removed. The Partner label is indeed missing in get-directory-issue-labels.ts. Anyway its absense doesn't affect the work of https://github.com/ubiquity/devpool-directory anyhow.

It's also not clear (to me at least) anymore the intended logic of the devpool

The intended logic of the https://github.com/ubiquity/devpool-directory is to show all github issues across all repositories from opt.json.

I'm also still under the impression that there are critical issues with the devpool backend

If you see a critical issue with the devpool backend you may file a new github issue at https://github.com/ubiquity/devpool-directory-tasks/issues

[Keyrxng]

The intended logic of the https://github.com/ubiquity/devpool-directory is to show all github issues across all repositories from opt.json.

I meant the lower level behaviours sorry.

1. https://work.ubq.fi/ is showing assigned issues, it used to be we'd handle this via the backend with the UNAVAILABLE label so either the logic behind it is incorrect or not required at all anymore.
2. https://github.com/ubiquity/devpool-directory/blob/__STORAGE__/devpool-issues.json now seems to be the 'DB' for the frontend as opposed to the devpool repo issues the way it used to be.

If the JSON is the DB and not the repo issues anymore then we could simplify the devpool logic significantly - #46 wants all issues to be inside the JSON it doesn't care about state/conditionals anything as it appears the frontend will now perform the filtering. Essentially the devpool repo issues are pointless and could be removed entirely in favour of just the JSON.

My point is, work.ubq should not be showing assigned tasks afaik and it's a problem with either the backend or frontend but it's unclear to me what should be done to resolve things since the logic in this repo was changed recently.

[rndquu]

Should be handled in ubiquity/work.ubq.fi#148