OSS Initial Release

.dockerignore

@@ -0,0 +1,64 @@
+# ==================== Python artifacts
+**/__pycache__
+**/*.pyc
+**/*.pyo
+**/*.pyd
+.python-version
+.mypy_cache
+_autosummary
+
+# ==================== Build artifacts
+build
+dist
+target
+*.egg-info
+*.DS_Store
+*.scala-build
+.bsp
+.bloop
+.metals
+.cache
+.lib
+tmp
+.tmp
+gigl.egg-info/
+gigl_dataflow_setup.egg-info/
+miniconda/
+
+# ==================== IDE / Editor folders
+.idea
+.vscode
+.history
+
+# ==================== Project tools & devcontainers
+.devcontainer
+tools/
+project/boot/
+project/plugins/project/
+project/target/
+**/project/**/metals.sbt
+src_managed/
+lib_managed/
+src/test/assets/output/*
+containers/
+
+# ==================== Test / temp / logs
+.test_assets/
+logs/
+**/src/test/assets/**/output/*
+
+# ==================== Git & VCS
+**/.git
+
+# ==================== Fossa files
+fossa
+fossa.bundle
+fossa*.zip
+
+# ==================== Miscellaneous folders
+proto/
+examples/MAG240M/downloads/
+scripts/
+graphlearn_torch/
+graphlearn_torch.egg-info/
+do_not_open_source

.gitignore

@@ -0,0 +1,43 @@
+.idea/
+*.pyc
+__pycache__
+.vscode
+.scala-build
+.bsp
+.tmp
+.test_assets/
+build
+*.DS_Store
+logs/
+.devcontainer/
+gigl.egg-info/
+gigl_dataflow_setup.egg-info/
+.python-version
+dist/
+*.egg-info/
+miniconda/
+.mypy_cache/
+tools/
+.metals/
+.bloop/
+**/project/**/metals.sbt
+**/src/test/assets/**/output/*
+target/
+lib_managed/
+src_managed/
+project/boot/
+project/plugins/project/
+.history
+.cache
+.lib/
+python/gigl/env/customer.yaml
+python/gigl/deps/
+_autosummary/
+graphlearn_torch/
+graphlearn_torch.egg-info/
+.git/
+
+# Ignore downloaded fossa files.
+fossa
+fossa.bundle
+fossa*.zip

.mdformat.toml

@@ -0,0 +1 @@
+wrap = 120

.pre-commit-config.yaml

@@ -0,0 +1,17 @@
+repos:
+  - repo: local
+    hooks:
+    # Hook to run make format on demand.
+    # This isn't stricly necessary now that we don't run format on push but nice to keep around as an example.
+    - id: make-format
+      name: make-format
+      entry: make format
+      language: system
+      pass_filenames: false
+      stages: [manual]
+
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.0.1
+    hooks:
+      - id: end-of-file-fixer
+      - id: trailing-whitespace

CHANGELOG.md

@@ -0,0 +1,19 @@
+# GiGL Changelog
+
+All notable changes to this repository will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
+
+## [Unreleased]
+
+### Added
+
+### Changed
+
+### Deprecated
+
+### Removed
+
+### Fixed
+
+## [0.0.7] - TODO

CODE_OF_CONDUCT.md

@@ -0,0 +1,95 @@
+# Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders of the GiGL community pledge to make participation in our community a
+harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex
+characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality,
+personal appearance, race, caste, color, religion, or sexual identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our community include:
+
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
+- Focusing on what is best not just for us as individuals, but for the overall community
+
+Examples of unacceptable behavior include:
+
+- The use of sexualized language or imagery, and sexual attention or advances of any kind Trolling, insulting or
+  derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others’ private information, such as a physical or email address, without their explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Enforcement Responsibilities
+
+GiGL community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take
+appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+GiGL community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits,
+issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for
+moderation decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing
+the community in public spaces. Examples of representing our community include using an official email address, posting
+via an official social media account, or acting as an appointed representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible
+for enforcement at `opensource [at] snap [dot] com`. All complaints will be reviewed and investigated promptly and
+fairly.
+
+All community leaders are obligated to respect the privacy and security of the reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem
+in violation of this Code of Conduct:
+
+### 1. Correction
+
+Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
+
+Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and
+an explanation of why the behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+Community Impact: A violation through a single incident or series of actions.
+
+Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including
+unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding
+interactions in community spaces as well as external channels like social media. Violating these terms may lead to a
+temporary or permanent ban.
+
+### 3. Temporary Ban
+
+Community Impact: A serious violation of community standards, including sustained inappropriate behavior.
+
+Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified
+period of time. No public or private interaction with the people involved, including unsolicited interaction with those
+enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate
+behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
+
+Consequence: A permanent ban from any sort of public interaction within the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at
+https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.
+
+For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq.

CONTRIBUTING.md

@@ -0,0 +1,126 @@
+# Contributing to GiGL
+
+Thank you for your interest in GiGL! We welcome community contributions and appreciate your time and effort in helping
+improve the project. Before getting started, please take a moment to review these guidelines.
+
+## Code of Conduct
+
+We want this project to be a welcoming space for everyone. By contributing, you agree to follow our
+[Code of Conduct](CODE_OF_CONDUCT.md) and help keep the community respectful and inclusive.
+
+## Reporting Issues
+
+**If security related please see [SECURITY.md](SECURITY.md) for guidance.**
+
+If you find a bug or have a feature request, please open an issue and provide as much detail as possible:
+
+- Search existing issues to avoid duplicates.
+- Clearly describe the issue with steps to reproduce (If applicable).
+  - Include relevent specs used both task and resource.
+  - Provide relevant logs or screenshots if applicable.
+- Expected and actual behahavior.
+- List Suggested solutions (if any).
+
+## Legal Terms
+
+By submitting a contribution, you represent and warrant that:
+
+- It is your original work, or you have sufficient rights to submit it.
+- You grant the GiGL maintainers and users the right to use, modify, and distribute it under the MIT license (see
+  [LICENSE](LICENSE) file); and
+- To the extent your contribution is covered by patents, you grant a perpetual, worldwide, non-exclusive, royalty-free,
+  irrevocable license to the GiGL maintainers and users to make, use, sell, offer for sale, import, and otherwise
+  transfer your contribution as part of the project.
+
+We do not require a Contributor License Agreement (CLA). However, by contributing, you agree to license your submission
+under terms compatible with the MIT License and to grant the patent rights described above. If your contribution
+includes third-party code, you are responsible for ensuring it is MIT-compatible and properly attributed.
+
+Moral Rights Disclaimer: Where permitted by law, you waive any moral rights (e.g., the right to object to modifications)
+in your contribution. If such rights cannot be waived, you agree not to assert them in a way that interferes with the
+project’s use of your contribution.
+
+## Open Development
+
+We follow an open development process where both core team members and the community contribute through the same review
+process. All pull requests, regardless of the author, go through the same review and approval workflow to ensure
+consistency and quality.
+
+## How to Contribute
+
+### Proposing a Non-Trivial Change
+
+- Before starting major work, open an issue to discuss your proposal with the maintainers.
+- Clearly outline the problem and your proposed solution.
+- Gather feedback and refine your approach before implementation.
+- This ensures alignment with project goals and avoids unnecessary work.
+
+### Submitting Code
+
+1. Fork the repository and create a feature branch.
+1. Ensure all unit tests pass before submitting.
+1. Add relevant unit/integration/performance tests.
+1. Submit a pull request (PR) with a clear description of your changes.
+1. Address review feedback promptly.
+1. All changes should be submitted to the `main` branch via a pull request.
+
+### Semantic Versioning & Changelog
+
+We adhere to [Semantic Versioning](https://semver.org/) (MAJOR.MINOR.PATCH) to ensure clear version tracking:
+
+- **MAJOR** versions introduce breaking changes.
+- **MINOR** versions add functionality in a backward-compatible manner.
+- **PATCH** versions fix bugs and small issues.
+
+All significant changes are recorded in the [CHANGELOG](CHANGELOG.md), where contributors should document major updates,
+new features, and fixes.
+
+TODO: (svij) More instructions to come on how release process will be managed.
+
+### Commit Guidelines
+
+- We squash commit PRs. Ensure your PRs follow the [pull_request_template](pull_request_template.md).
+
+### PR Checklist:
+
+#### Code Correctness
+
+- Is the code logically correct?
+- Are there any edge cases that we have not covered?
+- Has the author executed on a reasonable testing plan and/or has the reviewer tested the changes themselves?
+- Does the PR meet its objective of satisfying the task requirements? i.e. will it scale to necessary requirements
+
+#### Code Comprehension/Consistency
+
+- Will the change be easily understandable to a broader audience?
+- Will the solution make sense as the code-base evolves?
+- Does the PR follow agreed upon/ industry best practices, and follow patterns already established in the codebase?
+
+### Author’s Responsibility:
+
+#### Most important: Create *[Small PRs](https://google.github.io/eng-practices/review/developer/small-cls.html)*
+
+Explicitly tag two people on your PR (See [OWNERS](OWNERS) for list of reviewers). Generally the first review to your PR
+should be done within 1-2 business days depending on scope from when you ask for review; if this isn't done, it is your
+responsibility to follow up for a response or to find a different reviewer if needed using our
+[Communication Channels](#questions). In cases when the PR is not “small”
+([see what it means for PR to be small](https://google.github.io/eng-practices/review/developer/small-cls.html#what_is_small),
+1-2 business days guidance is not reasonable, and reviewers may push back and ask you to break the PR down into “small
+PRs.”
+
+More generally,
+
+- In rare cases, you may need to add more reviewers in cases of driving consensus or leveraging certain “domain
+  expertise”.
+- In some “contextually” very small PRs, you may only require one reviewer, for example:
+  - Adding a new small unit test.
+  - Formatting, variable or directory name change; this could span many files and lines; contextually, it is still a
+    “very small” change.
+  - Editing the OWNERS file
+  - Fixing a spelling mistake or adding a few lines to a README
+
+Happy coding!
+
+## Questions/Comments/Ideas?
+
+If you need help, or need to get in touch with the primary maintainers of the project, please open a discussion/issue.