Proposals/Request for Comment View (rfc.ubq.fi)

[0x4007]

I've opened up a couple of proposals, essentially requests for comment. It could be useful to aggregate them onto a single view for ease-of-access to the DAO. Recent examples:

• Cloudflare as a Risk .github#111
• Ubiquity Credit .github#110

I imagine that we can find issues without pricing and populate them under the "proposals" view.

1. Fork this repository, make rfc.ubq.fi repository
2. Fork devpool-directory repository, make devpool-rfc repository
3. rfc.ubq.fi UI should load from devpool-rfc "backend"

A Note on Forks

It seems that we have use cases for similar UI code but for different purposes. Perhaps it makes sense to fork and create new repos (leaderboard.ubq.fi, rfc.ubq.fi.)

In addition, we already have https://github.com/ubiquity/devpool-directory and https://github.com/ubiquity/devpool-directory-private. Ideally we could consolidate everything into a single aggregator repository, and collect even the github issues without pricing. That way we only need to maintain a single repository (instead of potentially three) for our "backend" of issues.

For now lets just do another fork and then we can worry about consolidating them into a "single backend" in a future project.

[0x4007]

@ubiquity/software-development rfc

[rndquu]

Github discussions serve the same purpose.

Regarding a unified UI, we should create a design system first with typography, colors, UI components, etc...(example)

[0x4007]

Github discussions serve the same purpose.

We tried using these in the past and it seemed that Issues always were able to handle the business need more effectively than Discussions. In addition, it was an extra step to convert to Issues to start the work. The extra barrier adds friction. That's why we basically no longer use Discussions.

Regarding a unified UI, we should create a design system first with typography, colors, UI components, etc...(example)

The closest thing we've got is dao.ubq.fi/branding can add more detail at some point though.

However I was actually referring to the page layout and everything with the list view etc. It seems like it could be useful for all of the applications.

[0x4007]

Alright for now lets just do another fork and then we can worry about consolidating them into a "single backend" in a future project.

[xno-miner]

/wallet 0x5ea33b5133d418f99C510ae8Bbe83f6040b99338

[ubiquibot]

+ Successfully registered wallet address

[xno-miner]

/start

[ubiquibot]

Deadline	Wed, Jun 12, 1:51 PM UTC
Registered Wallet	0x5ea33b5133d418f99C510ae8Bbe83f6040b99338

Tips:

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address.
• 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 task.

[xno-miner]

Seems to be working with a test issue. Now https://github.com/xno-miner/rfc.ubq.fi/ and https://github.com/xno-miner/devpool-rfc need to be forked to ubiquity.

[0x4007]

Please show a test deploy link. It doesn't seem possible if your "backend" has no relevant changes ubiquity/devpool-directory@development...xno-miner:devpool-rfc:development

[xno-miner]

Oh sorry, I didn't understand the issue fully before, I am currently continuing work.

[xno-miner]

I have made the changes that should make the backend work, but I am unable to run the bot locally. Please try it out and check if it works.

[0x4007]

@rndquu would you mind reviewing the "backend" code? As I recall you are the primary author and would likely be the most effective reviewer.

You can find the "backend" changes here ubiquity/devpool-directory@development...xno-miner:devpool-rfc:development

You can find the proposals directory here https://github.com/xno-miner/devpool-rfc/issues?q=is%3Aissue+

---

@xno-miner the inverted logic regarding pricing labels:

// if issue HAS the "Price" label then skip it

Seems to make sense to me so I am inclined to believe that the changes are good

---

Given that the changes are so small, perhaps it makes sense to just handle them in our existing backend? Perhaps you can open a pull to there @xno-miner? I imagine that you can use if else conditionals since the logic seemingly is just the opposite.

[xno-miner]

I have created the pull request, the changes are described in the pull request description.

ubiquity/devpool-directory#1212

[Keyrxng]

I just got pretty confused with these tasks if I'm honest.

The open PR aims to consolidate RFC logic into the current devpool-directory and so does this cover item 1 in Add support for proposals on 'work.ubq.fi': "upgrade backend"?

This spec implies that the work involved with rfc.ubq.fi is a requirement for this task to be completed. Is it expected that this issue won't be complete until the relevant work on the UI is complete too? And if this is true, then is working on work.ubq.fi filtering and an additional view as step 2 required in the larger task?

---

Seems like 'double dipping' as it's been called before but it leaves only repo-sync-solution as step 3 of the larger task.

Should we point the open PR towards a dedicated task in https://github.com/ubiquity/devpool-directory-bounties/issues and we can allow item 2 of the larger task to be worked on via this task?

Also ubiquity/devpool-directory-bounties#25 is a duplicate of item 3 of the larger task as well. Some consolidating of the issues would make things a lot clearer

[0x4007]

I think a separate ui is fine (possible fork of this codebase)

The backend logic must be completed for that new ui to load the right data though.

Please feel free to do as you see fit with the tasks regarding consolidation.