chore: update community profile (#65)

* update README.md

* update CONTRIBUTING.md

* chore: update pr template

Author: kaihiroi

.github/pull_request_template.md

@@ -1,7 +1,3 @@
----
-labels: "status: in-progress"
----
-
 ## Description
 
 - [link to related issue] or [short description]

CONTRIBUTING.md

@@ -1,14 +1,15 @@
 # Contributing Guideline
 
-Thank you for your interest in contributing to this project! We welcome contributions from everyone, whether it's reporting an issue, submitting a pull request, or suggesting improvements.
-
+Thank you for your interest in contributing to meta contract! We welcome contributions from everyone, whether it's reporting an issue, submitting a pull request, or suggesting improvements.
 
 ## Reporting Issues
+
 If you encounter a bug or have a feature request, please use the provided templates when [opening a new issue](https://github.com/metacontract/mc/issues/new/choose). This helps us address your concerns more effectively.
 
 ## Development Workflow
 
 ### Submitting Pull Requests
+
 When submitting a Pull Request (PR), please keep in mind the following:
 
 - PRs that contain backward-compatible bug fixes or minor changes will generally be merged directly.
@@ -18,63 +19,47 @@ When submitting a Pull Request (PR), please keep in mind the following:
 <details>
 <summary>How to submit PR</summary>
 
-1. Fork the repository and create a new branch for your feature or bug fix.
+1. Fork the repository and create a new branch from the `main` branch for your feature or bug fix.
 2. Make your changes and commit them with descriptive commit messages.
 3. Push your changes to your forked repository.
-4. Open a new pull request against the main repository, describing your changes in detail.
-</details>
-
-
-### Coding Style
-We adhere to the [Solidity Style Guide](https://docs.soliditylang.org/en/latest/style-guide.html) for maintaining a consistent and readable codebase. When contributing to this project, please follow the Solidity Style Guide with the exceptions and additions.
+4. Open a new pull request against the `main` branch of the main repository, describing your changes in detail.
+5. Ensure your branch is up to date with the `main` branch before requesting a review.
+6. Address any review comments and make necessary changes.
+7. Once approved, the PR will be merged into the `main` branch.
 
-To ensure consistent formatting, we use [forge fmt](https://book.getfoundry.sh/reference/forge/forge-fmt), a built-in code formatter for Foundry projects. Please run `forge fmt` before submitting your pull request. Our CI pipeline will check the formatting of your code using `forge fmt --check`.
+</details>
 
 
-### Release Process
-This document outlines the release process for our project, including the types of releases, planning, preparation, execution.
+### Documentation Style and Format
 
-- **Major Release**: Includes significant new features or backward-incompatible changes.
-- **Minor Release**: Includes small new features or improvements.
-- **Patch Release**: Includes bug fixes and backward-compatible changes.
+- Follow the Markdown formatting guidelines as outlined in the [Documentation Guidelines](https://mc-book.ecdysis.xyz/guides/project-management/documentation-guidelines).
+- Use kebab-case for all documentation file names.
 
-#### 1. Create a release branch
-A new release branch is created from the main branch, using the naming convention `release/vX.Y.Z`, where `X.Y.Z` represents the version number.
+### Coding Style
 
-- Major/Minor Release
-  1. Create a "New Release" issue to clarify the release plan.
-  2. Create a release branch.
-  3. Review and merge related Pull Requests into the release branch.
-- Patch Releases
-  1. Review a related Pull Request.
-  2. A maintainer creates a patch release branch.
-  3. Merge into the patch release branch.
-  - Individual Pull Requests can be merged on an ongoing basis.
-  - Combine multiple PRs into a single _Patch Release Brabch_ if needed.
-  - For critical patches, a "New Release" issue may be created, but generally, a lightweight process will be followed.
+- Adhere to the [Solidity Style Guide](https://docs.soliditylang.org/en/latest/style-guide.html) with project-specific additions as outlined in the [Coding Standards](https://mc-book.ecdysis.xyz/guides/project-management/coding-standards).
+- Use `forge fmt` for consistent code formatting.
 
-  [*] If necessary, create branch and validate a Release Candidate (RC).
+### Test Strategy
 
-#### 2. Preparation
-  1. Update the [CAHNGELOG](./CHANGELOG.md).
-  2. [Create release notes](https://github.com/metacontract/mc/releases/new).
-  3. A new git tag is created and chosen for the release, using the naming convention `vX.Y.Z`.
+- Follow the comprehensive test strategy outlined in the [Test Strategy](https://mc-book.ecdysis.xyz/guides/project-management/test-strategy).
+- Write unit tests for all functions and ensure high code coverage.
 
-#### 3. Publication
-  1. Publish release notes.
-  2. Announce the release to the community through our designated communication channels.
-  3. For information about upcoming releases and planned features, please refer to our [GitHub Issues](https://github.com/metacontract/mc/issues).
+### Release Process
 
-Please note that only project maintainers have the authority to create releases and merge changes into the main branch.
+- Follow the branching and release strategy as outlined in the [Branching and Release Strategy](https://mc-book.ecdysis.xyz/guides/project-management/branching-and-release-strategy).
+- Use Semantic Versioning for all releases.
 
 
 ### Versioning Policy
+
 This project follows [Semantic Versioning](https://semver.org/) and uses version numbers in the format _MAJOR.MINOR.PATCH_.
 - Version number updates will be determined and applied by the assigned maintainer(s).
 
 * For the initial v0.1.0 release, we expect to make frequent breaking changes.
 
 ### Changelog
+
 A changelog will be maintained in [CHANGELOG.md](./CHANGELOG.md) to document all notable changes in each version.
 
 - Changelog entries should follow the [Keep a Changelog](https://keepachangelog.com/) format.

README.md

@@ -1,51 +1,61 @@
-# Meta Contract
-A meta contract is a powerful framework for smart contract development, designed to enhance developer productivity and contract maintainability. Built on the principles of the *ERC-7546: UCS* (Upgradeable Clone Standard), this ***mc*** library provides a robust architecture for creating and managing upgradeable smart contracts.
+# Meta Contract ![Solidity][solidity-shield] [![License:MIT][license-shield]](./LICENSE)
+<!-- [![CI][ci-shield]][ci-url] -->
+
+[solidity-shield]: https://img.shields.io/badge/Built_with-Solidity-rgb(85,84,217)
+[license-shield]: https://img.shields.io/badge/license-MIT-blue.svg
+[ci-shield]: https://img.shields.io/github/actions/workflow/status/metacontract/mc/ci.yml?branch=main&label=build
+[ci-url]: https://github.com/metacontract/mc/actions/workflows/ci.yml
+
+Meta Contract is a Foundry-based smart contract framework designed to create flexible, upgradeable, and scalable blockchain applications. It implements the UCS ([ERC-7546: Upgradeable Clone for Scalable Contracts](https://eips.ethereum.org/EIPS/eip-7546)) architecture, providing developers with powerful tools to build and maintain complex decentralized systems.
 
 > [!WARNING]
-> This is an alpha release of the Meta Contract (mc) library, which means it is an early version intended for testing and feedback purposes. Please be cautious when using this version in production environments, as it may contain bugs, incomplete features, or unexpected behavior.
+> This is still in the development version, which means it is an early version intended for testing and feedback purposes. Please be cautious when using this version in production environments, as it may contain bugs, incomplete features, or unexpected behavior.
 
 ## Features
-- **Upgradeable Contracts**: Create smart contracts that can be easily upgraded, allowing for continuous improvement and bug fixes without contract migration.
-- **Modular Design**: A meta contract promotes a modular approach to contract development, enabling code reuse and reducing complexity.
-- **Standard Functions**: Utilize a rich library of standard functions to streamline contract development and ensure consistency across your projects.
-- **Development Kit**: Leverage the mc's Development Kit (DevKit) to simplify contract deployment, testing, and interaction.
-- **Comprehensive Documentation**: Benefit from extensive documentation and guides to help you get started and make the most of mc's features.
+
+- **Upgradeability**: Meta Contracts can be upgraded without changing their address, allowing for seamless improvements and bug fixes.
+- **Modularity**: The framework separates contract logic into distinct, manageable components, enhancing code organization and reusability.
+- **Scalability**: Meta Contracts are designed to handle growth efficiently, making them suitable for large-scale applications.
+- **Flexibility**: Developers can easily extend and customize Meta Contracts to suit specific project needs.
+- **Testability**: The modular structure of Meta Contracts facilitates comprehensive testing, including unit tests for individual functions and integration tests for the entire system.
 
 ## Getting Started
+
 ### Prerequisites
-To use mc, you need to have the following software installed:
-- [Foundry](https://github.com/foundry-rs/foundry) - a blazing fast, portable and modular toolkit for Ethereum application development.
 
-### Installation
-The mc can be installed using Foundry's `forge` command with useful template:
+To use mc, you need to have [Foundry](https://github.com/foundry-rs/foundry) installed.
+
+### Quick Start
+
+Just run this:
 
-```sh
+```bash
 forge init <Your Project Name> -t metacontract/template
 ```
 
-You can also install only this repository at your project root using:
-```sh
-forge install metacontract/mc
+After the installation, run the following command to test the _Counter_ sample project and see how it works:
+
+```bash
+cd <Your Project Name>
+forge test
 ```
 
+If you want to learn more about meta contract installation, please refer to [installation guide](https://mc-book.ecdysis.xyz/guides/setup/installation).
+
 ## Documentation
-The [MC Book](https://mc-book.ecdysis.xyz/) serves as a comprehensive guide for developing with the meta contract. It covers a wide range of topics, including:
-- Architecture overview
-- Setting up your development environment
-- Creating and deploying upgradeable contracts
-- Using standard functions and libraries
-- Testing and debugging your contracts
-- Best practices and guidelines
-You can find the source code for the MC Book on GitHub at [metacontract/book](https://github.com/metacontract/book).
+
+The [MC Book](https://mc-book.ecdysis.xyz/) serves as a comprehensive guide for developing with the meta contract. Also, you can find the markdown documents in [docs](./site/docs) directory.
 
 ## Contributing
+
 We welcome contributions from the community! If you'd like to contribute to mc, please check out our [Contributing Guide](./CONTRIBUTING.md) for detailed instructions on how to:
 - Report issues and bugs
 - Submit feature requests
 - Create pull requests
-- Follow our coding style and guidelines
+- Follow our [project management guidelines](https://mc-book.ecdysis.xyz/guides/project-management)
 - Participate in discussions and decision-making
-We appreciate your help in making mc even better!
+
+We appreciate your help in making meta contract even better!
 
 ## License
-This mc is released under the [MIT License](./LICENSE).
+This meta contract is released under the [MIT License](./LICENSE).