🚧🚧🚧 UNDER CONSTRUCTION 🚧🚧🚧

.gitignore

@@ -16,3 +16,5 @@ vignettes/*.pdf
 # File gen artefacts
 *.html
 *.pdf
+
+/.quarto/

README.md

@@ -1,26 +1,29 @@
-# isc-proposal
+# 🚧🚧🚧 UNDER CONSTRUCTION: isc-proposal 🚧🚧🚧
+
+This repository is currently being revisited.
+An update will be released in early September 2025.
 
 [![build-status](https://github.com/YOUR-USERNAME/YOUR-REPOSITORY/actions/workflows/publish-proposal.yaml/badge.svg)](https://github.com/YOUR-USERNAME/YOUR-REPOSITORY/actions/workflows/publish-proposal.yaml)
 
 This repository is a boilerplate repository that helps you prepare your proposal for the [R Consortium](https://www.r-consortium.org).
 
-## Background 
+## Background
 
 Set up in 2015, the R Consortium is an organisation set up to help support the R Foundation, the R Community, and R users.
 
-> The primary purpose of the R Consortium (collectively, the “Purpose”) is to: 
+> The primary purpose of the R Consortium (collectively, the “Purpose”) is to:
 >
 >(a) advance the worldwide promotion of and support for the R open source language and environment as the preferred language for statistical computing and graphics (the “Environment”);
 >
->(b) establish, maintain, seek support for, and develop infrastructure projects and technical and infrastructure collaboration initiatives related to the Environment, and such other initiatives as may be appropriate to support, enable and promote the Environment; 
+>(b) establish, maintain, seek support for, and develop infrastructure projects and technical and infrastructure collaboration initiatives related to the Environment, and such other initiatives as may be appropriate to support, enable and promote the Environment;
 >
->(c) encourage and increase user adoption, involvement with, and contribution to, the Environment; 
+>(c) encourage and increase user adoption, involvement with, and contribution to, the Environment;
 >
->(d) facilitate communication and collaboration among users and developers of the Environment, the R Consortium and the R Foundation for Statistical Computing (the “R Foundation”); 
+>(d) facilitate communication and collaboration among users and developers of the Environment, the R Consortium and the R Foundation for Statistical Computing (the “R Foundation”);
 >
->(e) support and maintain policies set by the Board; and 
+>(e) support and maintain policies set by the Board; and
 >
->(f) undertake such other activities as may from time to time be appropriate to further the purposes and achieve the goals set forth above.  
+>(f) undertake such other activities as may from time to time be appropriate to further the purposes and achieve the goals set forth above.
 >
 >In furtherance of these efforts, the R Consortium shall seek to solicit the participation of all interested parties on a fair, equitable and open basis.
 
@@ -44,11 +47,11 @@ This is a boilerplate repository that you will need to fork, title appropriately
 
 -   Use the "Use this template" button on GitHub
 -   Create a new repository with a name to reflect your proposal
--   Create a new Rstudio project from version control and use the git URL for the repo
+-   Create a new Positron/RStudio/IDE project from version control and use the git URL for the repo
 -   Write an overview of the proposal instead of this boilerplate for the README
--   Start completing the relevant Rmd pages of the proposal
+-   Start completing the relevant qmd pages of the proposal
 -   Render `isc-proposal.qmd` to build the document locally
--   Regularly commit and push the changes to github
+-   Regularly commit and push the changes to GitHub
 -   Solicit feedback and contributions from others
 
 ### Automatically generate your proposal

_quarto.yml

@@ -0,0 +1,5 @@
+project:
+  title: "Isc-proposal"
+  render:
+    - "*.qmd"
+    - "!proposal/"

isc-proposal.qmd

@@ -1,34 +1,39 @@
 ---
 title: "Proposal Title"
-author: 
+author:
   - name: Annie Easley
     orcid: 5555-5555-5555-5555
     affiliations:
       - "Lewis Research Center, National Aeronautics and Space Administration"
-    
+
 date: today
 date-format: iso
 format:
   html:
     embed-resources: true
   hikmah-pdf:
-    geometry: 
+    geometry:
       - left=1.25in
       - right=1.25in
 bibliography: references.bib
 ---
 
-{{< include proposal/signatories.qmd >}}
+# 🚧🚧🚧 UNDER CONSTRUCTION 🚧🚧🚧
+
+This repository is currently being revisited.
+An update will be released in early September 2025.
+
+{{< include proposal/00-exec-summary.qmd >}}
 
-{{< include proposal/problemdefinition.qmd >}}
+{{< include proposal/01-signatories.qmd >}}
 
-{{< include proposal/proposal.qmd >}}
+{{< include proposal/02-problemdefinition.qmd >}}
 
-{{< include proposal/timeline.qmd >}}
+{{< include proposal/03-proposal.qmd >}}
 
-{{< include proposal/requirements.qmd >}}
+{{< include proposal/04-timeline.qmd >}}
 
-{{< include proposal/success.qmd >}}
+{{< include proposal/06-success.qmd >}}
 
 ::: refs
-:::
+:::

proposal/00-exec-summary.qmd

@@ -0,0 +1,6 @@
+# Executive Summary
+
+<!--
+This section provides a condensed view of the entire proposal, one page long.
+It should be a comprehensive high-level overview that captures the essence of the proposal, including its goals, methods, expected outcomes, deliverables, and budget.
+-->

proposal/signatories.qmd → proposal/01-signatories.qmd

@@ -1,29 +1,30 @@
 # Signatories
-<!-- 
+<!--
 This section provides the ISC with a view of the support received from
 the community for a proposal. Acceptance isn't predicated on
-popularity but community acceptance is important.  Willingness to
+popularity but community acceptance is important. Willingness to
 accept outside input is also a good marker for project delivery.
 
 An optional section would be for R-Core signatories where changes to R
 are proposed.
 -->
 
 ## Project team
-<!-- 
+<!--
 Who are the people responsible for actually delivering the project if
 the proposal gets accepted and are already signed up and rearing to
-go?
+go? Briefly describe all participants and the skills they will bring
+to the project.
 -->
 
 ## Contributors
-<!-- 
+<!--
 Who are the people who have actively helped with this proposal but
 won't necessarily be on the core project team later?
 -->
 
 ## Consulted
-<!-- 
+<!--
 Who has been given the opportunity to provide feedback on the
 proposal? This should include any R Consortium & ISC members who the
 proposal has been discussed with.

proposal/problemdefinition.qmd → proposal/02-problemdefinition.qmd

@@ -5,7 +5,7 @@ bibliography: references.bib
 # The Problem
 
 ```{=html}
-<!-- 
+<!--
 Outlining the issue / weak point / problem to be solved by this
 proposal. This should be a compelling section that sets the reader up
 for the next section - the proposed solution!
@@ -14,8 +14,10 @@ It is important to cover:
 
  - [ ] What the problem is
  - [ ] Who it affects
- - [ ] Have there been previous attempts to resolve the problem
- - [ ] Why it should be tackled
+ - [ ] Why is it a problem
+ - [ ] What will solving the problem enable (why should it be solved)
+ - [ ] Brief summary of existing work and previous attempts (e.g., relevant R packages)
+ - [ ] If proposing changes to R itself: letter of support from R Core member
 -->
 ```
 

proposal/03-proposal.qmd

@@ -0,0 +1,50 @@
+# The proposal
+<!--
+How are you going to solve the problem? Include the concrete actions you
+will take and an estimated timeline. What are likely failure modes and
+how will you recover from them?
+
+This is where the proposal should be outlined.
+-->
+
+## Overview
+<!--
+At a high-level address what your proposal is and how it will address
+the problem identified. Highlight any benefits to the R Community that
+follow from solving the problem. This should be your most compelling
+section.
+
+Include concrete actions you will take and estimated timeline.
+-->
+
+## Detail
+<!--
+Go into more detail about the specifics of the project and how it delivers
+against the problem.
+
+Depending on project type the detail section should include:
+-->
+
+### Minimum Viable Product
+
+<!--
+What is the smallest thing you can build that delivers value to your users?
+-->
+
+### Architecture
+
+<!--
+What does the high-level architecture look like?
+-->
+
+### Assumptions
+
+<!--
+What assumptions are you making that, if proven false, would invalidate the project?
+-->
+
+### External dependencies
+
+<!--
+What external dependencies does the project have (e.g. libraries, services, other projects, etc.)?
+-->

proposal/04-timeline.qmd

@@ -0,0 +1,59 @@
+# Project plan
+
+## Start-up phase
+<!--
+Covering the planning phase, this section should provide a relatively
+detailed plan of how work will start on the project. This section is
+important because projects need to get up and running quickly.
+
+
+ - [ ] Setting up collaboration platform inc. code for contributors etc.
+ - [ ] Licence decisions
+ - [ ] Reporting framework
+-->
+
+
+## Technical delivery
+<!--
+Covering the actual delivery of the project this section should
+provide at least a high-level description of the implementation.
+
+Including target dates is really important as you need to be committed
+and the ISC need to have a means of tracking delivery
+-->
+
+## Other aspects
+
+<!--
+How will you ensure that your work is available to the widest number
+of people? Please specify the open-source or creative commons license(s)
+you will use, how you will host your code so that others can contribute,
+and how you will publicize your work. We encourage you to plan content
+to be shared quarterly on the R Consortium blog.
+
+ - [ ] Announcement post
+ - [ ] Delivery blog post
+ - [ ] Social media
+ - [ ] UseR!
+ - [ ] ISC meetings
+-->
+
+## Budget & funding plan
+
+<!--
+Outline the milestones for development and how much funding will be
+required for each stage (as payments will be tied to project milestone
+completion). Each milestone should specify the work to be done and the
+expected outcomes, providing enough detail for the ISC to understand
+the scope of the project work and assess the likelihood of success.
+
+We expect that most of the budget will be allocated
+for labor costs. We do not cover indirect costs. The ISC grants cannot
+cover such things as travel, lodging, food, journal publication fees,
+or personal hardware. Cloud services may be covered if they are specific
+to the project and the project period. The ISC reserves the right to vet
+how funds are used for each project separately. If in doubt, please reach
+out to us.
+-->
+
+## Budget

proposal/success.qmd → proposal/06-success.qmd

@@ -1,33 +1,22 @@
 # Success
-<!-- 
+<!--
 Projects should have a definition of done that is measurable, and a
 thorough understanding going in of what the risks are to delivery
 -->
 
 ## Definition of done
-<!-- 
-What does success look like? 
+<!--
+What does success look like?
 -->
 
 ## Measuring success
-<!-- 
+<!--
 How will we know when success is achieved, what markers can we use
 along the way
 -->
 
 ## Future work
-<!-- 
+<!--
 How could this be extended / developed in the future by yourself
 and/or the community in general?
 -->
-
-## Key risks
-<!-- 
-What sort of things could come up that can delay or break the project?
-
- - [ ] People
- - [ ] Processes
- - [ ] Tooling & Technology
- - [ ] Costs
-
--->