Close Assigned Issues - Githubissues

0x4007 commented 7 months ago

We do not want assigned issues to render on work.ubq.fi

The simple solution would be to close them (that way they would not be categorized as an "open" task)

The more complex solution would be to have special logic in the UI for the unavailable label but I feel that closing as not planned might be better? Then we can close as complete if it is actually closed as complete?

However, the original issue was resolved according to the spec here and that was just to remove the unavailable bounties from the devpool repo was it not?

You're right. I read the following as "closing" the issue which means that it would not render in the work.ubq.fi UI

if bounty is unavailable (i.e. assigned to some bounty hunter) and exists in the list with the state open then close such bounty

With an emphasis on

then close such bounty

So we need to file a new issue and get a new pull request to actually close them?

Originally posted by @pavlovcik in https://github.com/ubiquity/devpool-directory-bounties/issues/11#issuecomment-2017567237

Keyrxng commented 7 months ago

see https://github.com/ubiquity/devpool-directory-bounties/issues/11#issuecomment-2017595979

rndquu was laying the way for removing the unavailable label completely at least that's the direction I was being pushed with hiding the unavailable bounties from the devpool

0x4007 commented 7 months ago

I don't understand what you're saying but this still remains an active issue.

This one is on the directory and is currently assigned: https://www.github.com/ubiquity/pay.ubq.fi/issues/196

jordan-ae commented 7 months ago

@pavlovcik is this available to work on?

Keyrxng commented 7 months ago

@okhot just do /start so no one takes it first buddy, this is available tho I was going to grab it myself but gl with it

I don't understand what you're saying

I was referring to the removal of the unavailable labels from the devpool

The more complex solution would be to have special logic in the UI for the unavailable label

This seems backwards if those labels are being removed

jordan-ae commented 7 months ago

@Keyrxng thanks

jordan-ae commented 7 months ago

/start

ubiquibot[bot] commented 7 months ago

! Too many assigned issues, you have reached your max limit

jordan-ae commented 7 months ago

Didn't notice I got assigned the other bounties 😅. Thanks I'll pass on this one

gentlementlegen commented 7 months ago

@pavlovcik Wouldn't it be easier to have this handled directly via the fetching step inside of work.ubq.fi? Seems more like a visual change with filtering rather than changing logic inside of here.

0x4007 commented 7 months ago

The simple solution would be to close them (that way they would not be categorized as an "open" task)

Seems more intuitive for me to implement across all tooling that interacts with the data, which includes the statistics calculation json within this repo that is intended to be displayed on ubq.fi

I don't feel that the unavailable label is the right approach

Ekep-Obasi commented 7 months ago

Hi @Keyrxng, I'd like to give this a shot

Ekep-Obasi commented 7 months ago

/start

ubiquibot[bot] commented 7 months ago

! action has an uncaught error

gentlementlegen commented 7 months ago

The simple solution would be to close them (that way they would not be categorized as an "open" task)

Seems more intuitive for me to implement across all tooling that interacts with the data, which includes the statistics calculation json within this repo that is intended to be displayed on ubq.fi

I don't feel that the unavailable label is the right approach

If for some reason tomorrow we wanted to display these tasks and add a sorting parameter about them, we should revert this. To me it comes as simple as filtering out issues that have an assignee, which is straightforward and requires only one line of code change in work.ubq.fi

Edit: I noticed in the devpool that no one is assigned on the issues, which doesn't allow for sorting by assignee. Maybe actually assigning someone to the issues could be a solution, so we can directly sort using GitHub API?

0x4007 commented 7 months ago

It's not possible unless they are added to the org/repo as a collaborator I already looked into that. Please let's just go with the spec.

ubiquibot[bot] commented 7 months ago

@Ekep-Obasi the deadline is at 2024-03-26T11:06:41.592Z

0x4007 commented 7 months ago

/start

You need to set your wallet address @Ekep-Obasi

Also for obvious reasons we don't allow people to make multiple GitHub accounts just to get around assign limits. You will be unassigned if things aren't getting done in time.

In addition if anybody frontruns the delivery on this I would credit them as this is an emergency task

Keyrxng commented 7 months ago

Would that be bad karma for the frontrunner? 😂

gitcoindev commented 6 months ago

we don't allow people to make multiple GitHub accounts just to get around assign limits

An interesting concept to game the system, if one can type fast 😂

jordan-ae commented 6 months ago

We're not the same person 😅 he's my brother though. We have similar names. It's from the git history that we're different people. Changed my git name to make it less similar

0x4007 commented 6 months ago

Would that be bad karma for the frontrunner? 😂

We don't have it formalized but I think that high priority (emergency) tasks should be free-for-all because we need it done at any costs, figuratively speaking.

Ekep-Obasi commented 6 months ago

/wallet 0x6665c09B7473bd174329B93C13281D1B902bA053

ubiquibot[bot] commented 6 months ago

! action has an uncaught error

rndquu commented 6 months ago

@pavlovcik This feature (if partner issue is assigned then it will be closed in devpool) is already implemented, we see assigned issues at https://work.ubq.fi/ because of https://github.com/ubiquity/devpool-directory-bounties/issues/22

gentlementlegen commented 6 months ago

/query Ekep-Obasi

ubiquibot[bot] commented 6 months ago

- Invalid body for query command 
-  usage /query @user

gentlementlegen commented 6 months ago

/query @Ekep-Obasi

ubiquibot[bot] commented 6 months ago

Property	Value
Wallet	0x6665c09B7473bd174329B93C13281D1B902bA053

0x4007 commented 6 months ago

@pavlovcik This feature (if partner issue is assigned then it will be closed in devpool) is already implemented, we see assigned issues at https://work.ubq.fi/ because of #22

I'm at the conference so I can't efficiently handle novel situations. What should we do here?

Keyrxng commented 6 months ago

What should we do here?

https://github.com/ubiquity/devpool-directory/pull/1159 this aims to take care of things

0x4007 commented 6 months ago

@rndquu would you be able to address this?

rndquu commented 6 months ago

@rndquu would you be able to address this?

Already addressed in https://github.com/ubiquity/devpool-directory/pull/1159 and https://github.com/ubiquity/devpool-directory/pull/1158

Keyrxng commented 6 months ago

@rndquu should this be closed as not-planned then considering it's already been handled by yourself and in my test coverage PR?

And a new issue should be opened for improving test coverage specifically, or should this be closed as complete with the merging of my PR?