Fossil SCM
Expanded the discussion on user learning time vs arcance feature set size in fossil-v-git.wiki, within section 2.5.3 "Accepting Contributions".
Commit
1b479aff38068197c8a226611ede026072b4c63c590efee5b6bcf76164299964
Parent
466d74c80797d28…
1 file changed
+36
-13
+36
-13
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -441,32 +441,55 @@ | ||
| 441 | 441 | how we react to |
| 442 | 442 | [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by |
| 443 | 443 | contributions]. In brief, it's harder to get a new feature into Fossil |
| 444 | 444 | than into Git. |
| 445 | 445 | |
| 446 | -A larger feature set size is not necessarily a good thing. Git's command line | |
| 446 | +A larger feature set is not necessarily a good thing. Git's command line | |
| 447 | 447 | interface is famously arcane. Masters of the arcane are able to do |
| 448 | 448 | wizardly things, but only by studying their art deeply for years. This |
| 449 | 449 | strikes us as a good thing only in cases where use of the tool itself is |
| 450 | 450 | the primary point of that user's work. |
| 451 | 451 | |
| 452 | -Most DVCS users are not using a DVCS for its own sake, so we do not want | |
| 453 | -the DVCS with the most features, we want the one with a more easily | |
| 454 | -internalized behavior set, which we can pick up, use quickly, and then | |
| 455 | -set aside in order to get back to our | |
| 456 | -actual job as quickly as possible. There is some minimal set of features | |
| 457 | -required to achieve that, but there is a level beyond which more | |
| 458 | -features only slow us down while we're learning about the DVCS, as we | |
| 452 | +Almost no one uses a DVCS for its own sake; very few people get paid | |
| 453 | +specifically in order to drive a DVCS. We use DVCSes as a tool to | |
| 454 | +support some other effort, so we do not necessarily want the DVCS with | |
| 455 | +the most features. We want a DVCS with easily internalized behavior so | |
| 456 | +we can thoroughly master it despite spending only a small fraction of | |
| 457 | +our working time thinking about the DVCS. We want to pick the tool up, | |
| 458 | +use it quickly, and then set it aside in order to get back to our actual | |
| 459 | +job as quickly as possible. | |
| 460 | + | |
| 461 | +Professional software developers in particular are prone to focusing on | |
| 462 | +feature set sizes when choosing tools because this is sometimes a highly | |
| 463 | +important consideration. They spend all day, every day, in their | |
| 464 | +favorite text editors, and time they spend learning all of the arcana of | |
| 465 | +their favorite programming languages is well-spent. Skills with these | |
| 466 | +tools are direct productivity drivers, which in turn directly drives how | |
| 467 | +much money a developer can make. (Or how much idle time they can afford | |
| 468 | +to take, which amounts to the same thing.) But if you are a professional | |
| 469 | +software developer, we want you to ask yourself a question: "How do I | |
| 470 | +get paid more by mastering arcane features of my DVCS?" Unless you have | |
| 471 | +a good answer to that, you probably do not want to be choosing a DVCS | |
| 472 | +based on how many arcane features it has. | |
| 473 | + | |
| 474 | +The argument is similar for other types of users: if you are a hobbyist, | |
| 475 | +how much time do you want to spend mastering your DVCSs instead of on | |
| 476 | +the hobby supported by use of that DVCS? | |
| 477 | + | |
| 478 | +There is some minimal set of features required to achieve the purposes | |
| 479 | +that drive our selection of a DVCS, but there is a level beyond which | |
| 480 | +more features only slow us down while we're learning the tool, since we | |
| 459 | 481 | must plow through documentation on features we're not likely to ever |
| 460 | -use. When the number of features grows | |
| 461 | -to the point where people of normal motivation cannot spend the time to | |
| 462 | -master them all, you make the tool <i>less</i> productive to use. | |
| 482 | +use. When the number of features grows to the point where people of | |
| 483 | +normal motivation cannot spend the time to master them all, the tool | |
| 484 | +becomes <i>less</i> productive to use. | |
| 463 | 485 | |
| 464 | -We achieve this balance between feature set size and ease of use by | |
| 486 | +The core developers of the Fossil project achieve a balance between feature | |
| 487 | +set size and ease of use by | |
| 465 | 488 | carefully choosing which users to give commit bits to, then in being |
| 466 | 489 | choosy about which of the contributed feature branches to merge down to |
| 467 | -trunk. | |
| 490 | +trunk. We say "no" to a lot of feature proposals. | |
| 468 | 491 | |
| 469 | 492 | The end result is that Fossil more closely adheres to |
| 470 | 493 | [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the |
| 471 | 494 | principle of least astonishment] than Git does. |
| 472 | 495 | |
| 473 | 496 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -441,32 +441,55 @@ | |
| 441 | how we react to |
| 442 | [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by |
| 443 | contributions]. In brief, it's harder to get a new feature into Fossil |
| 444 | than into Git. |
| 445 | |
| 446 | A larger feature set size is not necessarily a good thing. Git's command line |
| 447 | interface is famously arcane. Masters of the arcane are able to do |
| 448 | wizardly things, but only by studying their art deeply for years. This |
| 449 | strikes us as a good thing only in cases where use of the tool itself is |
| 450 | the primary point of that user's work. |
| 451 | |
| 452 | Most DVCS users are not using a DVCS for its own sake, so we do not want |
| 453 | the DVCS with the most features, we want the one with a more easily |
| 454 | internalized behavior set, which we can pick up, use quickly, and then |
| 455 | set aside in order to get back to our |
| 456 | actual job as quickly as possible. There is some minimal set of features |
| 457 | required to achieve that, but there is a level beyond which more |
| 458 | features only slow us down while we're learning about the DVCS, as we |
| 459 | must plow through documentation on features we're not likely to ever |
| 460 | use. When the number of features grows |
| 461 | to the point where people of normal motivation cannot spend the time to |
| 462 | master them all, you make the tool <i>less</i> productive to use. |
| 463 | |
| 464 | We achieve this balance between feature set size and ease of use by |
| 465 | carefully choosing which users to give commit bits to, then in being |
| 466 | choosy about which of the contributed feature branches to merge down to |
| 467 | trunk. |
| 468 | |
| 469 | The end result is that Fossil more closely adheres to |
| 470 | [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the |
| 471 | principle of least astonishment] than Git does. |
| 472 | |
| 473 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -441,32 +441,55 @@ | |
| 441 | how we react to |
| 442 | [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by |
| 443 | contributions]. In brief, it's harder to get a new feature into Fossil |
| 444 | than into Git. |
| 445 | |
| 446 | A larger feature set is not necessarily a good thing. Git's command line |
| 447 | interface is famously arcane. Masters of the arcane are able to do |
| 448 | wizardly things, but only by studying their art deeply for years. This |
| 449 | strikes us as a good thing only in cases where use of the tool itself is |
| 450 | the primary point of that user's work. |
| 451 | |
| 452 | Almost no one uses a DVCS for its own sake; very few people get paid |
| 453 | specifically in order to drive a DVCS. We use DVCSes as a tool to |
| 454 | support some other effort, so we do not necessarily want the DVCS with |
| 455 | the most features. We want a DVCS with easily internalized behavior so |
| 456 | we can thoroughly master it despite spending only a small fraction of |
| 457 | our working time thinking about the DVCS. We want to pick the tool up, |
| 458 | use it quickly, and then set it aside in order to get back to our actual |
| 459 | job as quickly as possible. |
| 460 | |
| 461 | Professional software developers in particular are prone to focusing on |
| 462 | feature set sizes when choosing tools because this is sometimes a highly |
| 463 | important consideration. They spend all day, every day, in their |
| 464 | favorite text editors, and time they spend learning all of the arcana of |
| 465 | their favorite programming languages is well-spent. Skills with these |
| 466 | tools are direct productivity drivers, which in turn directly drives how |
| 467 | much money a developer can make. (Or how much idle time they can afford |
| 468 | to take, which amounts to the same thing.) But if you are a professional |
| 469 | software developer, we want you to ask yourself a question: "How do I |
| 470 | get paid more by mastering arcane features of my DVCS?" Unless you have |
| 471 | a good answer to that, you probably do not want to be choosing a DVCS |
| 472 | based on how many arcane features it has. |
| 473 | |
| 474 | The argument is similar for other types of users: if you are a hobbyist, |
| 475 | how much time do you want to spend mastering your DVCSs instead of on |
| 476 | the hobby supported by use of that DVCS? |
| 477 | |
| 478 | There is some minimal set of features required to achieve the purposes |
| 479 | that drive our selection of a DVCS, but there is a level beyond which |
| 480 | more features only slow us down while we're learning the tool, since we |
| 481 | must plow through documentation on features we're not likely to ever |
| 482 | use. When the number of features grows to the point where people of |
| 483 | normal motivation cannot spend the time to master them all, the tool |
| 484 | becomes <i>less</i> productive to use. |
| 485 | |
| 486 | The core developers of the Fossil project achieve a balance between feature |
| 487 | set size and ease of use by |
| 488 | carefully choosing which users to give commit bits to, then in being |
| 489 | choosy about which of the contributed feature branches to merge down to |
| 490 | trunk. We say "no" to a lot of feature proposals. |
| 491 | |
| 492 | The end result is that Fossil more closely adheres to |
| 493 | [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the |
| 494 | principle of least astonishment] than Git does. |
| 495 | |
| 496 |