Re: [Snowdrift-discuss] steps that lead to working mechanism
On 03/01/2016 12:44 PM, Bryan Richter wrote: > On Tue, Mar 01, 2016 at 12:16:22PM -0800, Aaron Wolf wrote: >> >> So, I have a bigger concern to make sure we consider: Lots of things >> currently reference user id such as links for sponsors and elsewhere >> including CiviCRM. There are some reasons to dislike the way the >> arbitrary id numbers are used compared to other options, but it may >> just be the most sensible. >> >> So, as we rebuild via a dev reimplemention, I want us to either use >> the *same* user list (i.e. migrate it over, question being how to >> deal with sync issues going forward) > > I believe I addressed this. Part of the reason we are keeping the old > site around is because all the data relating to users is, in fact, > valuable. When the time comes, it will be migrated or incorporated > appropriately. > >> ... make it clear that the dev thing is just testing and may get >> periodically wiped and that the main site is still the real one for >> now, > > This is why the plan is to operate the new site under > "dev.snowdrift.coop". > >> >> So, I imagine we end up with a nice working site that has a clean >> database with no users or anything and only the core functions we >> need or at least things separated into subsites adequately etc. We >> make all the cleanest decisions we can, like the table being "users" >> instead of "user" for example, maybe the newer environment >> variables, certainly the best newest auth stuff and no Persona >> anything… and then once we're comfortable with that, we do a >> migration where we copy over the users from the main site keeping >> the old database for reference but migrating only the columns that >> still apply to the new updated site. >> >> The significant thing here is keeping the users and their id >> numbers. I know there's a way to migrate the auth hash stuff so that >> we move to the stronger newer hashing… Anyway, we don't need to >> handle every aspect of this right away, just need the plan to be >> clear. > > Don't worry about these things right now. > Okay sounds good. The only reason I felt concerned was because I'm *okay* with losing some data such as precise wiki version history (not that I *want* to lose it, but I don't want preservation to get in the way of more important progress). So, I know that the overall data is understood as valuable, I just wanted to make it clear that the particular user ids actually matter, whereas the id of the snowdrift project, for example, can change because we refer to it by "snowdrift" and never by it's database id. So the user id specifically seemed a non-obvious thing to point out as a concern. I'll not worry about this further. I definitely support the proposed direction and would be happy to see it push forward ASAP. signature.asc Description: OpenPGP digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] steps that lead to working mechanism
On Tue, Mar 01, 2016 at 12:16:22PM -0800, Aaron Wolf wrote: > > So, I have a bigger concern to make sure we consider: Lots of things > currently reference user id such as links for sponsors and elsewhere > including CiviCRM. There are some reasons to dislike the way the > arbitrary id numbers are used compared to other options, but it may > just be the most sensible. > > So, as we rebuild via a dev reimplemention, I want us to either use > the *same* user list (i.e. migrate it over, question being how to > deal with sync issues going forward) I believe I addressed this. Part of the reason we are keeping the old site around is because all the data relating to users is, in fact, valuable. When the time comes, it will be migrated or incorporated appropriately. > ... make it clear that the dev thing is just testing and may get > periodically wiped and that the main site is still the real one for > now, This is why the plan is to operate the new site under "dev.snowdrift.coop". > > So, I imagine we end up with a nice working site that has a clean > database with no users or anything and only the core functions we > need or at least things separated into subsites adequately etc. We > make all the cleanest decisions we can, like the table being "users" > instead of "user" for example, maybe the newer environment > variables, certainly the best newest auth stuff and no Persona > anything… and then once we're comfortable with that, we do a > migration where we copy over the users from the main site keeping > the old database for reference but migrating only the columns that > still apply to the new updated site. > > The significant thing here is keeping the users and their id > numbers. I know there's a way to migrate the auth hash stuff so that > we move to the stronger newer hashing… Anyway, we don't need to > handle every aspect of this right away, just need the plan to be > clear. Don't worry about these things right now. signature.asc Description: Digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] steps that lead to working mechanism
On 03/01/2016 10:52 AM, Bryan Richter wrote: > On Tue, Mar 01, 2016 at 10:17:33AM -0800, Aaron Wolf wrote: >> >> For one thing, I insist that the full launch of MVP (which is not at >> the beginning of the process strictly) include some form of the >> establishment process with the honor pledge as part of keeping our >> dedication to safe, respectable community space front-and-center, >> even if we don't have moderation integrated in all places. > > Indeed. Users/Establishment/CoC is not on the list because, as far as > I know, it's mostly complete. It's also simple enough to not > necessarily need a total rewrite. Its status will be verified after > step #4. > > Note that with no wiki or discussion, there will be very little to > moderate programatically, although the establishment process will > still be necessary. > Right. So, I have a bigger concern to make sure we consider: Lots of things currently reference user id such as links for sponsors and elsewhere including CiviCRM. There are some reasons to dislike the way the arbitrary id numbers are used compared to other options, but it may just be the most sensible. So, as we rebuild via a dev reimplemention, I want us to either use the *same* user list (i.e. migrate it over, question being how to deal with sync issues going forward) or make it clear that the dev thing is just testing and may get periodically wiped and that the main site is still the real one for now, until a time we switch things over. I would lean toward the latter option. So, I imagine we end up with a nice working site that has a clean database with no users or anything and only the core functions we need or at least things separated into subsites adequately etc. We make all the cleanest decisions we can, like the table being "users" instead of "user" for example, maybe the newer environment variables, certainly the best newest auth stuff and no Persona anything… and then once we're comfortable with that, we do a migration where we copy over the users from the main site keeping the old database for reference but migrating only the columns that still apply to the new updated site. The significant thing here is keeping the users and their id numbers. I know there's a way to migrate the auth hash stuff so that we move to the stronger newer hashing… Anyway, we don't need to handle every aspect of this right away, just need the plan to be clear. signature.asc Description: OpenPGP digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] steps that lead to working mechanism
On Tue, Mar 01, 2016 at 10:17:33AM -0800, Aaron Wolf wrote: > > For one thing, I insist that the full launch of MVP (which is not at > the beginning of the process strictly) include some form of the > establishment process with the honor pledge as part of keeping our > dedication to safe, respectable community space front-and-center, > even if we don't have moderation integrated in all places. Indeed. Users/Establishment/CoC is not on the list because, as far as I know, it's mostly complete. It's also simple enough to not necessarily need a total rewrite. Its status will be verified after step #4. Note that with no wiki or discussion, there will be very little to moderate programatically, although the establishment process will still be necessary. signature.asc Description: Digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] steps that lead to working mechanism
On 03/01/2016 10:08 AM, Bryan Richter wrote: > We've made some progress on concretely defining the goal for MVP, but > there's a gulf between our current situation and that goal. > > Here is the shortest path to a working mechanism including > notifications. > > 1. Begin hosting a new version of the site at dev.snowdrift.coop >with a fresh database. > 2. Remove wiki and discussions* > 3. Remove prototype code > - Events > - Notifications > - EmailDaemon > 4. Take stock of remaining components > - Identify them > - Can we cut any more fat? > - What % completion is each component? > > ** Things start getting fuzzy here. Make new plan after #4. > > 5. Refactor web pages away from the "alpha sprint" mess > - Use a single defaultLayout > - Deal with Handler/NewDesign.hs (shouldn't exist) > - Document deficiencies of the page-authoring framework > including of the CSS framework and page-test framework > 6. Refactor the page-writing framework > - Document it > 7. Integrate the mechanism library > 8. Rewrite and integrate an events library > 9. Rewrite and integrate a notifications library > - Including email notifications > > * Step #1 only exists since there is still valuable content in the > wiki, discussions, and user profiles. The old site would stay > live until that data can be migrated to new homes. > > Discussion is appreciated. > This all seems sensible to me. After MVP, I could see the migration of wiki data happening by adding Gitit2 and then just moving the data over, we tweak that until we have it working smoothly, ideally styled acceptably and sharing auth info. It uses Pandoc anyway. But the thing is, it would be separate sub-site. For migration of discussion stuff, that's a bit more complex. Once refactored enough to be separate subsite, we can then figure out that whole situation. I understand we won't get to it right away. We can link from the dev site to the original site in select places, losing type-safe URLs unfortunately, or make other decisions. For one thing, I insist that the full launch of MVP (which is not at the beginning of the process strictly) include some form of the establishment process with the honor pledge as part of keeping our dedication to safe, respectable community space front-and-center, even if we don't have moderation integrated in all places. In other words, all newcomers need to know that we have these values and a written Code of Conduct that is used to address any concerns that may arise. So, in general, I support this start-fresh and migrate as we can to build up the core foundation for launch. Cheers, Aaron signature.asc Description: OpenPGP digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
[Snowdrift-discuss] steps that lead to working mechanism
We've made some progress on concretely defining the goal for MVP, but there's a gulf between our current situation and that goal. Here is the shortest path to a working mechanism including notifications. 1. Begin hosting a new version of the site at dev.snowdrift.coop with a fresh database. 2. Remove wiki and discussions* 3. Remove prototype code - Events - Notifications - EmailDaemon 4. Take stock of remaining components - Identify them - Can we cut any more fat? - What % completion is each component? ** Things start getting fuzzy here. Make new plan after #4. 5. Refactor web pages away from the "alpha sprint" mess - Use a single defaultLayout - Deal with Handler/NewDesign.hs (shouldn't exist) - Document deficiencies of the page-authoring framework including of the CSS framework and page-test framework 6. Refactor the page-writing framework - Document it 7. Integrate the mechanism library 8. Rewrite and integrate an events library 9. Rewrite and integrate a notifications library - Including email notifications * Step #1 only exists since there is still valuable content in the wiki, discussions, and user profiles. The old site would stay live until that data can be migrated to new homes. Discussion is appreciated. signature.asc Description: Digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
