fixed post

posts/2023-07-20_cross_company_dev/cross_industry_dev.qmd

@@ -40,9 +40,9 @@ As the industry moves toward new (to them) programming languages, fit-for-purpos
 The realization that siloed solutions -- in an area where competitiveness does not benefit patients -- are simply resource hungry ways to solve the same problem in parallel provided a great argument for a shift toward collaborations. 
 
 Such cross-industry collaborations gave rise to the pharmaverse, an opinionated collection of R packages designed to solve clinical reporting in R.
-[{admiral}](https://github.com/pharmaverse/admiral), the project that I work on, is part of the pharmaverse and covers the creation of ADaM data sets (CDISC standard data).
+[{admiral}](https://github.com/pharmaverse/admiral), the project that I work on, is part of the [pharmaverse](https://pharmaverse.github.io/admiraldev/devel/index.html) and covers the creation of ADaM data sets (CDISC standard data).
 These data sets are subsequently used to produce tables, listings, and graphs and are usually part of the submission package for regulators.  
-You can read about the inception of {admiral} in [this recent blog post by ...]().
+<!-- You can read about the inception of [{admiral}](https://github.com/pharmaverse/admiral) in [this recent blog post by ...](). -->
 
 
 
@@ -51,31 +51,31 @@ You can read about the inception of {admiral} in [this recent blog post by ...](
 When creating an open source package in an industry where currently there is a lot of traction you have to move fast. 
 No, I don't mean: Move fast and break things. 
 I mean: Communicate! Get people on board! 
-We aimed {admiral} to be **the** package for ADaM creation even before deciding to create the package together with GSK. 
+We aimed [{admiral}](https://github.com/pharmaverse/admiral) to be **the** package for ADaM creation even before deciding to create the package together with GSK. 
 By being transparent about our endeavor, e.g. Thomas Neitmann (then at Roche) posting on LinkedIn, we managed to connect with Micheal Rimler from GSK and soon realized that we were dealing with the exact same challenge at both companies, and that a collaborative effort would improve the final product while reducing individual efforts.
-A working prototype of {admiral} was to be created by GSK and Roche within six months, and would then be open sourced. 
-In our effort to communicate openly, we informed statistical programmers from over 20 companies about the {admiral} project and invited them to try it out and provide feedback once released. 
+A working prototype of [{admiral}](https://github.com/pharmaverse/admiral) was to be created by GSK and Roche within six months, and would then be open sourced. 
+In our effort to communicate openly, we informed statistical programmers from over 20 companies about the [{admiral}](https://github.com/pharmaverse/admiral) project and invited them to try it out and provide feedback once released. 
 In the end, we received over 500 comments from over 50 programmers. 
 
 This was instrumental in creating a product that was optimised for general usage in the clinical reporting field and ensured that other companies would not unknowingly invest into their own solution to this challenge. 
 Open sourcing early is particularly beneficial because this ensures from the get-go that code created is aimed at a general audience, and not company specific (perhaps by accident).
 
 
-{admiral} was created with the long term goal of having a stable and flexible solution for the clinical reporting pipeline. 
-In that spirit, its permissive apache 2.0 licence (jointly owned by Roche and GSK) further strengthens trust into the the project, namely for three reasons: 
+[{admiral}](https://github.com/pharmaverse/admiral) was created with the long term goal of having a stable and flexible solution for the clinical reporting pipeline. 
+In that spirit, its permissive [apache 2.0 licence](https://www.apache.org/licenses/LICENSE-2.0) (jointly owned by Roche and GSK) further strengthens trust into the the project, namely for three reasons: 
 
   - Jointly owned means that efforts to monetize the code-base by one company could be vetoed by the other. The permissive licence ensures that in such an unlikely case, the code-base that has been published would stay available and could always be used and improved upon by others. 
 
   - Having this package backed by Roche and GSK ensures (as far as this is ever possible) funding for properly maintaining the packages. This is crucial, as a package is rarely **finished**. 
 
-Up to now, experts from many more companies have joined {admiral} or one of its therapeutic area specific package-extensions, inspiring even more trust into its reliability.
+Up to now, experts from many more companies have joined [{admiral}](https://github.com/pharmaverse/admiral) or one of its therapeutic area specific package-extensions, inspiring even more trust into its reliability.
 If you would like to learn more about licenses for open source projects in the clinical reporting world please check out the [recent E2E guidence on open source license](https://phuse-org.github.io/E2E-OS-Guidance/) 
 
 ## Development workflow
 
-Every improvement, task, or feature we want to implement on {admiral} starts as an issue on our [GitHub repository](https://github.com/pharmaverse/admiral).
+Every improvement, task, or feature we want to implement on [{admiral}](https://github.com/pharmaverse/admiral) starts as an issue on our [GitHub repository](https://github.com/pharmaverse/admiral).
 It is the centerpiece of our development workflow, along with our [developer guides](https://pharmaverse.github.io/admiraldev/devel/articles/development_process.html) which describe in detail the strategies, conventions, and workflows used in development.
-The guides help us keep the {admiral} package internally consistent (e.g. naming conventions, function logic) but also ensure that {admiral} adjacent packages follow the same conventions and share the user interface.
+The guides help us keep the [{admiral}](https://github.com/pharmaverse/admiral) package internally consistent (e.g. naming conventions, function logic) but also ensure that [{admiral}](https://github.com/pharmaverse/admiral) adjacent packages follow the same conventions and share the user interface.
 This is further helped by the implemented CICD pipeline which ensures styling convention and spelling (and much more).
 
 
@@ -84,19 +84,20 @@ Here, the role of product lead (currently [Edoardo Mancini](https://www.linkedin
 These stand-up meetings are centered around the [project-board](https://github.com/orgs/pharmaverse/projects/12) which gives a complete overview of activities and progress.
 Issues are mostly self-assigned so developers can really chose what they want to work on. 
 
-By design, {admiral} is community built. 
+![GitHub project board](project_board.png)
+
+By design, [{admiral}](https://github.com/pharmaverse/admiral) is community built. 
 Most developers working on the project are statistical programmers working on clinical reporting themselves. 
-As an open source project, community input is highly valued, and anyone using admiral is encouraged to submit issues or take on issues as part of the development team.
+As an open source project, community input is highly valued, and anyone using [{admiral}](https://github.com/pharmaverse/admiral) is encouraged to submit issues or take on issues as part of the development team.
 We also do occasional events to bring the statistical programmers community and the developers closer together. 
-Just last February we organised the {admiral} hackathon which had up to 500 participants.
-
+Just last February we organised the [{admiral}](https://github.com/pharmaverse/admiral) hackathon which had up to 500 participants.
 
 
 ## Impact
 
-For Roche, this agreement is great: They get access to a programm created by specialists and users from across the industry but paying only a fraction of the developmental costs. 
+For Roche, cross-industry package development work out in their favor: They get access to software created by specialists and users from across the industry but paying only a fraction of the developmental costs. 
 Of course, they don't have total developmental control but they do get a seat at the table. 
-Any gaps between the open source {admiral} package and the proprietary Roche workflow were bridged by the internal {admiralRoche} package. 
+Any gaps between the open source [{admiral}](https://github.com/pharmaverse/admiral) package and the proprietary Roche workflow were bridged by the internal {admiralRoche} package. 
 
 The switch towards a more language agnostic platform, and open source languages specifically, opens the door to a broad population of university graduates with diverse backgrounds.
 I personally would not have considered this position five years ago due to a misalignment of skills and job requirements.
@@ -125,7 +126,7 @@ The possibility for statistical programmers to pivot towards developing software
 It is this transformation that is reflected by the choice of Roche to re-brand statistical programmers as analytical data scientists. 
 The fact that cross-industry development is being advocated for really lets programmers expand their network outside of their company.
 
-The {admiral} project serves as a testament to the power of collaborative open-source development and the potential it holds for the future of work in this industry.
+The [{admiral}](https://github.com/pharmaverse/admiral) project serves as a testament to the power of collaborative open-source development and the potential it holds for the future of work in this industry.
 
 <!--------------- appendices go here ----------------->