Opt Out & Opt In

[0x4007]

Enable support for both "opting in" and "opting out" model on the repository-level.

• The main issue I was inspired by right now is that I would like to be able to quickly create new repos and issues in old repos under @ubiquity without having to manually add each repo here every time.
• I would like for us to be able to add approved partners, like us (@ubiquity) and automatically import all of their public repositories.

opt.json

{
    "out": [
        "ubiquity/devpool-directory",
        "ubiquity/.github"
    ],
    "in": [
        "alpha-labs-global/blockalizer",
        "uniswap/interface"
    ]
}

• Most partners will use opt.in to opt in specific repositories.
• Special partners, including @Ubiquity will automatically sync all of their issues to the directory, and will be using opt.out to exclude repositories.

---

Notice

• It is implied that we automatically import all of the repositories from the ubiquity organization.
• "ubiquity/" can be parsed within opt.out as an organization name.

[rndquu]

so we should have the ability to:

1. import all repositories from particular organisations (i.e. we should support plain organization names in the projects.json):

   {
   "urls": [
       "https://github.com/Alpha-Labs-Global",
       "https://github.com/ubiquity"
   ]
   }

2. exclude certain repos from issues sync

right?

[0x4007]

import all repositories from particular organisations (i.e. we should support plain organization names in the projects.json):

I think it makes sense to support organization format as this is intended to only work from inside of GitHub.

exclude certain repos from issues sync

Yes and I have a proposal to update the spec below:

Specification Update Proposal

Maybe it makes more sense to have a separate json file for tiers for partners?

sync-organization.json

and

sync-repository.json

For example, we could have some type of privileged partner class (like @ubiquity) which will automatically sync all of their repositories. We would add ourselves and have the opt-outs expressed inside of sync-organization.json. As of now, perhaps it makes sense to only allow ourselves to use this feature (until we onboard some very close partner we work well with.)

For everybody else, perhaps they should specify their repositories they want to opt-in using sync-repository.json?

[rndquu]

Perhaps we could have a single json like:

{
  "organizations": [
    "https://github.com/ubiquity/"
  ],
  "repositories": [
    "https://github.com/ubiquity/ubiquity-dollar"
  ],
  "repositories_exclude": [
    "https://github.com/ubiquity/devpool-directory"
  ]
}

Where:

• organizations: list of all organizations where all repos should be synced
• repositories: list of single repositories which should be synced
• repositories_exclude: list of single repositories to exclude from sync

[0x4007]

I still think that we should support non URL syntax because it's more concise and equally as expressive.

I also think that my proposal will yield more concise and equally expressive syntax.

Example:

sync-organization.jsonc

// {
//     "organization-to-automatically-sync": [
//         "excluded-repository-1",
//         "excluded-repository-2",
//         "excluded-repository-3"
//     ]
// }

{
    "ubiquity": ["devpool-directory"]
}

sync-repository.jsonc

// organization/repository
[
    "alphalabsglobal/blockalizer"
]

Because most people will be modifying sync-repository.jsonc I think that a quick look at the syntax will make it clear how they can add their repository.

We could even make CI to parse this file on pull requests and check if those repositories exist.

---

We might even be able to add a .txt file and just parse each line as a new entry due to how concise this syntax is, making it ultra easy to add repositories.

[harjaapdhillon16]

@pavlovcik @rndquu Is the spec finalised for this ? I wanna start working on this !

[0x4007]

@harjaapdhillon16 almost finalized give us a few more days please! 🙏

[rndquu]

I still think that we should support non URL syntax because it's more concise and equally as expressive.

I also think that my proposal will yield more concise and equally expressive syntax.

Example:

sync-organization.jsonc

// {
//     "organization-to-automatically-sync": [
//         "excluded-repository-1",
//         "excluded-repository-2",
//         "excluded-repository-3"
//     ]
// }

{
  "ubiquity": ["devpool-directory"]
}

sync-repository.jsonc

// organization/repository
[
    "alphalabsglobal/blockalizer"
]

Because most people will be modifying sync-repository.jsonc I think that a quick look at the syntax will make it clear how they can add their repository.

We could even make CI to parse this file on pull requests and check if those repositories exist.

We might even be able to add a .txt file and just parse each line as a new entry due to how concise this syntax is, making it ultra easy to add repositories.

it is not clear that devpool-directory is excluded in sync-organization.json in this example:

{
    "ubiquity": ["devpool-directory"]
}

let's use:

{
    "ubiquity": {
            "exclude": [
                "devpool-directory"
            ]
        }
}

The example for sync-repository.json is fine

[0x4007]

it is not clear that devpool-directory is excluded in sync-organization.json in this example: let's use:

I value the expressiveness, but with that additional layer of the object, I feel like the original specification might be better. Perhaps it is not so expressive that the organization is automatically added for opt.out but I imagine that we (@ubiquity) are the only ones who will be using it for awhile.

What do you think about the original specification?

[rndquu]

it is not clear that devpool-directory is excluded in sync-organization.json in this example: let's use:

I value the expressiveness, but with that additional layer of the object, I feel like the original specification might be better. Perhaps it is not so expressive that the organization is automatically added for opt.out but I imagine that we (@ubiquity) are the only ones who will be using it for awhile.

What do you think about the original specification?

The original spec is fine, everything in a single file

[0x4007]

@harjaapdhillon16 its ready check the original comment for the specification. Thank you.

[harjaapdhillon16]

Gonna start it this weekend @pavlovcik

[gitcoindev]

/start

[ubiquibot[bot]]

Deadline	Thu, 09 Nov 2023 17:36:46 UTC
Registered Wallet	0x7e92476D69Ff1377a8b45176b1829C4A5566653a

Tips:

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address @user.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the bounty.

[gitcoindev]

I will finish QA for edge cases and try to open a pull request today.

[gitcoindev]

I opened a pull request and did QA of the following edge cases:

https://github.com/ubiquity/devpool-directory/commit/9536a7ede0aa1427dfc1ff9921883b62ba871091 https://github.com/ubiquity/devpool-directory/commit/9a710d6430c5c5342ffb1db92a627d125b457239 https://github.com/ubiquity/devpool-directory/commit/14aa96aa8db07a667c83988156b446e6ce607ce3 https://github.com/ubiquity/devpool-directory/commit/cf39440e5ecf25d1927f6974d533e755134f2b75 https://github.com/ubiquity/devpool-directory/commit/c2d851c89fa1ae85a7c49973415db06f4f154480 https://github.com/ubiquity/devpool-directory/commit/8c21270cf44e4a7df346f4b1dfd452dd7388e527 https://github.com/ubiquity/devpool-directory/commit/fe8ee7acc8c1c1b46f3a188ea761f93a40f306a0

with GitHub action runs:

https://github.com/korrrba/devpool-directory/actions/runs/6802055953 https://github.com/korrrba/devpool-directory/actions/runs/6802121606 https://github.com/korrrba/devpool-directory/actions/runs/6802244616 https://github.com/korrrba/devpool-directory/actions/runs/6802324668 https://github.com/korrrba/devpool-directory/actions/runs/6802368832 https://github.com/korrrba/devpool-directory/actions/runs/6802446925 https://github.com/korrrba/devpool-directory/actions/runs/6802578286

The implementation is minimal and according to the spec. A note on implementation: at first a list of repository urls available in projects.json is collected into a set. Then opt.in is collected and tool automatically recognizes if to opt in a single repository in owner/repo format or whether to import all repositories when an org is provided. Finally, opt.out deletes single repository or all repositories from an org from the list of repositories to process.

A few usage examples:

• opt in two repositories alpha-labs-global/blockalizer and uniswap/interface

{
    "out": [
    ],
    "in": [
        "alpha-labs-global/blockalizer",
        "uniswap/interface"
    ]
}

• opt in one repository alpha-labs-global/blockalizer and all repositories from korrrba org

  {
  "out": [
  ],
  "in": [
      "alpha-labs-global/blockalizer",
      "korrrba"
  ]
  }

• opt out ubiquity/devpool-directory repostiory

  {
  "out": [
      "ubiquity/devpool-directory",
  ],
  "in": [
  ]
  }

• opt in all repositories from korrrba org, but opt out korrrba/devpool-directory repository

  {
  "out": [
      "korrrba/devpool-directory",
  ],
  "in": [
      "korrrba"
  ]
  }

• leaving opt in and opt out empty will not change anything, only urls from projects.json will be used

  {
  "out": [
  ],
  "in": [
  ]
  }

fyi @pavlovcik @rndquu

[0x4007]

opt out ubiquity/devpool-directory repostiory

Can you describe what exact behavior it has in this scenario?

[gitcoindev]

opt out ubiquity/devpool-directory repostiory

Can you describe what exact behavior it has in this scenario?

Sure. Normally projects.json on purpose does not contain 'https://github.com/ubiquity/devpool-directory', and if we opt out ubiquity/devpool-directory nothing will happen. The repository will not be processed.

But there are two other situations to consider. One is when somebody would add https://github.com/ubiquity/devpool-directory to projects.json or the whole ubiquity org to opt.in in opt.json. In this scenario ubiquity/devpool-directory will be excluded, or opted out from processing. I can add a few logs and simulate those scenarios if you would like to see the logs as well.

[0x4007]

opt out ubiquity/devpool-directory repostiory

Can you describe what exact behavior it has in this scenario?

Sure. Normally projects.json on purpose does not contain 'https://github.com/ubiquity/devpool-directory', and if we opt out ubiquity/devpool-directory nothing will happen. The repository will not be processed.

But there are two other situations to consider. One is when somebody would add https://github.com/ubiquity/devpool-directory to projects.json or the whole ubiquity org to opt.in in opt.json. In this scenario ubiquity/devpool-directory will be excluded, or opted out from processing. I can add a few logs and simulate those scenarios if you would like to see the logs as well.

The original specification states that opt.out should serve as a blacklist. This means that all repositories under Ubiquity would be synchronized except for what is listed in opt.out

• Special partners, including @Ubiquity will automatically sync all of their issues to the directory, and will be using opt.out to exclude repositories.

Are you suggesting that it is more expressive to do:

{
    "out": [
        "ubiquity/devpool-directory",
    ],
    "in": [
        "ubiquity"
    ]
}

[gitcoindev]

The original specification states that opt.out should serve as a blacklist. This means that all repositories under Ubiquity would be synchronized except for what is listed in opt.out

• Special partners, including @ubiquity will automatically sync all of their issues to the directory, and will be using opt.out to exclude repositories.

Are you suggesting that it is more expressive to do:

{
    "out": [
        "ubiquity/devpool-directory",
    ],
    "in": [
        "ubiquity"
    ]
}

Hi @pavlovcik I thought about it for a while and yes, it looks more expressive and would keep information in one place. But I am fine if you insist on hard-coding ubiquity organization into opt.in and can implement it this way as it was part of the original specification. Please let me know, in this case I will update the pull request and re-test all scenarios.

[gitcoindev]

Hi @pavlovcik I would be grateful if you let me know the decision on this issue, we can merge or I will rework and retest.

[0x4007]

Thanks for the follow up. I've been fixing my sleep schedule this week and have been very fatigued.

insist on hard-coding ubiquity organization into opt.in

This is not what I meant. I meant that it should be implied from "ubiquity" as the prefix of "ubiquity/devpool-directory".

However I think that optimizing for expressiveness is probably the correct answer.

[ubiquibot[bot]]

Task Assignee Reward

[ CLAIM 200 WXDAI ]

0x7e92476D...A5566653a

If you've enjoyed your experience in the DevPool, we'd appreciate your support. Follow Ubiquity on GitHub and star this repo. Your endorsement means the world to us and helps us grow!

We are excited to announce that the DevPool and UbiquiBot are now available to partners! Our ideal collaborators are globally distributed crypto-native organizations, who actively work on open source on GitHub, and excel in research & development. If you can introduce us to the repository maintainers in these types of companies, we have a special bonus in store for you!

[ubiquibot[bot]]

Task Creator Reward

pavlovcik: [ CLAIM 87.3 WXDAI ]