You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful to the project if there was a document detailing what features are considered "out of scope" of the Bitcoin Core Wallet. This would make evaluating wallet PRs that add features easier for reviewers. It would also be useful to contributors so that they can get a better sense of which features are more likely to get merged. I'm curious if anybody else thinks that such a document would be useful, and if there are any guidelines that should be added. These guidelines would probably be more directed towards things that are unlikely to get merged, rather than things that we find acceptable.
Some examples of guidelines include the following:
Features shouldn't call any 3rd party APIs
Features shouldn't require any major changes to how the other parts of Bitcoin Core work
The text was updated successfully, but these errors were encountered:
I think both lists are important. Maybe you can kick off that effort?
I can't speak to the core wallet, but with the related GUI project I am helping with, we are trying to create solid design documentation from the start (see here), which may also end up including a good amount of feature specs. We're still early in this, but I do think it's worth the effort to document things well. It gets easier to make decisions, newcomers can more easily understand the goals and status, you avoid repeatedly having the same conversations, etc.
I also believe that both of these are needed and should be described as "what is a good Bitcoin core wallet" rather than limiting it. Perhaps we can start working together by creating a public Google document?
It would be useful to the project if there was a document detailing what features are considered "out of scope" of the Bitcoin Core Wallet. This would make evaluating wallet PRs that add features easier for reviewers. It would also be useful to contributors so that they can get a better sense of which features are more likely to get merged. I'm curious if anybody else thinks that such a document would be useful, and if there are any guidelines that should be added. These guidelines would probably be more directed towards things that are unlikely to get merged, rather than things that we find acceptable.
Some examples of guidelines include the following:
The text was updated successfully, but these errors were encountered: