User talk:Bert Niehaus/Forking

Fork / Import - Cross-product Workflow in a Wiki Environment
Thank you, Dave, you mentioned that import-feature before, but I did not understand that properly. I was trapped by the automated diff-feature for versions of a single document. I think, import defines and allows the diff-comparison between source and destination for a content fork and I understand that forking/branching is not an appropriate term for handling text documents for non-IT perfect. The import feature is perfect, because it allows to track the changes between different pages and sets the proper branching node in underlying version control graph. With that feature the reader can track the changes/alteration at the branching node in the document history between different pages, perfect. The import is done at a specific time stamp and the import feature links to relevant version in the version control of the two different documents.


 * (Application of Curator Status) Ok I want to apply for a curator status. That status makes life easier. Does the curator status is applicable for branching media.
 * (Branching Media/Images/Diagrams): I used an SVG image with german text in it, and I wanted to preserve the look and feel of the diagram and I used the same arrows, colors of the frames, but replaced all the text elements by english and added additional comments in the diagram. This is a classical use-case for branching wiki content. The branching/import feature will be helpful for media as well. because translation of visualization/diagrams and transformations of learning material are necessary to make more comprehensive for target group. At the same time the previous version should be untouched because the media is used in a different context. This is classical use-case for version control applied on branching media.


 * (Cross-product reuse Images/media - Licencing) Does the cross product use of images from Wikipedia to Wikiversity require the same way of license crediting in the text, because the origin(BY citation) is handled by the mediawiki infrastucture and version control of images itself? Would the curator status solve the branching problem for media as well?
 * (fork me on GitHub-approach): I think the fork me on GitHub-approach is hidden in the import function. I must learn resp. get more experience of that branching scenario by creating content by myself with that feature and understand much better the benefits and pitfalls of branching applied on content development! It takes time for me get the requirements and constraints clear in my mind might and I would like to come back to you to discuss a fork me on GitHub-button in Mediawiki. Currently I just have a rough idea, which is too much driven by version control of code. In the wiki environment we deal with content and the fork-idea needs appropriate wordings in the publishing environment that can be understood by non-IT-people as well in different languages. This could be difficult, because the branching concept is in its semantics much richer than "import" but I might be wrong. Use cases of forking are required, when new versions are required and the source remains untouched and has still its own linear version control. In the content domain use-cases of forking are e.g.:
 * (Specialization)Create a specialization of general document that transforms the general document into a description of the special application, that is more comprehensive for a special target group of learners,
 * (Fork as Specialization of parent documents) we can have more than one specializations of the general document for different use-cases,
 * (Version control as transparent approach of a fork) the transformation process into a specialized document/use case of educational content is a longer process for the author from the first time-stamp of forking and a more elaborate version as a first release for the learning resource.
 * (Automated Licensing Support of Forks) To do that properly without violation of BY licensing, I have to do add citations, remove citations, double citations when I split the source text and insert new text. That is tremendous additional workload that MUST be done, looking at it from the licensing angle. The version control could do that for the authors, especially in the early phases of a learning resource, when there is more dynamic in the evolution of a resource. Of course I could do the content development outside the MediaWiki infrastructure, but I think, viewing the content's history is a learning resource for others authors as well ("How did the author transform the learning resource? What was her/his first step?" "Can I fork my ideas from his/her previous forking ideas?") If we perform this forking development outside the wiki and check in the new version when the first release is ready, then we will loose additional forking points for the wiki community. Furthermore branching could be regarded as a natural process of content development, but the workflow of forking has to be bullet-proof from the licensing angle, I agree.
 * (Merge Development Branches of Documents) Different documents could have a common parent node, that might not be obvious when the separate documents were created. An author that recognizes the similarities between those two documents might decide to merge the different development branches into a single document/learning resources, that covers the content of both documents/learning resources in a more comprehensive way. The merge of branches has additional comments showing the common feature of both independently developed learning resources. We cannot expect that the authors of the independently developed documents have the generalized perpective already in their mind, when they create their separate learning resources. Some generializations become obvious, if and only if we can see the finalized version of a learning resource as a wiki community. So merging of document is a natural process of content evolution, which is dependent on the evolution of wisdom and knowledge (here in the use-case of "abstraction").
 * (Bot-Assessment of Fork/Branch Comparison) If branching requires alteration of the source, directly after a fork two branches will show differences, but the branches may only have minor differences. A transformation process of a learning resource into a new context takes time, and therefore a bot should assess forks for significant differences between those branches after a well-defined provided time for implementing changes for the wiki document. If the differences remain just minor after a while then that branch may be suggested for deletion. The quantification of the activities in a branch could also be a helpful approach for a bot approach based on (let's call it) Activity Index for Branches (AIB):
 * $$ AIB=$$(Number of versions in branch per month since fork) $$ \times $$ (Character Count of Changes in branch per month since fork)
 * AIB can be calculated by quantifications provided by the internal version control (history) of the wiki. A threshold implementation could support custodians and curators in triggering interventions. Maybe already implemented!
 * Thank you, Dave, for your ongoing support, clarifications and excuse me for my slow learning curve for the forking/import feature as a wiki-author. Writing this response was also helpful for me to clarify this concept in my mind. Furthermore experience as a curator of the import feature will help me to make a next step improving my skills according to the workflow analysis in the cross-product Wiki environment. Best regards,

--Bert Niehaus (discuss • contribs) 04:42, 13 August 2017 (UTC)


 * Response:
 * For your level of editing and computer skill set, curator status provides additional tools you would find useful.
 * Anything, including files, copied under CC-BY-SA requires crediting the source. Copying a file from Wikipedia copies the comments on the file rather than the media itself.
 * Wiki software was not designed for forking. From the Wikipedia point of view, forking is to be avoided, so they make it difficult. There's Wikipedia:Wikipedia:Copying within Wikipedia and Wikipedia:Wikipedia:Administrators' guide/Fixing cut-and-paste moves, depending on the approach necessary. Keep in mind that these both are written from a Wikipedia point of view.
 * At Wikiversity, we use subpages for the specialization you refer to. It may be easier to think of it in parts and additions rather than redundancy and duplication.
 * Much of the rest of your comments and suggestions need to be discussions rather than Wikiversity discussions. It is possible to propose Wikimedia changes, recommend code, etc. It is also possible (but quite rare) to use Wikiversity as an example and test of that code.
 * Dave Braunschweig (discuss • contribs) 13:55, 13 August 2017 (UTC)

Conclusions of Discussions: Import/Fork

 * Apply for the curator status, DONE --Bert Niehaus (discuss • contribs) 05:21, 14 August 2017 (UTC)
 * Work-in-progress should not be stored in Wikiversity unless everything is Copyright bulletproof. For work in progress set up a MediaWiki on the local machine and perform a private-versioning in the sense of Public-Private-Versioning and check in only the first release from private MediaWiki in Wikiversity version control.
 * According to Wikiversity concept to use subpages for the specialization. I agree with you that it easier to think of it in parts and additions. In computer science we want to avoid redundancy and duplication because creates "headaches" for maintenance of information systems. But we create information systems in way that
 * we can manage/maintain the data with algorithms and
 * users can comprehend/use/alter the information easily

Similarities to Design Principles of relational databases
Even a relational database decomposes a record into parts that avoid redundancy (use primary and secondary keys - relations), but we as humans need the redundancy for the output to be able to read. Speaking in the database example, an INNER JOIN in SQL resolves the DB relation of keys into a table humans can read and comprehend. Transfering this analogy to Wikiversity means: We have a solution to avoid redundancy and duplication but we have no technical support to realize an INNER JOIN for wiki parts. So I have full support for you suggestions to avoid redundancy and create Wikiversity parts that might be reusable by Wikiversity INNER JOIN in the future. There is only one driver for me that lets me forget the Computer Science background and this driver comes from the objective of risk literacy itself. If we could loose comprehensiveness for some users by decomposition into parts. In terms of Risk Literacy we reduce the risk mitigation success of the learning resouces. From a learning perspective e.g. learners get frustated when they have to dig deeper and deeper into the information system until they are able to understand. On this regard redundancy cannot be avoided. So I guess we have to wait until the Wiki Community takes ownership of this concept and sees the benefit. If the community sees that benefit, appropriate IT tools for this will popup anyway when the community wants that. I think a significant fraction of the community of authors must be exposed to the limitations of a mainly linear content development in Wikiversity. Then the community will find an appropriate solution for that to implement an INNER JOIN for a Wiki, that handles BY citations between Wiki products properly Users can decide if the want to read the exploded or the compressed version of the wiki resource. By this underlying INNER JOIN concept (the Wiki community might rename it by a more comprehensive term) we accomplish good IT maintenance in the backend and good usability. If guess if that becomes reality, this needs 5-10 years experience of the community of authors. I am confident the good ideas will make their way and if ideas do not make their way, there is something wrong with the idea and we must refine it or just accept that the community does not want that.
 * from the IT design for information systems and
 * from usability and readibility perspective e.g. by an "explode-link" in a wikiversity document that does not work like a link we all know. It rather works like a INNER JOIN in a database and replaces the reference ("explode-link") to "Normal Distribution" by the definition of the term "Normal Distribution" coming from Wikipedia and the "explode-link"-reference injects the definition into the document dynamically.


 * See Instructional scaffolding and  Progressive disclosure. From my perspective, there is a greater risk of frustration through overwhelming content than there is in appropriately designed progressive disclosure. -- Dave Braunschweig (discuss • contribs) 12:32, 14 August 2017 (UTC)

Wiki Book Creator - synthetic and analytic view
By the way the wiki community of developers had already produced the Wiki Book Creator to synthesize a Wiki product from Wikipedia articles. Wiki INNER JOIN approach the just supports opposite analytic pathway for a "join" of parts of a wiki resources (e.g. a definition). If I read my conclusions again, then it is far away from being comprehensive to authors with a non-IT background. That could be part of a learning resouce for wiki authors about the general principles in information systems without digging into Computer Science Design Principles to much.

Once again thank you, Dave, you are a good guide for me to evolve as a wiki author.

--Bert Niehaus (discuss • contribs) 05:08, 14 August 2017 (UTC)