📅 Original date posted:2017-07-11
📝 Original message:On Wed, Jul 12, 2017 at 6:11 AM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
> and release process once the basic technology is done; because it's
> only past that point that guarantees can really start being made.
Bitcoin development differs from Linux kernel development in a number
of obvious ways, such as the fact Bitcoin is being "patched in
flight". The current political situation over Bitcoin development is
also quite different, with scalability being a major concern for a lot
of users, and conflicting views leading to risky technical gambles.
Having *something* like a roadmap that gives the average user some
insights into what exactly is being planned for Bitcoin is very
desirable, arguably even necessary, in particular for the scaling
solutions. Putting deadlines and dates in would of course be highly
irresponsible, as no one can predict how much of their free time
volunteer developers will put into the project in advance (or whether
they will stick around for the next X months or stop being
contributors).
I think there is necessity for a document that describes the project
intentions for scaling solutions, but I don't think adding dates and
deadlines is appropriate. That may or may not be a roadmap. I imagine
such a document would be updated regularly as appropriate, which means
it may be less of a roadmap than the traditional kind.
Karl Johan Alm [ARCHIVE] /
npub1e7…fg307
2023-06-07 18:04:22
in reply to nevent1q…vfyx
Author Public Key
npub1e7vdq905zr4xjr5nxuz58l9jcvffxq728ysl6m2xxgr024mjy5vq4fg307Published at
2023-06-07 18:04:22Event JSON
{
"id": "7ca77bb3628f15322c909727615ce4db97aa2ffa3cd485b829b8a9c3163500f6",
"pubkey": "cf98d015f410ea690e93370543fcb2c3129303ca3921fd6d463206f557722518",
"created_at": 1686161062,
"kind": 1,
"tags": [
[
"e",
"0dbbb3b4fffe9287047e58a8fa04c4b6c95589f2269ea5553f7cb2691feb3b03",
"",
"root"
],
[
"e",
"c0cf992560947f4022fa205ac2c42c8b2de0b8bc18e82ded5e7e2df57f3de830",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2017-07-11\n📝 Original message:On Wed, Jul 12, 2017 at 6:11 AM, Gregory Maxwell via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e IMO the way to do \"roadmaps\" in Bitcoin is to roadmap the finalization\n\u003e and release process once the basic technology is done; because it's\n\u003e only past that point that guarantees can really start being made.\n\nBitcoin development differs from Linux kernel development in a number\nof obvious ways, such as the fact Bitcoin is being \"patched in\nflight\". The current political situation over Bitcoin development is\nalso quite different, with scalability being a major concern for a lot\nof users, and conflicting views leading to risky technical gambles.\n\nHaving *something* like a roadmap that gives the average user some\ninsights into what exactly is being planned for Bitcoin is very\ndesirable, arguably even necessary, in particular for the scaling\nsolutions. Putting deadlines and dates in would of course be highly\nirresponsible, as no one can predict how much of their free time\nvolunteer developers will put into the project in advance (or whether\nthey will stick around for the next X months or stop being\ncontributors).\n\nI think there is necessity for a document that describes the project\nintentions for scaling solutions, but I don't think adding dates and\ndeadlines is appropriate. That may or may not be a roadmap. I imagine\nsuch a document would be updated regularly as appropriate, which means\nit may be less of a roadmap than the traditional kind.",
"sig": "917813b5c3accb5fbda9ef53c8a959fd6a3775cd4800cc85070e780bfbaea95697b3028a771b5fbed5c6eed111df6ef7454611d6cf2cced804d5d17fb3432b5f"
}