![]() I’d for sure document most of my projects this way, and I know others that’d do too, so it might even be a way to get free advertisement and expand your user-base. ![]() ![]() I could even envision hybrid repositories, when pushed to gitlab it’s just a regular old repository with a npm library, but when pushed to observable it becomes this beautiful living documentation. I’d certainly help my workflow if I could simply pull the entire notebook, work on it in the train via vim, and then when I’m home, push the entire thing back. It’s familiar to most people, and allows for the straightforward resolution of even the most complex operations, like merging, splitting and rebasing notebooks. I understand that you want to make the interface simple enough to use even without an extensive software development background, but it would be really useful to have both a simple abstracted interface for the common user, as well as a git endpoint for experienced devs.Įven though it might be technically more challenging, I believe that the rewards would be well worth it. If you want to hear my dream solution, I’d be simply git. Thanks for your clarifications and thoughtsįor my use-case, simply being able to hide the fork relationship would be completely sufficient. If you have thoughts on what would work well for you, we’d love input! For example, we might allow hiding the fork relationship (for when the notebooks are unrelated) and grouping forks into “branches” (for when forks by the same author are closely related). The fork indicator would be more valuable as a meaningful signal, so we’re considering ways for authors to better express relationships between notebooks. It’s merely a historical artifact, if you will. Thus the fork indicator does not imply content equivalence or similarity only that at some point, the current notebook originated from the parent. ![]() On the original topic, we know there are many different reasons why people fork sometimes a fork is closely related to its parent while other times it diverges and becomes wholly unrelated. When you delete your notebook, you’re deleting only your own notebook, not copies other users may have made. The license grant to other users in the terms of service simply means that by publishing, you’re allowing other users to make copies of your published content, say by forking or importing. Yes, there’s nothing preventing you from deleting your notebook whenever you like. There’s definitely laws in Germany that allow an author to change their mind and redact their work.Įven GDPR alone should completely safeguard you from this. This stuff is specific and limited enough that I don’t see it extend to the point that they can still keep it published after you’ve changed your mind about releasing it. To the extent this agreement is not enforceable by applicable law, you grant Observable the rights we need to use Your Content without attribution and to make reasonable adaptations of Your Content as necessary to render the Website and provide the Service. When you publish a notebook, you grant each User of Observable a nonexclusive, worldwide license to use, display, and perform Your Content through the Observable Service and to reproduce Your Content solely on Observable as permitted through Observable’s functionality (for example, through forking). This license does not grant Observable the right to sell Your Content or otherwise distribute or use it outside of our provision of the Service. We need these rights for both public and private notebooks because these rights are necessary for providing the Service.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |