# Solution

A short (~5 minutes) questionnaire that leads to a badge for your README indicating your maintenance/end-of-life plans.
This should be a minimal amount of work to encourage people to consider maintenance without becoming overwhelmed by the options

## Questions include:
* How much maintenance do you want to do? None/a tiny bit/a lot/etc.
* Do you have funding for maintenance?
* Have you identified funding opportunities for further maintenance?
* How long do you intend to maintain for?
* Will you continue maintenance after funding runs out?
* Who is the contact person at the end of the project?
* Do you expect to ever come back to this project for further development? I.e. is this a development gap, not end-of-life
* Do you welcome new development from other people? Are you able to answer questions/open to being contacted?
* Do you support/help track forks for new development?

# Diagrams / Illustrations

# New discussion

## Possible questions
* Does the project have a specific end date?
* Is this an individual project, or team-based?
* Is there funding available to cover ongoing support? If not, do you intend to seek funding?
* Is there potential for the project to be extended?
* Is there a dedicated person for ongoing maintenance, or shared responsibility?
* Will you provide support, or will it be passed to someone else?
* How long will the end-of-life support (hoped to) be?
* Will your contact details/affiliation change?
* Will the future users be the current users, or will the project become more widely adopted?
* Is there a specific server/webhost/database instance required, or is it standalone/bundled?
* What type of maintenance Do you intend to do? none/Merge PRs only/minor bug fixes only/bug fixes only/more…
* Do you welcome new issues/pull requests?
* Do you welcome new contributors/maintainers?
* Are there commitments to the funding body/other relating to ongoing provision?
* How sustainable is the project currently?
* Will "replacement projects" be pointed to if the project is superseded?
* What is the career stage of the developers/supporters?

Assume high level parts are binary "yes"/"no"

### Question themes
* funding
* continued dev vs maintenance
* infrastructure
* size of userbase
* size of maintainer group
* contactability of developers/contact info

## Logic

- text with a couple of lines saying what the questionnaire is about
- Load first question
- Text of the question
- Options for the answers/(multiple choice, maybe a few free text?)
- Button to accept
- save the answer
- Based on output, load next question
- logic that process all answers and allote badges
- display badges HTML code to be copied

## Communication between front- and back-end

* Expose "question and choice(s)"
* Present badge
* Request "answer"

question = ("question text", {
        "option 1": next_question,
        "option 2": next_question
        })
question_returned = ("question text", question[1].keys())

def get_question():
    """Returns:
    the text of a question,
    an iterable of options, and
    the next steps for each option."""
    #question_returned (as above)
    #status = boolean -if False get_badge-
    return (status, question_returned)


def put_answer(question_text, chosen_option):
    """ Returns status:
    Error, etc.
    More questions True/False"""
    #chosen option = string
    return status
    
def get_badge():
    return md_code
    
def reset():
    current_question = first_question
    return status

## Other information to render from repository

* Introduction text/instructions page
* Additional resources, suggested badge list

example={
  1: Question("example text 1",  {"option 1 ": 2, "option 2": 3}),
  2: Question("example text 2",  {"option 1 ": 2, "option 2": 3}),
  3: Question("example text 3",  {"option 1 ": 2, "option 2": 3}) 
  }

## Judging criteria

1. Novelty, creativity, coolness and/or usefulness

We've defined the problem in the README and hope that it applies to the community. It isn't just "our problem". The presentation will feature a walkthrough of the decision tree and show a badge. We add a badge to this repository.

2. Implementation and infrastructure

We follow good practice: we use collaborative tools (GitHub, REPL.it, hackmd, Zoom(!), Binder) and accessible server.

It hopefully works when demonstrated.

3. Demo and presentation

Demonstration of the UI, repository and walking through to reach a decisions. Explained while doing so some of the design choices.

4. Project transparency

We have a public GitHub repository (collaboration restrictions for development) and Binder which is open. Repository has a README which has signficant design and motivation documenatation. Python code has docstrings.

CC-BY 4.0 licence with code of conduct and contribution guidelines.

5. Future potential

Project is extensible (and incomplete) with "known issues" (including development idea) provided in the README.

6. Team work

All team members had things to do, even the one who hates Python. PRs raised and reviewed. QA review on back- and front-ends. Good splitting up of work, with sufficient overlap for sensible review but not needless duplication.