Working Group Structure

[allen]

This isn't quite the place to do this, but while things aren't set up just right yet, this is the best place to do this for now. Email is a little cumbersome until the groups are set up...

Just to reiterate on the working group structure, this is the working group member list:

Core Group

IA Members:

• Nils Hoerrmann (@nilshoerrmann)
• Bernardo Dias (@bernardodiasc)
• Jens Scherbl (@jensscherbl)

SA Members:

• Brendan Abbott (@brendo)
• Thomas Appel (@iwyg)
• Nicolas Brassard (@nitriques)
• Huib Heemink (@creativedutchmen)

  Community Group

• Allen Chang (@allen)
• John Porter (@designermonkey)

  Documentation Group

• Stephen Bau (@bauhouse)
• Jonathan Mifsud (@jonmifsud)
• Ian Young (@ijy)
• Andrea Buran (@theBigMandarino)

I think we're one short on IA, which @ijy and @jonmifsud did volunteer also. Ideally we shouldn't have members pull double duty so we're all focused on our own areas. Who's up for moving into Core IA? If there's no candidates, we can have Ian and Jonathan sub in for the time being until a more permanent member can join the sub group.

Next. The Core (IA+SA) needs to schedule a time to discuss Next. This meeting will need to pencil down the next 4 weeks of tasks.

Before the core meeting occurs:

The IA group members have to individually write up a list of existing UI limitations and also proposals for how we can solve the limitations. I know this is going to rehash some old topics, but it is important for us realign our vision and get everyone on the same page again.

The SA group members have to have played, poked, prodded and possibly even broken Laravel and have at the very least a good understanding of the framework's capabilities and limitations. The meeting will decide just how Symphony should integrate Symphony with Laravel.

I everyone who has been named here to voice up, so we are sure that everyone is on board and ready to get things going.

[bauhouse]

I'm in for the Documentation Group.

[bernardodiasc]

Hi @allen, if still possible, I would like to join in IA group.

[creativedutchmen]

IA group members have to individually write up a list of existing UI limitations

Wait. UI? I am not really a UI guy to be honest...

[nitriques]

Thanks @allen for all this coordination.

[iwyg]

Thanks @allen. Sorry guys for being silent the last couple of days. My Macbook Pro died, still struggling with getting my backups system up.

[designermonkey]

Quite happy to continue on the community group for the current codebase, and website. Also, I've been involved so far with the documentation from a perspective of structure and ideas for implementation.

It still holds true that I have very little time, and for the next week or two, I have a very serious matter to attend to from a past part of my life, so I may be a little vacant for that time. Hopefully things will ease on that front and I'll be back to help out.

[designermonkey]

Also, I can supply a Jira environment for up to 9 members and myself for serious planning if it is needed. I know we use Github, but for serious task planning, the option is there if it is wanted :)

[nitriques]

Thanks a lot @designermonkey

[jensscherbl]

@allen It's still on my radar, but I haven't had the time yet to dive into Laravel. Composer and unit testing is also new ground for me, so I might not be a good fit for the SA group at this point.

Would make more sense to switch roles with @creativedutchmen. I could be some kind of mediator between software- and information architects, while also maintaining the role I proposed a few days ago.

[nitriques]

@allen @jensscherbl I will play with Lavarel ASAP. I really think we shoud focus on defining the quality attributes that are most important: trying to get them all is always impossible and trade-offs have to be made. As far as I am concern, I think that testability, maintainability and flexibility are the three attributes we must start with.

I also start up drawing some module diagrams, which could relate to packages in the code. I hope to be able to PR this stuff soon, as I leave for a three weeks vacation next Thursday (I will have my phone with me and will follow all the discussion though).

[ijy]

Happy with the above.

[allen]

@bernardodiasc Sure, that's great. I'll update the structure accordingly.

@jensscherbl no problem, I'll switch your role with @creativedutchmen

@creativedutchmen I put you in IA because you mentioned you can help with the "design", but I misinterpreted that in the literal sense. I'll switch your role with @jensscherbl

[creativedutchmen]

@allen thank you. With design I indeed meant the "technical design". Sorry for the confusion (and unfortunate choice of words).

[ranbureand]

I’m on board too!

[allen]

Had a real awesome hangout session at this week's Docs meet. Myself, @brendo, @rowan-lewis, @theBigMandarino, @nilshoerrmann, @designermonkey and @bauhouse joined the meet and got a bunch of stuff sorted.

Now, we need to set up a core dev meet too. I won't propose a date until two things have happened:

1. Everyone in the SA group have had the chance to play with Laravel
2. Everyone in the IA group have made a list of requirements for Next.

For the SA guys, you don't need to be an expert in Laravel, but I think it's important to at least have an idea on how the integration with Symphony might work. I understand there are a lot of other technical questions we need to address but the issue surrounding the framework of choice and approach to integration is our productivity killer right now.

For the IA guys, with the requirements, we don't need anything detailed. Just things like, "Symphony Next should be able to handle section relationships better", "Symphony Next should be able to version control structural changes in Sections and pages", etc. Bear in mind though that for each requirement in the list, you should also think about possible solutions to that problem.

If the core group is ready for our chat, I'll propose a date and time for a Google Hangout session.

Cheers, and thank your mum for the cookies.

[brendo]

Ah, @allen, is your above post backwards?

1. Everyone in the IA group have had the chance to play with Laravel
2. Everyone in the SA group have made a list of requirements for Next.

Should it be the SA group use Laravel and the IA group make a requirements list right?

[allen]

Yes sir, yes sir, three bags full.

I've fixed it up. Expect more shenanigans and tomfoolery in everything I write after midnight.

[iwyg]

Did a couple of projects with Laravel 3 and 4 as well as some Laravel bundles. So I guess I'm ok with that.

[nitriques]

Yeah, I quickly read the Lavarel doc, and I must say that there are a lot of pros and cons to be listed explicitly. Still could not figure out sometime to actually work on that, but I am staying up to date with the conversation here.

[iwyg]

Personally I find most of the laravel docs quite quirky. Leveraging those static facades seems quite an antipattern and usually new developers tend to use them in their classes instead of explicitly declaring their dependencies.

Another concept that's potentially dangerous is the ability to bind interfaces to an implementation. This might be useful in certain cases, but think of a class that expects a different implementation than the one that's bound to the interface and you whole application might go straight to hell (well, in the worst case).

Fabien Potencier, the creator of Symfony pointed this out and removed interface binding from symfony's IoC container. Maybe Laravel will follow with the next release.

[nilshoerrmann]

@allen: We talked about cross-posting this on the forum to gain more interest from visual designers. Shall I post it or will you do that?

[allen]

I'm out of commission tonight and all of tomorrow. If you have the time to do this now, could you please do it? Otherwise, I can post it sometime Wednesday evening.

[nitriques]

Hi everyone,

@rowan-lewis I just sent you an email with my contact information.

I am back from 20 days of vacations. Will be available all day long tomorrow (EDT time).

[iwyg]

Hi, and thanks for sharing. I was actually under the impression that this project is dead. Good news at least it's not. I'll go over the RFC asap and let you know what I'm thinking about.

Cheers, Thomas

[jensscherbl]

In the meantime, I had a chance to make myself familiar with Composer and Laravel, so count me in for development as well (if needed).

[henrysingleton]

Hells yeah! Very exciting to see this continuing. Will try and get some time to go over this RFC as well, but in theory it sounds great

[brendo]

Good work Rowan! Let's do this On 1 Nov 2013 11:22, "Henry Singleton" notifications@github.com wrote:

Hells yeah! Very exciting to see this continuing. Will try and get some time to go over this RFC as well, but in theory it sounds great

— Reply to this email directly or view it on GitHubhttps://github.com/symphonycms/symphony-next/issues/15#issuecomment-27542018 .

[nitriques]

Very good work Rowan. I will try to see what I can do about Renderers.

[nitriques]

Otherwise I have some very perverted ideas involving MongoDB...

Me too...

[iwyg]

I think it's important to evaluate the current symphony API approach. In my opinion, if you'd translate the api to an ORM, a section is a Model, a field is a validator, and a Datasource is like the sections' controller that knows what content to pull from its Model. So basically this could be done with Eloquent or every other relational ORM.

[jensscherbl]

What we need is a proper evaluation of Eloquent ORM, to see if it's possible to create an API similar to current Symphony around it.

What @nils-werner has done with his Scaffolding package is a pretty good start in my opinion.

We also could rethink if fields should really store multiple values, or if it would be better to model more complex data structures with another model/section instead, using one to one relationships.

[iwyg]

Yes, lets do this. Just one more thing

Fields have user interfaces […]

And I think fields shouldn't know anything about their user interface. That's not their responsibility. A fields UI is only related to the backend UI and has no use elsewhere. So there should be something else caring about a fields UI e.g a controller. So basically you could split it up into 3 parts : Field, FieldSettingsController, FieldPublishController…

[nitriques]

Field, FieldSettingsController, FieldPublishController

And with DI, someone could change the UI without having to code a new field or inherit from the other one. +1

[bernardodiasc]

Hi guys, I know everyone have compromises and I bet when the time has passed this great team grew up skills and the idea is much more mature today. I'm very happy to be part of such great project.

I'm on AI team, so I'll let the tecnical decisions with you, but as asked by Allen on this comment https://github.com/symphonycms/symphony-next/issues/15#issuecomment-22458188, I'm preparing a few itens which I consider very important to have on the next Symphony. The good part is that the system as it is today is so great that I hope we use it as startpoint and improve without lose focus in the good parts.

[nitriques]

Can't wait to hear more :)

Me too!

[lewiswharf]

Love this.

[streaps]

MongoDB!!!

[ijy]

To kick-start things for the IA team I've put together a list of core characteristics for Symphony Next.

I've tackled it from a more open-minded top-level approach so that we don't fall into the trap of just trying to re-build Symphony 2 in Laravel without an eye on the bigger picture. We don't want opportunities to be missed or problems to be carried over because we didn't take a step back to get a better view. Start with a vision and refine it down to an action plan. :) As a result I've deliberately not gone into any technical implementation just yet and also not directly tied it to Symphony 2 although Symphony 2 already does a fantastic job and caters for many of those points.

As I was compiling the list it seemed to make sense to break it down into varying viewpoints/personas as not everyone's needs and requirements are the same and we need to consider the variation of the target audience we're designing for. Some of the points may need further elaboration or discussion but is probably better suited to working group meetings for speed. It's a start however to get the ball rolling.

I've done plenty of research on the IA side of things and there are some pretty radical developments happening in some corners. I'd be happy to elaborate further and start conceptualising with the IA team but just keeping things focused for now. I think once the IA requirements lists have been compiled however it's probably a good time to switch to a more focused project management setup.

[bernardodiasc]

What an outstanding list. Most of my own list are there (and much more! congrats @ijy), I just want to add a little things:

In the developer/builder view I would like to have some main field that can be integrate with special functionalities. For example the Upload Field, if I want to add unique/custom naming behavior, or multiple upload behavior, or resize image behavior, or version behavior, or crop behavior.. etc. Just examples of things we have each one in a different extension today, and change from one to another is a real pain (sometimes impossible).

One other thing is to have something like modular content and structure. I would like to get some section folder, copy and paste in another project and voilà, the section and the content can be reused. This is just a simple example. But I think its easy to understant what I mean.

I know there are some extensions that do this (in some way), but I really miss a textarea with multimedia superpowers. Maybe this fits in the first item I mention, but its important, mainly for content publishers users.

Well, really, @ijy's list is very wide, I cant think anything that are not already there at the moment. :)

[ijy]

Thanks @bernardodiasc, it's a starting point at least.

One other thing is to have something like modular content and structure. I would like to get some section folder, copy and paste in another project and voilà, the section and the content can be reused.

As in template re-use, content re-use or settings re-use? I think the general consensus seems to be to have more flat-file configuration (XML based or otherwise) so that would be possible to re-use. Templates (regardless of template language used) should also be re-usable to some degree and provide template inheritance. But I've steered clear of technical implementations for the moment as that can present a sticking point at times.

By all means, feel free to use my list as a starting point from which to add to or add any others as comments and I'll modify the gist so we all work from one compound list. Whatever is easier and preferable.

[ijy]

With the above list and a lot of research and consideration in to the IA side of things I'm ready for the WG discussions whenever everyone else is.

[bernardodiasc]

What I mean in the reusable stuff is a kind of a better import/export system, file-based or not. In a real scenario I wat to have some parts to be plugged on a new project. Or update existing projects.

Example: is I have a project with a Post section and want to reuse it in another project this should be easy, with content or empty. Maybe even with data source and related templates. I also can store an origin, lets call, package and from it update several projects.

Said that, the unique ID for content is also important, in that way I can export/import whatever I want, with some filter, for example, the Post section content for the package I mention above. This kind approach maybe also help on sync enviroments (I'm having hard time syncing dev and prod database).

[bernardodiasc]

[kinda offtopic] spend last days reading all Drupal documentation and making some little tests on it for a more complex work I'll need to do in teamwork (its not up to me the choice of the tool). God I miss Symphony so much. Drupal is powerful, big, complex and fuuuuull of "I dont want this" or "Could be different" stuff! Otherwise, more I know Drupal, its possible to like it, but dont get close of the Symphony structure/logic/concept/workflow/etc. [/kinda offtopic]

As Sym is good as it is and remember the begin of the second rush of Sym3 discussions, I suppose the Sym2 fault is only on it framework level, thats right?

[jensscherbl]

As Sym is good as it is and remember the begin of the second rush of Sym3 discussions, I suppose the Sym2 fault is only on it framework level, thats right?

More or less, yeah. I guess most of us are just experimenting with possible rewrites in private for now, and development on the current codebase continues for a while.

[michael-e]

I don't think that the framework is the only point. I see another very important point, and that is overcoming the current technological difference between the backend and the frontend. As soon as you start building an "app" (i.e. have more "content" administered from the frontend), you will see that this is a big issue. Some things are simpler in the backend, some in the frontend. And you can never interchange them or re-use code. In an ideal world, both the backend and the frontend would be driven by the same approach (MVC, that is, probably) and the same building blocks (Events, Datasources and XSLT, at the moment). Imagine having only one type of user account and being able to simply manage every "administrative" access (from posting a contact form to editing a section's structure) using an advanced permissions layer!

I don't know if that's on the radar though. And I know that this is a very ambitious ides (which has been postponed more than once). But it would make Next really great. More than that: As long as Symphony has a separated "backend", it is just a CMS. The "Symphony eats its own dog food" idea which I tried to describe would make Symphony kind of a "super-framework" (on top of a framework).