Recent updates:

• Continued handling PRs (great work especially by @oxarbitrage)
• Updated seed nodes based on reports in seed node thread (https://bitsharestalk.org/index.php/topic,23715.0.html)
• Cleaned up README (https://github.com/bitshares/bitshares-core#bitshares-core)

Perhaps you didn't see it, but if you have what is your objection to keeping the current SMF forum, locking it down into a read only state, and moving ONLY the user accounts over to Discourse? This was DataSecurityNode's suggestion and I believe it has great merit. I agree that re-registration should not be required. Migrating user accounts will be far easier (tho issues could arise) than then entire forum content.

I think a managed host path should be investigated as well. Even if the costs were not prohibitive I still think we should ONLY migrate user accounts and lock down this SMF forum in a read only state. Although the user base is much larger, I manage an SMF forum myself, and it is not a heavy resource intensive application. It would be worth checking into whether the Discourse hosting might also include hosting for this SMF forum as well. If not I still believe it should be preserved as is in a read only state.

A read only state also reduces the maintenance requirements. As long as a full backup is preserved, and that could be done by several trusted users, should the forum be corrupted or compromised it could be restored from a backup fairly quickly, and speed wouldn't really be an issue in doing so anyway, given it is only a reference library.

Migrating the SMF threads will be wrought with problems and take a significant effort. There are likely to be complications and incompatibilities. All of that can be avoided by just providing access to this SMF from Discourse as a reference.

I don't have a strong objection, I guess I just have a preference to minimize discontinuity if feasible. For example, I like to look at people's post history on here, but that chain gets broken if not migrated.

I'm willing to leave it up to whomever ends up in charge though. As long as a read-only version remains reliably accessible and searchable then I think that could be okay. I agree it's important that at least the user accounts be migrated (I wonder how smoothly that can be done--would it require a password reset?) The old forum would also need to be clearly marked that it has been deprecated so that anyone looking will know to move to the new forum for discussion.

I'm no expert in forum software (and related) maintenance and operations nor do I want to be, so if it were me I would go with managed hosting--but again I think this can also be at the discretion of whoever is in charge and their skillset.

Quote

As discussed with Fuzzy, I personally think a group solution for hosting the forum is making the subject unnecessary complex. I would prefer that one trusted active community member is in charge of the forum. That would make it easy in terms of the responsibilities, who to contact and also who is in charge to fix something in case of a problem. I prefer to keep things simple.

How simple will it be if that person can't fulfill their responsibility due to unforeseen circumstances?

No, I think the best model is worker for hosting / server costs, several trusted community members with admin rights. If one admin can't do the job or heaven forbid gets hit by a bus, there are 1 or 2 more that can pick up the slack. I would prefer a primary admin and 2 backup admins.

I do agree with you tho that we probably shouldn't count on buy.org. I like the idea of a blockchain based forum but it may be too much to ask of it to meed our needs upon launch.

I also think that anything we can do to improve communications with the east should be given priority.

I tend to agree along these lines--and my vote is for either stick with SMF or migrate all current content to Discourse--as decided by whomever takes over management and their skills/preferences for managing and maintaining the website operations.

I am not a fan of less established or experimental software (i.e. anything blockchain based) for something as important as the forum. I am also not a fan of anything that has any more friction than necessary for lurking/participating (https://bitsharestalk.org/index.php/topic,23705.msg302021.html#msg302021).

To be clear, I am assuming whoever takes over will have full control over the domain name, the forum server software + database, and any additional software like an SMTP server for sending emails.

If sticking with SMF, it's important that it be kept up to date for security purposes (we are currently several versions behind). This is also the least surprising path since there is unlikely to be any outcry for keeping things as-is.

If moving to Discourse, I think it is important that all threads and user accounts be migrated. If everyone had to re-register, then that could kill the forum. Performing such a migration manually seems non-trivial though: here it says https://meta.discourse.org/t/migrating-to-discourse-from-another-forum-software/16616 it requires manual review and editing of the migration script, which is a complex script (https://github.com/discourse/discourse/blob/master/script/import_scripts/smf2.rb). The best bet for a migration (and possibly ongoing operations/maintenance) may be a managed hosting solution (https://meta.discourse.org/t/what-are-some-reputable-managed-discourse-hosting-providers-out-there/54702) like https://www.discoursehosting.com/pricing/ or https://payments.discourse.org/buy/ which also will do the migration for you (eg https://meta.discourse.org/t/discoursehosting-migration-service-for-your-existing-forum/12201). Self-hosting could be done on something like Digital Ocean (https://www.digitalocean.com/community/tutorials/how-to-use-the-discourse-one-click-application-on-digitalocean) but it would still require a complex manual migration and at least an SMTP server for sending emails.

Seems to somewhat regularly go temporarily offline with that error

I've gone ahead and made the following changes on GitHub:

• Renamed https://github.com/bitshares/bitshares-2 into https://github.com/bitshares/bitshares-core
• Moved all the issues from https://github.com/cryptonomex/graphene into https://github.com/bitshares/bitshares-core
• Closed many old issues
• Updated git submodule remotes to point to bitshares forks instead of cryptonomex forks (defined here https://github.com/bitshares/bitshares-core/blob/master/.gitmodules)
• Changed default bitshares-core branch from bitshares to master

Active developers should update their local git configurations to reflect the new repository remote URL, submodule remote URLs, and default branch. People just building from source can maybe just re-clone if they want to make it easy. Be careful not to unintentionally delete wallets, blockchain databases, or other files if you decide to reclone.

Active developers and those building from source can update their submodule remote URLs using "git submodule sync --recursive".

I'd like some developer feedback on reorganizing the GitHub repositories.

For the most part the https://github.com/cryptonomex/ organization seems to be no longer maintained. Specifically there is no one that is maintaining issues and pull requests in https://github.com/cryptonomex/graphene and https://github.com/cryptonomex/fc. @svk is still maintaining https://github.com/cryptonomex/graphene-ui but I think there is a possibility he will be abandoning it soon based on his approved worker proposal here: https://bitsharestalk.org/index.php/topic,23645.0.html

I've already started a new fc fork here https://github.com/bitshares/bitshares-fc which merges all applicable updates and pull requests from https://github.com/cryptonomex/fc and https://github.com/steemit/fc. BitShares will use the bitshares-fc fork moving forward.

I'd like to propose a merge of https://github.com/cryptonomex/graphene and https://github.com/bitshares/bitshares-2. The main reasons for doing so would be to bring the issue tracker into the BitShares organization where myself and other BitShares developers can maintain it, and also to avoid confusion about which of multiple issue trackers and forks BitShares users and contributors should work with.

Due to the way GitHub works, in practice such a merge would essentially involve deleting the current bitshares-2 repository, moving and renaming the graphene repository to take its place, and then restoring all missing branches, tags, and releases from the previous bitshares-2 repository into the new one.

This would also effectively mean that BitShares would become the "reference" Graphene implementation and there would be no more "pure" Graphene project. I think this would be fine, because it can be seen from the current diff between graphene and bitshares-2 at https://github.com/cryptonomex/graphene/compare/master...bitshares:bitshares?w=1 that Graphene already contains "hardfork" code as though it were already part of BitShares, and that it is already missing a number of patches that BitShares contains since nobody is maintaining it. If desired, somebody could maintain a branch downstream of BitShares that removes hardforking code, etc. that would represent a clean Graphene. I would likely do this to begin with as there are still differences for example in the testing infrastructure in Graphene vs BitShares which still need to be fixed.

Performing such a merge would also require agreement from Cryptonomex, whom I cannot speak for. If they do not want to do this or it is otherwise undesirable, an alternative would be to use the https://github-issue-mover.appspot.com/ tool to copy all issues from the graphene repo into the bitshares-2 repo. This would still leave the upstream Graphene repo and issue tracker in place though, which could still be confusing for users and contributors. It could be a reasonable middle ground if perhaps the upstream graphene issue tracker was disabled afterwards to help avoid confusion.

Any thoughts are appreciated.

@abit @dannotestein @kenCode @svk @xeroc

Locking this thread and continuing discussion here: https://bitsharestalk.org/index.php/topic,23715.0.html