-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Internal Task Listing #2
Comments
rfc @ubiquity/software-development |
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:
If we "generalize" issue descriptions at https://github.com/ubiquity/card-issuance we can simply make the whole repo public. |
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.)
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. |
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 |
You think its best to manually check the private repositories on GitHub for new, high priority tasks? |
perhaps a subdomain does it! core.work.ubq.fi |
Okay so you're suggesting an entirely new approach from the UI where the flow is:
This makes sense but unfortunately seems work intensive (it sort of makes the existing logic, and the existing devpool-directory issues redundant.) |
Crypto Top-Up Card + Ubiquity (Dollar) Staking Shares Enable + Github issues to be tackled in proportional + Super Pull request reviewing 🤑 let it come |
Or create a private 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. |
This approach is interesting because it's basically forking the "backend" which means it should be quick to set up!
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. |
Is it core-team only issue? @pavlovcik |
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? |
@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? |
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 The only problem is we have to list the private repos somewhere because they aren't sent to one place like the |
That's a good idea. I assume https://work.ubq.fi/ works this way:
We could:
|
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.
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. |
@pavlovcik this setup worked.. i think the previous implementation already pulled in those repo and it cannot delete them so it just closes them |
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 |
@pavlovcik can you confirm this |
@devpanther I think you can set the out array to be empty since it doesn't have any effect with the current |
Yes |
I emptied it |
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 |
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:
@devpanther pls fix |
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 |
It would be really appreciated |
@rndquu it is done |
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 |
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:
|
+ Evaluating results. Please wait... |
Objective
List private tasks for organization collaborators.
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) ubiquity/card-issuance#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
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.
The text was updated successfully, but these errors were encountered: