symphony-next
symphony-next copied to clipboard
symphonycms
Working Group Structure
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.
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...
Thanks @allen. Sorry guys for being silent the last couple of days. My Macbook Pro died, still struggling with getting my backups system up.
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.
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 :)
@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.
@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).
@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
@allen thank you. With design I indeed meant the "technical design". Sorry for the confusion (and unfortunate choice of words).
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:
- Everyone in the SA group have had the chance to play with Laravel
- 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.
Ah, @allen, is your above post backwards?
- Everyone in the IA group have had the chance to play with Laravel
- 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?
Yes sir, yes sir, three bags full.
I've fixed it up. Expect more shenanigans and tomfoolery in everything I write after midnight.
Did a couple of projects with Laravel 3 and 4 as well as some Laravel bundles. So I guess I'm ok with that.
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.
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.
@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?
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.
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).
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
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).
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
Good work Rowan! Let's do this On 1 Nov 2013 11:22, "Henry Singleton" [email protected] 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 .
Otherwise I have some very perverted ideas involving MongoDB...
Me too...
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.