Internal Task Listing

[0x4007]

Objective

List private tasks for organization collaborators.

1. fork devpool-directory to be devpool-directory-private
2. modify the code of private to get all our private repositories.
3. check if the user is a member of the organization by querying the user profile details when they log in.
4. if they are a member, then display the private issues from devpool-directory-private

Original Spec

I want to start a brief discussion/brainstorm around how we should handle this scenario:

Due to a tremendous amount of non-disclosure agreements signed related to card issuance, the card issuance repository has been made private for core team only.

We have a new task which is of high priority (should be functional in time for fundraising in March) https://github.com/ubiquity/card-issuance/issues/34

I think that the work.ubq.fi interface is the best for our team to find new tasks to work on, but it can only see public issues, as it loads all of them from the devpool-directory's issues.

work.ubq.fi/src/home/fetch-github/fetch-issues-preview.ts

Line 16 in 69ca27e

const freshIssues: GitHubIssue[] = await octokit.paginate("GET /repos/ubiquity/devpool-directory/issues", {

Perhaps the directory can load every issue, including private issues? I'm not sure if its a privacy concern because it exposes the issue title, but without the issue body! Seems like a suboptimal solution but it is the most direct solution.

The issue body in the devpool-directory (mirror) is only a link to the source issue (which requires the user to have permission to view) however from our work.ubq.fi UI, we can use the user's authentication to fetch the issue contents.

[0x4007]

rfc @ubiquity/software-development

[rndquu]

I think that the work.ubq.fi interface is the best for our team to find new tasks to work on, but it can only see public issues, as it loads all of them from the devpool-directory's issues.

The core team already sees all of the issues in github's private repos.

This issue seems to be mission critical so it makes sense to assign it to somebody from the core team hence it's ok to hide it from https://work.ubq.fi/. You've already stated that we need public issues as a sort of triage while high priority features should be implemented by the core team.

Overall I don't see any NDA violations here. If the API provider is worried about exposing its API docs or routes then here we could:

1. Remove all API provider mentions
2. Remove all URL to docs or routes
3. Make an issue description very general and provide details only on demand (like API docs, routes, etc...)

If we "generalize" issue descriptions at https://github.com/ubiquity/card-issuance we can simply make the whole repo public.

[0x4007]

The core team already sees all of the issues in github's private repos.

I don't believe that every individual on the team goes through the repositories manually to find new tasks. I do think there is a better chance to make it a habit to have the core team use the work.ubq.fi interface regularly when incentives are implemented and aligned correctly (particularly when compensation is handled entirely by the DevPool system vs base pay/salary.)

If we "generalize" issue descriptions at https://github.com/ubiquity/card-issuance we can simply make the whole repo public.

I agree but in practice I don't like the idea of tiptoeing around what we can and can not discuss. If its private we don't need to spend extra time or energy worrying about non-disclosure in the form of new tasks, code, documents, or conversation.

[molecula451]

it might take a bit but the integration sounds like a bit straightforward for anyone from the core team, btw I am no sure how the idea comes to hide/unhide tasks if we're planning to keep relevancy of the work on work.ubq.fi i still think critical tasks fits best in private over here

[0x4007]

i still think critical tasks fits best in private over here

You think its best to manually check the private repositories on GitHub for new, high priority tasks?

[molecula451]

perhaps a subdomain does it! core.work.ubq.fi

[0x4007]

Okay so you're suggesting an entirely new approach from the UI where the flow is:

1. Authenticate with GitHub (mandatory to proceed to next step)
2. Load the issues across all of our private repositories

This makes sense but unfortunately seems work intensive (it sort of makes the existing logic, and the existing devpool-directory issues redundant.)

[molecula451]

Crypto Top-Up Card + Ubiquity (Dollar) Staking Shares Enable + Github issues to be tackled in proportional + Super Pull request reviewing 🤑 let it come

[gitcoindev]

Or create a private devpool-directory-private-repositories / devpool-directory-restricted or a similar named GitHub repository which would collect tasks from private repositories and would be accessible only to the core team.

The internal devpool for private repositories could also be integrated with https://work.ubq.fi/ after login by adding a button 'Core team tasks for private repos'. Visible for core team only, would fetch issues from devpool-directory-private-repositories. But I would see this only as a nice to have feature.

[0x4007]

This approach is interesting because it's basically forking the "backend" which means it should be quick to set up!

ubiquity-internal-directory

On the UI we can probably make an extra network request based on if the logged in user is a collaborator on the organization.

I see how it can scale to other partners from the front end but not sure on the backend.

[kamaalsultan]

Is it core-team only issue? @pavlovcik

[0x4007]

It can be done by external contributors but it would be significantly more burdensome to set up. I do not recommend you take on this task.

You would need to set up all of the infrastructure, which includes 1. a new organization 2. fork the devpool directory for your organization 3. private repositories with mock issues and the correct labels to work with the devpool directory.

[kamaalsultan]

It can be done by external contributors but it would be significantly more burdensome to set up. I do not recommend you take on this task.

You would need to set up all of the infrastructure, which includes 1. a new organization 2. fork the devpool directory for your organization 3. private repositories with mock issues and the correct labels to work with the devpool directory.

Is it complicated?

[devpanther]

@pavlovcik since there is a sign-in with GitHub on work.ubq.fi, I think we can display ard issuance issues if the signed-in user has access to it.

is this up for the taking or has anything changed?

[0x4007]

@pavlovcik since there is a sign-in with GitHub on work.ubq.fi, I think we can display ard issuance issues if the signed-in user has access to it.

is this up for the taking or has anything changed?

If it is that simple then let's do it. I assumed we had to make custom accommodations beyond just authenticating one request?

[0x4007]

You can try your approach if that works but I'm skeptical

[devpanther]

You can try your approach if that works but I'm skeptical

It's going to work but more than 2 hours.. the bot is going to get the authenticated user PAT to fetch the private repos (if it does not fetch then they don't have access, I picture a checkForAccess type of function so it skips fetching if they don't have access

The only problem is we have to list the private repos somewhere because they aren't sent to one place like the devpool-directory

[rndquu]

Or create a private devpool-directory-private-repositories / devpool-directory-restricted or a similar named GitHub repository which would collect tasks from private repositories and would be accessible only to the core team.

The internal devpool for private repositories could also be integrated with https://work.ubq.fi/ after login by adding a button 'Core team tasks for private repos'. Visible for core team only, would fetch issues from devpool-directory-private-repositories. But I would see this only as a nice to have feature.

That's a good idea.

I assume https://work.ubq.fi/ works this way:

1. If user is not authorized then use some public PAT to fetch issues from https://github.com/ubiquity/devpool-directory
2. Otherwise use the user's github's PAT to fetch from https://github.com/ubiquity/devpool-directory

We could:

1. Fork https://github.com/ubiquity/devpool-directory into https://github.com/ubiquity/devpool-directory-private and set only private repos there
2. Update https://work.ubq.fi/ to fetch issues from https://github.com/ubiquity/devpool-directory and https://github.com/ubiquity/devpool-directory-private (if repo is available for the authorized user)

[0x4007]

Or create a private devpool-directory-private-repositories / devpool-directory-restricted or a similar named GitHub repository which would collect tasks from private repositories and would be accessible only to the core team.
The internal devpool for private repositories could also be integrated with https://work.ubq.fi/ after login by adding a button 'Core team tasks for private repos'. Visible for core team only, would fetch issues from devpool-directory-private-repositories. But I would see this only as a nice to have feature.

That's a good idea.

I assume https://work.ubq.fi/ works this way:

1. If user is not authorized then use some public PAT to fetch issues from https://github.com/ubiquity/devpool-directory
2. Otherwise use the user's github's PAT to fetch from https://github.com/ubiquity/devpool-directory

We could:

1. Fork https://github.com/ubiquity/devpool-directory into https://github.com/ubiquity/devpool-directory-private and set only private repos there
2. Update https://work.ubq.fi/ to fetch issues from https://github.com/ubiquity/devpool-directory and https://github.com/ubiquity/devpool-directory-private (if repo is available for the authorized user)

My concern with this idea is that this approach doesn't work for partner organizations. Perhaps its a premature objective but it would have been preferred to find a solution that we can implement once and can add value for everyone.

I assume https://work.ubq.fi/ works this way:

GitHub allows for 60 public requests per IP address per minute. The UI is adaptive and makes use of this limitation by making requests only to the essential "preview" information from the client. With increased limits, it will go on and fetch all the issue details etc.

[0x4007]

Let's do all the private repos

[devpanther]

@pavlovcik It should be set now.. i refactored fetchAndMergeOptJson

It was overriding the local instead of merging with it

[devpanther]

just 3 private repos: https://github.com/ubiquity/devpool-directory-private/blob/development/opt.json

[0x4007]

@devpanther the behavior of opt.json is not clear to me.

Does this ONLY pay attention to private repos? Otherwise opt.json must redundatly include the values of the public opt.json

Yea, it only pays attention to private repository.. the link you sent is for the public devpool though, the opt.json there shows every repository on ubiquity except the one on the out

This is obviously not true

https://github.com/ubiquity/devpool-directory-private/issues/53

[0x4007]

just 3 private repos: https://github.com/ubiquity/devpool-directory-private/blob/development/opt.json

This should be all of the ubiquity and ubiquibot org. We can selectively opt out later.

[devpanther]

This is obviously not true

@pavlovcik this setup worked.. i think the previous implementation already pulled in those repo and it cannot delete them so it just closes them

[devpanther]

Or can it delete them?

The issues its showing right now are private issues only: https://github.com/ubiquity/devpool-directory-private/issues

This task is closed (for example) because its not part of the privates and it could not delete it: https://github.com/ubiquity/devpool-directory-private/issues/52

[devpanther]

@pavlovcik can you confirm this

[rndquu]

@devpanther I think you can set the out array to be empty since it doesn't have any effect with the current in setup

[devpanther]

@devpanther I think you can set the out array to be empty since it doesn't have any effect with the current in setup

Yes

[devpanther]

I emptied it

[devpanther]

I think https://work.ubq.fi/ shows private now, or is there anything else?

[rndquu]

I think https://work.ubq.fi/ shows private now, or is there anything else?

I can see private issues at https://work.ubq.fi/, works as expected

[0x4007]

[ 1524.3 WXDAI ]

@devpanther

[rndquu]

Reopening this one because https://github.com/ubiquity/devpool-directory-private can't fetch the latest code from https://github.com/ubiquity/devpool-directory

Possible solutions:

• https://gist.github.com/0xjac/85097472043b697ab57ba1b1c7530274
• https://docs.github.com/en/repositories/creating-and-managing-repositories/duplicating-a-repository#mirroring-a-repository-in-another-location

@devpanther pls fix

[devpanther]

Mirroring the repo wasn't part of the original spec, we tried to fork and it failed..

Could've implemented a quick fix without reopening this

[rndquu]

Could've implemented a quick fix without reopening this

It would be really appreciated

[devpanther]

@rndquu it is done

[devpanther]

They can fetch upstream now on private

[rndquu]

They can fetch upstream now on private

I don't understand, what exactly did you do?

[devpanther]

They can fetch upstream now on private

I don't understand, what exactly did you do?

I followed the steps in the link you sent, what else?

It works by adding an upstream so once the main repo is updated, someone needs to pull in the upstream using CMD

[rndquu]

It works by adding an upstream so once the main repo is updated, someone needs to pull in the upstream using CMD

Can't we do it with github UI ?

[0x4007]

It works by adding an upstream so once the main repo is updated, someone needs to pull in the upstream using CMD

Can't we do it with github UI ?

Because this is a private repo we couldn't officially fork the public repo so there isn't a sync button in the GitHub UI

[rndquu]

It works by adding an upstream so once the main repo is updated, someone needs to pull in the upstream using CMD

Can't we do it with github UI ?

Because this is a private repo we couldn't officially fork the public repo so there isn't a sync button in the GitHub UI

But we could:

1. Setup CI to sync files from ubiquity/devpool-directory#development to ubiquity/devpool-directory-private#upstream
2. Apply all necessary changes to ubiquity/devpool-directory-private#development (like updating opt.json)
3. From time to time merge ubiquity/devpool-directory-private#upstream to ubiquity/devpool-directory-private#development via Github UI