You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is also migration code there which can be used in a runtime upgrade to migrate over the old forum state to the new one. Lastly, there is some benchmarking code that attempts to measure how much time a given machine would take to run a migration on a forum of a given size. It has been used to make sure that the migration portion of the runtime upgrade could safely be executed.
Goals
Here are the goals for this project, in order of execution. Notice that all the work after point 5. is about the non-runtime work of fully putting the forum in production. It's not yet clear how far we should go down that path, as it effectively makes the project into a full network release that probably requires the input of other team members for timely completion.
Introduce the new forum code into the monorepo, while preserving its commit history.
Augment the forum to get rid of technical debt and make it compatible with the new working group system. This will require updating unit tests and the migration code. Read here Forum tech debt + cleanup #766.
Introduce proper module documentation.
Introduce the forum module into the runtime.
Introduce a working group for the forum in the runtime, and integrate it with the forum.
<-- non-runtime work below -->
Update the Joystream/types typescript library to allow off-chain typescript apps to talk to the new full node.
Update the CLI to allow it to work with the forum working group.
Update the CLI to allow it to be used by moderators
lead can manipulate moderator assignment to categories
lead can create categories (or could moderators also do this?)
moderators can delete posts
moderators can archive threads
moderators can delete threads
Update the network integration testing to also cover basic user and moderator actions on the forum.
Write a runtime upgrade scenario, with forum migration, into the network integration testing.
Write query node schemas for the 2.0 forum: most important improvement is representing full history on all objects: who edited/removed/created/.. what+when.
Update the Pioneer experience to expose new forum functionality and use the query node.
Workflow
We will follow the current Joystream branching model
This means a new working branch for this project will be created, called forum_2, which will branch from the current development branch. All improvements should come in the form of pull requests targeting this branch from forked repos. All PRs must have a well-defined scope, and features should be broken down into PRs with minimal coherent scope. Any changes requested to a PR must be made in that PR not in any other open or future PR, unless explicitly agreed upon. Lastly, any PR open should, prior to the review being requested, be rebased on top of the current forum_2 branch.
We will routinely, and depending on what ends up being the final path for this work to go into production, pull changes from development, master, or other feature/network branches into forum_2.
The text was updated successfully, but these errors were encountered:
Background
We have a completed version of a new set of forum functionalities in the
development
branch of this repohttps://github.com/Joystream/substrate-forum-module
There is also migration code there which can be used in a runtime upgrade to migrate over the old forum state to the new one. Lastly, there is some benchmarking code that attempts to measure how much time a given machine would take to run a migration on a forum of a given size. It has been used to make sure that the migration portion of the runtime upgrade could safely be executed.
Goals
Here are the goals for this project, in order of execution. Notice that all the work after point 5. is about the non-runtime work of fully putting the forum in production. It's not yet clear how far we should go down that path, as it effectively makes the project into a full network release that probably requires the input of other team members for timely completion.
<-- non-runtime work below -->
Workflow
We will follow the current Joystream branching model
#638
This means a new working branch for this project will be created, called
forum_2
, which will branch from the currentdevelopment
branch. All improvements should come in the form of pull requests targeting this branch from forked repos. All PRs must have a well-defined scope, and features should be broken down into PRs with minimal coherent scope. Any changes requested to a PR must be made in that PR not in any other open or future PR, unless explicitly agreed upon. Lastly, any PR open should, prior to the review being requested, be rebased on top of the currentforum_2
branch.We will routinely, and depending on what ends up being the final path for this work to go into production, pull changes from
development
,master
, or other feature/network branches intoforum_2
.The text was updated successfully, but these errors were encountered: