Hello All, I'm sorry if this seems like a trivial question, but none-the-less I have not been able to find a concise answer. There might be none..?
When people external to development groups need to be involved in development process, for example because of their scientific domain's particular usage of terminology, I often observe clashes between "views of how the world works". Ignorant but hopeful as I am, I wondered whether fossil's with its UI-friendly capabilities could support the process of developing documentation BEFORE any coding actually is done. The reason for this ISO-9000 approach is that I have to align understanding between 3 parties. Let's call them "developers", "scientists" and "portfolio-manager". *They have to:* 1. Make an official sign-off of the documentation co-authored by the "coders" and the "scientists" and the "portfolio-managers", unfortunately they do not necessarily understand each others domains. So, in this structure: + Managers and Scientists are in dialogue about contextual relevance and pursued functionality (very holistic and broad). + Scientists and Developers are in dialogue about pursued functionality and written code (very detailed and specific). + Developers and Managers are in dialogue how time (cost) is spend. 2. The documentation must be readable by the "developers" and "scientists" for check of the developers scientific understanding (risk of logical errors). 3. The documentation must be readable by the "portfolio-managers" who do not have the in-depth knowledge the scientist has, but needs to communicate what is being done, why time is spent on it and how each particular element is supporting the scientific program (to the management board). 4. In the specification process the "portfolio-managers" are given "docbook" chapters and asked to review these to check their understanding and get the board to sign off the investment based on their "defense" of the described features. 5. The developers can read the scientist-users usage of "words" and "definition" and use these in the development process, so that the scientists will find the API-familiar by concept; and if necessary the developers can challenge the scientists if the developers believe the scientists usage of the definitions are inappropriate. 6. The documentation is used by the client to describe and develop test & validation cases in the same priority as the developers have to work on them. 7. The documentation is used as a project checklist to main mutual understanding of the progress. Now if ANY PAIR in this triangle fails, they all fail. But if they all use the same version-controlled documentation at three levels of detail (code vs. domain-scientific vs. common English), then each should be able to identify inconsistencies and prevent misunderstanding, which finally should accelerate learning and prevent waste of resources. However, in comparison to the "default" usage of fossil-scm, there are three users with overlapping similar needs, though different perspective. >From what I see, fossil could be used if I could get a "narrative" (webmail-type) log-in for the portfolio-managers and scientists, that supports something like mathjax, plots and images. Ipython's new notebook gives a nice presentation layer, but it is missing the neat & clean fossil-scm implementation, and doesn't support the 12 languages my development teams have to respond to. Following Fossil for 1.5 years I think we are close, but feel unqualified to answer whether we are close enough to crack this generic nut of collaboration. What do you think? Kind Regards, -- Bjorn Madsen *Researcher Complex Systems Research* Ph.: (+44) 0 7792 030 720 [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
