Updating Readme and Contributing files

CONTRIBUTING.md

@@ -9,7 +9,7 @@ We warmly welcome contributions from the community. Whether you're fixing bugs,
 
 ## Submit Your Code
 
-1. If you have working code to implement your idea, please submit a Pull Request (PR) **to the develop branch**.
+1. If you have working code to implement your idea, please submit a Pull Request (PR) **to the develop branch** from your fork.
 2. Ensure that your code follows the PHP and WP coding standards and has passed all the GitHub Actions checks.
 3. Your PR should have corresponding discussions post with at least 2 additional thumbs up for it to be merged.
 
@@ -19,6 +19,25 @@ We warmly welcome contributions from the community. Whether you're fixing bugs,
 2. **Autoloading:** We utilize Composer's `classmap` autoloading for efficient class loading. We use `classmap` over `psr4` so the WordPress naming standards can be fulfilled.
 3. **Versioning:** We adhere to [Semantic Versioning](https://semver.org/) for a clear and predictable versioning scheme.
 4. **Changelog:** We maintain a changelog for our project following the [Keep A Changelog](https://keepachangelog.com/en/1.0.0/) standards.
+5. We follow the [PHP Package Development Standards](http://php-pds.com) for file and folder structures and naming.
+
+## Development flow
+
+When a release is made, our GitHub workflows automatically will build the autoloader and add dependencies declared in the composer.json file.
+If you are to add new dependencies, or want to build the autoloader locally, you need composer.
+- `composer install`
+
+Note that all autoload classes from the main plugin will be autoloaded from `$base_dir/src/src` when you build locally.
+Manually replace `/src/src` to `/src/` if you want to test the plugin prior to pushing.
+
+If you are cloning this repo, or a fork of this repo locally, and want to run some of the tests we run on the repo, and ensure your code will pass, you can follow these steps:
+
+- install PHPUnit `composer require --dev phpunit/phpunit:^9.0`
+- install [WP Unit Tests](https://make.wordpress.org/core/handbook/testing/automated-testing/phpunit/) 
+- edit phpunit.xml file adequately
+- install WPCS (Standard: WordPress)
+
+_Any of the above steps are optional but highly recommended_
 
 ## Special Cases
 
@@ -33,12 +52,4 @@ If you’re interested in writing any documentation or creating tutorials please
 - Join the ongoing discussions to stay updated with the latest proposals and the roadmap.
 - Feel free to reach out to the maintainers for any queries.
 
-Your contributions help make Better WordPress Plugin Boilerplate better. Together, let's build a robust, modern, and community-driven boilerplate for WordPress and ClassicPress plugin development!
-
-```
-- install PHPUnit () composer require --dev phpunit/phpunit:^9.0
-- install WP Unit Tests https://make.wordpress.org/core/handbook/testing/automated-testing/phpunit/
-- edit phpunit.xml file 
-- install WPCS (Stnadard: WordPress)
-- install composer
-```
+Your contributions help make Better WordPress Plugin Boilerplate better. Together, let's build a robust, modern, and community-driven boilerplate for WordPress and ClassicPress plugin development!

README.md

@@ -34,6 +34,27 @@ This repository is not a Plugin you can download and install. The Plugin files i
 
 For detailed documentation on the Plugin usage and Development processes, please refer to the [Wiki](https://github.com/TukuToi/better-wp-plugin-boilerplate/wiki).
 
+_Until Wiki is online_
+- to manage and release a plugin with this repo/clone of
+    - clone/fork this entire repo
+	- your _plugin_ will be whatever is inside the root `src` folder. The rest of the root content is NOT part of your plugin, but part of your dev env and workflow
+    - develop your plugin by making changes to anything inside the root `src` folder
+	- if you need other dependencies add them to the composer file, remove composer lock, and run `composer install`
+	- push any changes you make to your `develop` branch
+	- this will trigger the wpcs and phpunit workflows, which when passed, allow you to
+	- merge your changes to your release branch (typicall `main`)
+	- then checkout `main` locally, switch to that branch, and in the CLI run the interactive `/bin/git_release.sh` script
+	- this will prompt you a few details and then release your _plugin_ to a new Tag, where an asset will be added that holds your built _plugin_
+
+==> You do NOT need to zip things manually, or run autoloader locally, as the workflows will do that all for you
+
+==> IF you run autoloader manually locally to maybe test your plugin, keep in mind to search-replace the `/src/src/` > `/src/` in the `/src/vendor/composer` files to guarantee no errors. _This step is done for you if you use the release workflow_.
+
+
+Of course, if this is all too much for you, feel free to just extract `src` contents and use that as your repo, this is entirely up to you.
+
+==> `/bin` includes other helpful scripts to generate documentation of your _plugin_ as well as convert documents from a to another format
+
 # Credits
 
 *This credits section is only here to honor the origins of the repository, as it is a hard-fork. The code has been 100% rewamped from the original.*