Symphony.

Don't know what of this is already thought about and planned for the upcoming new site, but just to be sure, here are my most recent ramblings on documentation...

@designermonkey, thanks! I agree, this is a great learning opportunity for anyone who wants to get involved.

@jensscherbl, this effort is all about improving the Symphony documentation. I was supposed to be heading up the Documentation Working Group, but life and work got in the way. Which is why I quit my job to be able to dedicate more time to this.

The effort to document the development process has been slowing things down, but I actually think that is the most important part, so I'm trying to make sure that everyone can learn from this project, like a case study on the creative, technological and collaborative process involved in building the site.

@s_e, it would be great to start on the parts of the site that have already been worked out in the Symphony Factory design. We will eventually need a development server that we can use as the canonical reference for the state of the database. Or we my need to assign structural changes to be handled by a single individual. Otherwise, we will need to shift to working with the CDI or DB Sync extension.

• First, get comfortable with how the XSL templates have been designed and see if you can apply the existing Factory designs to the main pages.
• Meanwhile, work can be happening to figure out what the rest of the layouts should look like.
• A separate site will deal with authentication, so that the Members extension can be integrated to manage user profiles.
• The Discussions section can be started, building sections and fields to manage posts.
• JavaScript needs to be integrated to display showcase items, either as a list of text entries or as a gallery of thumbnails.
• I can sanitize some of the XML being used by the current site to use as temporary data sources for the various sections to try out XSLT templates.

If there is an area that you are particularly interested in, let me know and I'll make a list of tasks we need for that section. Documentation would be a great place to start. We should probably create a separate repository for each subdomain. Try modifying the existing Ensemble to create a docs.getsymphony.dev site on your localhost, then modify the pages to match the proposed site structure. See how well the existing content is able to port into the Factory design.

If you need anything, just ask. The best thing to do at this point is to fork the repository and start messing around with it. If you have some good ideas, just send a pull request.

@bauhouse I'd like to put something into this but i'm quite busy at the moment... job + masters & bunch of other stuff going on.

I've noticed you mentioned you need to sync work; with both CDI & dbsync mentioned. I've worked on a multi-dev version of the CDI. Basically works like stanard CDI, except that it logs all your queries in DB even if you are running a master instance. Additionally the json is better formatted; so you can actually see the queries. I've tried with the last update on friday with 2 devs and seems like it works fine probably you can give it a shot would be worth using in multi dev environments.

Also if there's some stuff I can do with XSLT (as long as not too time-consuming would be good) a task list / issues of things to be tackled would be nice. so maybe people can take ownership of small things which will be joined into one big task.

Currently working on a beast of a multilingual ensamble myself (for work purposes) so I'm sure there are things I'm working on that would be useful to the community.

Dividing Up the Work

I have started a list of issues on the GitHub repository. I have tagged them to categorize the work into the following types of tasks:

• api
• data
• design
• development
• xslt

@gunglien, thanks for your offer to help! It may be a little early to try out the multi-dev version of the CDI extension, but I would definitely like to try it out. You may need to walk me through the process, as I really haven't had the opportunity to work in a multi-dev environment.

To be honest, it may even be a little early to start work on XSLT, since the data modelling work has not been started and there isn't any data to work with yet. But, if you need data, we can start by faking it, based on what we already have on this site.

Feel free to add to what I've started.

Great at least now there's a list to tackle.

I could contribute to the other things; but since I don't have plenty of time doing data modelling; would require more comprehensive views and probably time.

As for the CDI I could walk you through it; there might be some implications in relation do database offsets etc so we might need to know how many people are working on it.

Quick Question; I assume we're just sticking to everything being in english no translations etc for the different parts of the Symphony Network sites; Only regional sites which are separate would be translated correct?

Stephen,

Would it be possible to have a chat over Skype, Google Hangout, IRC or IM at some point? I have many questions about the workflow, practices and conventions we'd like to use when fleshing this out. Also might need a hand with some git-fu as it'd be my first time using it "properly" for collaborative development! At the moment my workflow is pretty haphazard as I work solo and approach things slightly differently every project.

I know a lot of this is fleshed out in the excellent and extensive documentation you've already provided but there's a lot to take in so a bit of real time conversation would be a boon to me to clarify everything.

@s_e, I would be happy to chat with you. You can reach me on Google+

@gunglien, it would be great to have a walk through of the steps to integrate CDI into the process. Thank you!

Yes, as far as I know, we will be sticking to English-only for the community site. Each language-specific/regional site would use their own instance of the Symphony Network site.

@bauhouse, great give me a couple of days working on a new-set of sites for work and will be actively collaborating with a colleague of mine. Where I plan to use the CDI two-way. So I can be sure there are no glitches cos otherwise might be a bit messy.

Then we can schedule a time where I could probably come online and walk-through it. Would also be good to write for documentation purposes.

Would also be good to write for documentation purposes.

Please do so. I'm very interested in this technique.

No excuses, just an apology, a new opportunity and a wager.

Happy to help, just let me know what you'd me to do (even if that is hitting me with a stick until I do screencasts or tutorials) :P

@bauhouse willing to help here too; I do think that the sites running factory + proper documentation will help us focus prior to the next step.

Additionally to your comment on github I wouldn't see this effort going to waste even if eventually we had to move with Symphony Next. Especially if the community agrees upon the very core concepts of Symphony, which ultimately should stay more or less what they are now.

@brendo and @gunglien, thanks for your offers to help. I really appreciate it! I'll get a plan together for how we can move this project forward.

@gunglien, how has the CDI process been working for you. It would be great to schedule a time for a walk-through.

@bauhouse So far looks all right; not much issues.

It's not completely ideal when one of the devs does a lot of tests on his local machine & still pushes up the changes; so I tend to prefer having a look-in these days.

Also other potential issues (though not with the multi-dev only) could be when using multiple branches; switching between branches (because they have different extensions/datasources attached) could be slightly problematic. (once you run cdi.. there's no option to roll-back to go to state before the change for example)

But otherwise I didn't have id-related clashes or anything of the sort; so if one of my colleagues adds a section or a field; I'm guaranteed to have no conflicts whatsoever.

@gunglien, thanks for the update. It's worth giving CDI a go during our development and testing phases to see how well it works.

To get this project moving again, let's plan a regular meeting once a week. Let's see if we can coordinate our schedules and get a Google+ Hangout set up. What time of day works best for everyone?

For myself ideally would be weekdays after 5pm CET at the moment & possibly Saturday mornings. Would give me time to get back from work & set-up.

I volunteer to help as well! In this period I’m rather flexible, so I think I can adapt my schedule.

As @gunglien wrote, weekdays would be a better choice. How do we do with the different time zones?

So, weekdays after 5pm CET would be 8am PDT for me. I think that would work. That would be pretty short notice for today (Tuesday). Shall we try for tomorrow, Wednesday, and then figure out what works best for everyone? Unfortunately for @brendo, that's going to be 1am EST. To include the Australians, we may need to try something like:

• 10pm CET (Italy, Malta)
• 1pm PDT (Vancouver, Canada)
• 6am EST (Brisbane, Australia)

If anyone has any other suggestions, please let me know.

We'll also need a way to discuss things asynchronously, so I have set up a list of issues on GitHub: https://github.com/symphonycms/sym-getsymphony/issues.