Skip to content
Open
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
200 changes: 200 additions & 0 deletions CONTRIBUTING.md
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I wrote a long and detailed file level comment here proposing a detailed step by step strategy for integrating this with our standard contributing guide template used on other repos, but after spending an hour writing it, fucking GitHub somehow got amnesia and wiped it when I accidentally hit back (unlike literally any other GitHub review comment normally), just when I was thinking of copying it to have a backup just in case GitHub fucked up. RIP...

Instead of reinventing the wheel here developing and maintaining an entirely separate contribution guide, IMO we should instead start with our standard template used on most of our other repos, adding/replacing the repo-specific bits from here as needed, and contributing any common changes you find valuable upstream to the aforementioned master template so they can be re-used elsewhere too.

Given the scope of the change and particularly the delay here, I'd be more than happy to take care of the integration with a commit here if you prefer—just let me know!

Here are the specific integration steps I suggest:

  • Delete "Setting Up a Development Environment with Nox (Recommended)", "Installing and Using the Pre-Commit Hooks", and "Decide which branch to use" sections
  • Replace "Setting Up a Development Environment Manually" and "Building the Project" with the content of "Development setup", which to be consistent with the others can be called "Installing and building" or similar
    • Add the content of the "Add the upstream remote" section to the end of the "Cloning the repository" section, as without Nox to do it for you, it is better mentioned at that point
  • Find/replace "Spyder-Infra" (in lowercase and Title Case variants) and the remaining couple _FIXME_ placeholders that are relevant
  • "Creating Blog Posts" can go after "Contributing Changes", since it provides detailed advice for a specific sub-type of code contribution after offering an overview of the overall contribution flow
  • We can add a section "Make and test your changes" between the "Prepare" and "Commit" sections of "Contributing Changes" (in the upstream template too), reminding users to run npm run dev and ensure they appear as expected (step 1 of your "PUll request process".
  • Standards and Conventions
    • "Key standards" should be updated to list the specific, well, standards and conventions this repo follows (rather than generic ChatGPT-sounding advice, jaja)
    • If desired to be retained, the "File structure" summary can go as a second section under here
  • The detailed specifics in the "Reporting Issues" section of your version can be added to the "Reporting Issues" section of the template (and some of it at least is worth adding upstream)
  • The Questions section can be kept, added to the end and also contributed upstream
  • The remaining sections few sections are redundant with those added in the template and elsewhere

Original file line number Diff line number Diff line change
@@ -0,0 +1,200 @@
# Contributing to the Spyder Website

Thank you for your interest in contributing to the Spyder website! This guide will help you get started with different types of contributions.

## Table of Contents

- [Contributing to the Spyder Website](#contributing-to-the-spyder-website)
- [Table of Contents](#table-of-contents)
- [Getting Started](#getting-started)
- [Development Setup](#development-setup)
- [Types of Contributions](#types-of-contributions)
- [Creating Blog Posts](#creating-blog-posts)
- [Adding New Authors](#adding-new-authors)
- [Creating the Blog Post](#creating-the-blog-post)
- [Code Contributions](#code-contributions)
- [Guidelines](#guidelines)
- [File Structure](#file-structure)
- [Reporting Issues](#reporting-issues)
- [Pull Request Process](#pull-request-process)
- [Review Process](#review-process)
- [Style Guidelines](#style-guidelines)
- [Questions?](#questions)
Comment on lines +5 to +22
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this auto-updated, or does it have to be done manually? We use doctoc for this on our other repos (which we'll get for free if and when we add our pre-commit config here).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will remove it for now and we can auto-generate it later using pre-commit.


## Getting Started

1. **Fork the repository** from [spyder-website](https://github.com/spyder-ide/spyder-website)
2. **Clone your fork** locally:
```bash
git clone https://github.com/YOUR-USERNAME/spyder-website.git
cd spyder-website
```
3. **Create a new branch** for your changes:
```bash
git checkout -b your-feature-branch
```
Comment on lines +24 to +35
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Redundant with the Cloning the repository section of our standard template, aside from the "create a new branch" step which interleaves and mixes up one-time step actions (forking, cloning, installing dependencies) with every-time contribution flow (branch creation, building, committing, etc)—our standard template keeps them cleanly separated.


## Development Setup

1. **Install dependencies**:
```bash
npm install
```

2. **Start the development server**:
```bash
npm run dev
```
The site will be available at `http://localhost:5173`

3. **Available scripts**:
- `npm run dev` - Start development server
- `npm run build` - Build for production
- `npm run preview` - Preview production build

## Types of Contributions

We welcome various types of contributions:

- **Blog posts** - Share news, tutorials, or insights about Spyder
- **Bug fixes** - Fix issues in the website functionality
- **Feature enhancements** - Improve existing features or add new ones
- **Documentation** - Improve clarity and completeness of documentation
Comment on lines +55 to +62
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This reads as rather bland, generic and rather ChatGPT-sounding advice that doesn't really add much useful information over what's here and in the standard template; Blog posts have their own section just below as do issues, and the remaining are rather self-evident. Therefore, it seems redundant in the integrated version.


## Creating Blog Posts

### Adding New Authors

If the blog post author(s) haven't been added yet:

1. **Create author folder** in `static/assets/authors/` using a simple identifier (no spaces/special characters)
2. **Add author files**:
- Square avatar image (recommended: 512×512px WEBP format)
- `metadata.json` file:
```json
{
"name": "Author's Display Name",
"image": "filename.webp"
}
```

### Creating the Blog Post

1. **Create post folder** in `src/routes/blog/` (folder name becomes URL slug - use lowercase, no spaces)

2. **Add main content file** `+page.md` with proper frontmatter:
```yaml
---
title: Blog Post Title # Required
author: author-id # Required. For multiple authors, use array: [author1, author2]
pub_date: YYYY-MM-DD # Required (ISO format)
category: Category Name # Optional
tags: Tag1, Tag2 # Optional (comma-separated)
summary: Concise overview of content # Required
---
```

3. **Write content** using mdsvex Markdown:
- [Never indent code blocks](https://mdsvex.pngwn.io/docs#limitations)
- Use standard Markdown syntax for formatting
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no such thing as "standard" Markdown, because there is no "Markdown standard" and many sometimes-incompatible dialects are used (e.g. CommonMark, GFM, etc). You should specify the dialect here (it wasn't entirely clear to me from reading the docs without being familiar with the parsers/tools it referenced viz its syntax support, but you presumably are).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mdsvex itself uses remark which supports CommonMark out of the box. If we want, we could support GFM too with a plugin. So, for now, I will mention this support.

- Follow our [style guide](#style-guidelines) for consistency

4. **Add images** (if needed):
```markdown
![Meaningful description](image.webp "Optional caption")
```
- Store images in the post's folder
- Use descriptive alt text (avoid "image of...", "picture of...", etc.)
- Prefer WEBP format for better performance

5. **Preview your post**:
```bash
npm run dev
```
- Verify post appears at `/blog/your-post-name`
- Check author metadata and image display
- Test on different screen sizes

## Code Contributions

### Guidelines

- Follow the existing code style and conventions
- Write clear, descriptive commit messages
- Test your changes thoroughly
- Update documentation if needed
Comment on lines +120 to +125
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This rather generic advice is or will be be made redundant by the specific reminders in the relevant sections, so no need to include it in the new integrated version


### File Structure

- `src/routes/` - Page routes and content
- `src/lib/` - Reusable components and utilities
- `static/assets/` - Static assets (images, fonts, etc.)
- `src/app.css` - Global styles

## Reporting Issues

Before creating an issue:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two of these three steps are actually about creating an issue itself, not before that. We'll want to keep this in mind when integrating the relevant bits from here into the standard template section (and upstreaming the changes)


1. **Search existing issues** to avoid duplicates
2. **Use the issue template** (if available)
3. **Include relevant details**:
- Clear description of the problem
- Steps to reproduce
- Expected vs. actual behavior
- Browser/OS information (if relevant)
- Screenshots (if applicable)

## Pull Request Process
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first step can be adapted to a section to the template-integrated version as described above (between "Prepare" and "Commit"), while the rest are already taken care of there.


1. **Ensure your changes work locally**:
```bash
npm run dev
# Test your changes thoroughly
```

2. **Keep commits clean and descriptive**:
```bash
git add .
git commit -m "Add: New blog post about feature X"
```

3. **Push to your fork**:
```bash
git push origin your-feature-branch
```

4. **Create Pull Request**:
- Target the `main` branch
- Use a clear, descriptive title
- Fill out the PR template (if available)
- Link any related issues

5. **After submission**:
- Be responsive to feedback
- Make requested changes promptly
- Keep your branch updated with main if needed
Comment on lines +166 to +175
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More generic ChatGPT advice, haha


### Review Process

- All PRs require review before merging
- CI/CD will automatically build and test your changes
- Reviewers may request changes or ask questions
- Once approved, maintainers will merge your PR
Comment on lines +177 to +182
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The actually relevant/useful bits of this generic ChatGPT advice are mostly already incorporated into the standard template, so no need to retain this separate section


## Style Guidelines

- Use clear, concise language
- Follow existing naming conventions
- Maintain consistent formatting
- Optimize images for web (prefer WEBP format)
- Ensure accessibility best practices
Comment on lines +184 to +190
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This mostly generic, ChatGPT set of style guidelines should (besides the WebP for images, which can stay) be replaced with concrete references to the specific standards to follow, as in the standard template


## Questions?

If you have questions or need help:

- Check existing [documentation](README.md)
- Search [existing issues](https://github.com/spyder-ide/spyder-website/issues)
- Create a new issue with the "question" label

Thank you for contributing to the Spyder website! 🎉
176 changes: 156 additions & 20 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,37 +1,173 @@
# Spyder-Website
# Spyder Website

Minimal static [SvelteKit](https://kit.svelte.dev/) set-up made deployable to [GitHub Pages](https://metonym.github.io/sveltekit-gh-pages/). Based on [sveltekit-gh-pages](https://metonym.github.io/sveltekit-gh-pages/)
![Spyder Logo](static/assets/media/spyder-logomark.png)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should use the Readme banner here that is much better proportioned and explicitly designed as a banner, and IMO as a banner it would look better above the main title.


- PostCSS framework provided by [TailwindCSS](https://tailwindcss.com/)
- Icons from the [Svelte Icons Pack](https://leshak.github.io/svelte-icons-pack/)
- Markdown files processed with [mdsvex](https://mdsvex.pngwn.io/)
The official website for [Spyder IDE](https://www.spyder-ide.org) - a powerful scientific environment written in Python, for Python, and designed by and for scientists, engineers and data analysts.

## Deployment
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
[![Built with SvelteKit](https://img.shields.io/badge/Built%20with-SvelteKit-orange.svg)](https://kit.svelte.dev/)
[![Deployed on GitHub Pages](https://img.shields.io/badge/Deployed%20on-GitHub%20Pages-blue.svg)](https://pages.github.com/)

### 1) Install dependencies with NPM:
🌐 **Live Site**: [www.spyder-ide.org](https://www.spyder-ide.org)

```bash
npm install
```
## About

### 2) Test the website (optional)
This repository contains the source code for the official Spyder IDE website. The site serves as:

```bash
npm run dev
```
- **Information hub** for Spyder features and capabilities
- **Download center** for installers and releases
- **Blog platform** for project updates and community news
- **Documentation gateway** linking to guides and resources
- **Community showcase** highlighting contributors and achievements

And visit your local copy at [https://localhost:5173](https://localhost:5173)
## Tech Stack

### 3) Build the website
This website is built with modern web technologies:

```bash
npm run build
- **Framework**: [SvelteKit](https://kit.svelte.dev/) - Full-stack web framework
- **Styling**: [TailwindCSS](https://tailwindcss.com/) - Utility-first CSS framework
- **Content**: [mdsvex](https://mdsvex.pngwn.io/) - Markdown processor for Svelte
- **Icons**: [Svelte Icons Pack](https://leshak.github.io/svelte-icons-pack/) - Icon library
- **Deployment**: [GitHub Pages](https://pages.github.com/) - Static site hosting
- **CI/CD**: GitHub Actions - Automated deployment

## Features

-**Modern Design** - Clean, responsive interface
- 📱 **Mobile Optimized** - Works perfectly on all devices
- 🚀 **Fast Performance** - Static site generation for speed
- 📝 **Blog System** - Dynamic blog with author management
- 🎨 **Component Library** - Reusable UI components
- 🌍 **Internationalization** - Multi-language support ready
-**Accessibility** - WCAG compliant design
- 🔍 **SEO Optimized** - Meta tags and structured data
Comment on lines +34 to +43
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds more like an advertising brochure rather than a readme... 🤔

May as well add Blazing Fast while you're at it 😅


## Quick Start

### Prerequisites

- [Node.js](https://nodejs.org/) (version 18 or higher)
- [npm](https://www.npmjs.com/) (comes with Node.js)
Comment on lines +47 to +50
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be in the contributing guide (as this should be a subset of content there)


### Development Setup

1. **Clone the repository**:
```bash
git clone https://github.com/spyder-ide/spyder-website.git
cd spyder-website
```

2. **Install dependencies**:
```bash
npm install
```

3. **Start development server**:
```bash
npm run dev
```

The site will be available at [http://localhost:5173](http://localhost:5173)

### Available Scripts

| Command | Description |
| --------------------------------- | ---------------------------------------- |
| `npm run dev` | Start development server with hot reload |
| `npm run build` | Build the site for production |
| `npm run preview` | Preview the production build locally |
| `npm run generate-og-images` | Generate Open Graph images |
| `npm run generate-contrib-data` | Generate contributor data |
| `npm run generate-hubspot-data` | Generate HubSpot integration data |
| `npm run generate-funding-schema` | Generate funding schema |

## Project Structure

```
spyder-website/
├── src/
│ ├── routes/ # Page routes and content
│ │ ├── +page.svelte # Homepage
│ │ ├── about/ # About page
│ │ ├── blog/ # Blog posts and pages
│ │ └── download/ # Download page
│ ├── lib/ # Reusable components and utilities
│ │ ├── blocks/ # Page section components
│ │ ├── components/ # UI components
│ │ ├── config/ # Configuration and data
│ │ ├── i18n/ # Internationalization
│ │ ├── store/ # State management
│ │ └── utils/ # Utility functions
│ ├── app.css # Global styles
│ └── app.html # HTML template
├── static/ # Static assets
│ └── assets/ # Images, fonts, media
├── scripts/ # Build and utility scripts
└── ci/ # CI/CD scripts
```

You can also test the built website with
## Deployment

This website is automatically deployed to GitHub Pages using GitHub Actions. The deployment process:

1. **Triggers** on push to `main` branch
2. **Builds** the static site using SvelteKit
3. **Generates** dynamic content (OG images, contributor data, etc.)
4. **Deploys** to GitHub Pages

### Manual Deployment

For manual deployment or testing:

```bash
# Build the site
npm run build

# Preview the built site
npm run preview
```

And preview your built site at [https://localhost:5174](https://localhost:5174)
The built site will be available at [http://localhost:5174](http://localhost:5174)

## Contributing

We welcome contributions from the community! Please see our [Contributing Guide](CONTRIBUTING.md) for details on:

- Setting up the development environment
- Creating blog posts
- Making code contributions
- Submitting pull requests
- Reporting issues

### Quick Contribution Steps

1. Fork this repository
2. Create a feature branch (`git checkout -b feature/amazing-feature`)
3. Make your changes
4. Test locally (`npm run dev`)
5. Commit your changes (`git commit -m 'Add amazing feature'`)
6. Push to your branch (`git push origin feature/amazing-feature`)
7. Open a Pull Request

## Community

- 🐍 **Main Project**: [Spyder IDE](https://github.com/spyder-ide/spyder)
- 💬 **Discussions**: [GitHub Discussions](https://github.com/spyder-ide/spyder/discussions)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uh, no, we don't use this and it 404s.

- 🐛 **Issues**: [Bug Reports](https://github.com/spyder-ide/spyder/issues)
- 📧 **Mailing List**: [Google Groups](https://groups.google.com/group/spyderlib)
- 🐦 **Twitter**: [@Spyder_IDE](https://twitter.com/Spyder_IDE)

## License

This project is licensed under the MIT License - see the [LICENSE.md](LICENSE.md) file for details.

## Acknowledgments

- Built with ❤️ by [@conradolandia](https://github.com/conradolandia) and the Spyder development team
- Special thanks to all [contributors](https://github.com/spyder-ide/spyder-website/graphs/contributors)
- Powered by [SvelteKit](https://kit.svelte.dev/) and [TailwindCSS](https://tailwindcss.com/)
- Hosted on [GitHub Pages](https://pages.github.com/)

---

*Made with love for the Python community*