Skip to content
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

[LIP-14] Migrate Lens LIPs from Github to CharmVerse #37

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

alexpoon
Copy link

When opening a pull request to submit a new LIP, please use the suggested template: https://github.com/ethereum/LIPs/blob/main/lip-template.md

Copy link

height bot commented Feb 22, 2024

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

@alexpoon alexpoon changed the title Migrate Lens LIPs from Github to CharmVerse [LIP-14] Migrate Lens LIPs from Github to CharmVerse Feb 22, 2024
@benalistair
Copy link

Anything that is more user-friendly is worth a try, in my opinion. GitHub is too technical for general community discussions, and I think a smoother UI that is easier to navigate would bring more conversation.

@punkess
Copy link

punkess commented Feb 24, 2024

I totally agree, github is not ideal for LIPs. I would like to see LIPs natively on lens though (instead of going to another third party tool).
“As Lens Protocol is a neutral and flexible technology stack for social networking use-cases, LIPs provides the basis to ensure that Lens Protocol remains flexible and uniform across all potential use-cases, improvements and ideas within the community.” … and therefore the home for LIPs should be @lens/lens.
advantages:
(1) accessibility: literally every lens user can join discussions and add ideas without any barrier of entry. (Status quo: setup of a GitHub/Charmverse profile, getting used to the app and the (technical) workflow coming with the process currently implemented).
(2) visibility: based on the amount of comments and the profiles participating in the discussions so far, LIPs will get an amazing visibility in the broader lens community.

to be improved: LIPs won’t be easily accessible as soon as they are in the lower end of the feed.
workaround: use of the #LIP hashtag eg #LIP14.
solution(s): #LIP15 ;-) full content search on lens.

@alexpoon
Copy link
Author

alexpoon commented Feb 24, 2024 via email

@iPaulPro
Copy link

iPaulPro commented Feb 25, 2024

I love the idea of having a place dedicated to user feedback, but I believe we should have a clear distinction between protocol proposals and community discussions. I worry that trying to make LIPs more user-friendly is going to make it much harder to propose actual technical changes to the protocol. I'd argue that there should be some technical hurdle involved in being part of technical discussions, to help cut down on the noise. Github is where the code is, and keeping it on GitHub aligns with the rest of the ecosystem while allowing for easy tracking; from proposal to shipped.

To be fair, Github really isn't all that confusing or difficult to use. Creating and commenting on issues is far more social than it is technical. We already have a lot of low-value comments on LIPs (even on GitHub) -- I don't think we should be looking for ways to increase that.

In short, I believe LIPs should primarily be for developers, heavily moderated to be technical and specific, and something new should be created for user proposals/discussions.

@defispartan
Copy link

I definitely support the goal of increasing involvement in the LIPs. However, I think GitHub should remain the primary platform, and discussions from GitHub should be integrated instead of migrated.

GitHub is where the Lens Protocol codebase and most community applications are committed and tracked: smart contracts, metadata, specifications, open source applications. The EIP process and Git history of important proposals such as EIP-4844 are an example of how a spec can evolve over time and benefit from having history persisted in a way that can be modified, referenced, reverted, etc.

Currently, it is possible but difficult for apps to integrate GitHub comments into an existing social feed / forum. A potential solution is to create a bot to cross-post comments between GitHub and Lens with a unique publication tag (see #33 ). This would allow any frontend application (such as CharmVerse) to directly participate in LIP conversations by indexing and publishing content to a Lens community.

@jb0gie
Copy link

jb0gie commented Apr 9, 2024

BIG 🧠 IDEA 💡

using charmverse is a wonderful idea❗

here's why :

  • slow learning curve
  • rich UX
  • cool ass team
  • mainly and simply vibes

@punkess
Copy link

punkess commented Apr 9, 2024

I love the idea of having a place dedicated to user feedback, but I believe we should have a clear distinction between protocol proposals and community discussions. I worry that trying to make LIPs more user-friendly is going to make it much harder to propose actual technical changes to the protocol. I'd argue that there should be some technical hurdle involved in being part of technical discussions, to help cut down on the noise. Github is where the code is, and keeping it on GitHub aligns with the rest of the ecosystem while allowing for easy tracking; from proposal to shipped.

To be fair, Github really isn't all that confusing or difficult to use. Creating and commenting on issues is far more social than it is technical. We already have a lot of low-value comments on LIPs (even on GitHub) -- I don't think we should be looking for ways to increase that.

In short, I believe LIPs should primarily be for developers, heavily moderated to be technical and specific, and something new should be created for user proposals/discussions.

Maybe we need two processes:
(1) what makes sense to improve lens from a "user/business requirements" (non-technical) point of view and
(2) technical discussion (related to 1 as well as independent of 1)
I don't see why github is the best place for (1).
I totally get why github is the best place for (2).

Of course 1 needs some moderation and discussion before LIPs from 1 are handed over to 2. (maybe a similar approach to "signaling proposals" in the cosmos world might work).

cc @defispartan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants