Qiskit is an open-source quantum computing software development framework for leveraging today's quantum processors in research, education, and business.

• Table of Contents
• 🚀 Get Up and Running
• 💻 Technology Used
• 🏭 Content Generation
  • 🥸 Mocking content
• 🏷️ Naming Conventions
  • Nuxt Components
• ✏️ How to Contribute
• 🗓 Open backlog
• 👩‍💻 Maintainers
• 🔗 Connect with Qiskit

1. Download this repository and go to its folder

   git clone git@github.com:Qiskit/qiskit.org.git && cd qiskit.org

2. Install dependencies

    npm install

3. Create an .env file

cp .env.example .env

4. Run a local server with hot reload at localhost:3000

   npm run dev

Qiskit.org is a static website generated using Nuxt.

We create and run tests using Vitest, avoid syntax errors using ESLint and Stylelint, and automate code integration and deployment using GitHub Actions.

Qiskit.org integrates with the tools used by the IBM Quantum Community Team to generate content based on 3rd party APIs such as Airtable. Part of this content is prefetched during building time.

During local development, mock data is generated by default but fetching real data from Airtable is possible. If you need to do this, please ask a core maintainer for the AIRTABLE_ACCESS_TOKEN, or generate your own if you have an Airtable account with access to the required bases. Once you have the Airtable access token, change these environment variables in your .env file:

• AIRTABLE_ACCESS_TOKEN=<Airtable access token>
• GENERATE_CONTENT=true
• MOCK_CONTENT=false

Then you can run the local server as usual and the content will be fetched at the beginning:

npm run dev

If you don't have access to the Airtable data or you don't need to fetch it, mock data can be generated by setting the environment variable MOCK_CONTENT to true in your .env file. This is set by default after you generate your .env file from .env.example.

The project has a default mocked content under the hooks/mock/content folder. If you want your own custom mocked content, you can create a new folder and set it as your mocked content folder using the environment variable MOCK_BASE_PATH which should be an absolute path of your system.

When working with files in the components/ directory, please adhere to the following naming conventions:

• Component files and directories should be named using PascalCase.
• Always use multi-word names.
• Simplify component names where possible, for example, EventsItemCard can be named EventsCard.
• Group related components in folders when more than one component refers to the same concept.
• When naming the component .vue files, include the whole path to make it easier to locate the components.
• Generic components that can be reused across multiple pages should be placed in the components/Ui/ directory.
• Components specific to a page should be placed in their respective directory, such as components/Events/ for events-specific components.
• Avoid appending "Section" to component names, as it is usually implied that the component represents a section of the page.

Contributions are always welcomed, no matter how large or small. Before contributing, please read the contributing guide and code of conduct.

We actively maintain our backlog using GitHub Projects. You can view our backlog here.

Eddybrando Vásquez 🐛💻💬

Randy Tolentino 🐛💻💬

Yaiza García 🐛💻💬

• Twitter
• Medium
• YouTube
• Slack