Posted by pwolanin on April 30, 2010 at 5:04pm
I wrote at http://acquia.com/blog/drupalcon-buzz-can-we-say-r-word-drupal-8 asking questions about whether we need to collect together various roadmaps and plans in a central place to communicate a "plan" to developers and Drupal users.
What do you think? How could we make that work and keep it up to date throughout a core development cycle? Do you think that would be valuable or a distraction?
Comments
PHP OO
I think moving to OO would be the logical move. PHP 5.3 is now mature enough to provide a solid OO language. I don't see why we should stop us from using it. Some logical entities (like nodes and user) should become classes and hook should be described using Interface. I've encountered many case we it would have been useful to be able to inherit a node class and extend it.
But I do see
Please do not let this become another OOP battleground. While using OOP where it makes sense is good and all but the fundamental flaw of PHP classes -- you need to declare 'em in one file and that's it, you can't add more methods stops us from using it at many places.
I agree
You do rise a valid concern that I didn't thought of. This should definitely be addressed by PHP. Either in the form of partial class or by allowing late class member declaration (which would be better IMHO) or even both.
Use and misuse
That's only a limitation if you're using OO in a naive and foolish way, like module == class. There's plenty of use cases where that's not a problem at all. Views for instance, or Feeds.
I agree though that OO vs. procedural has nothing to do with "how do we aggregate road maps".
The use of OO is an
The use of OO is an implementation detail, not relevant where/how to have an overall "plan"
Wanted: Fragmentation
The recent revamp of core component maintainers has already led to much more discussion, collaboration, and ultimately, traction on respective Drupal core components. Naturally, people are starting to have more clear visions of what needs to be done and what could be done. Although mostly kept in private conversations, there are indeed a couple of concrete ideas and plans for Drupal 8 already.
However, the code freeze phases of Drupal 7 clearly revealed that the biggest potential for mapping a road lives in API clean-ups. Those partially led to entire revamps of existing code throughout Drupal core. And effectively, every single clean-up heavily clarified the usage of a certain functionality in Drupal core -- ultimately turning wildly annoying and rather confusing thoughts about core API fragments into clear considerations about how a certain component of Drupal core is supposed to work currently, and how exactly it could be changed in the future.
Don't get me wrong, but for me it's still a fact that most of Drupal APIs are still very annoying. If there wouldn't have been time restrictions, then I would have cleaned up much more stuff. And this leads me to my point:
It makes no sense for me to think about raw + wild + fancy big picture ideas, which most often want to replace entire subsystems or whatnot of Drupal core. As long as core is full of inconsistencies, workarounds, ill logic, and hard-coded presumptions, such larger changes - if executed at all - do not touch or improve the WTF-parts of the system and, most often, rather introduce more inconsistencies and problems, rather than working towards a solid system.
In addition, we should have learned by now that just putting Usability + X features on a roadmap is not necessarily healthy for Drupal core. I wonder whether anyone ever wondered why that is? My take is simple: Because any new feature requires solid and clean APIs to be introduced properly. But yes, again, most of Drupal's APIs are anything, but not clean. We still carry around historical baggage from Drupal 4.x times almost everywhere, and that's also the reason for why we have so many ugly contributed modules.
However. By revamping Drupal core component maintainers, we laid the ground for the community to build open teams around topics, which heavily focus on quality, vision, and execution. Fundamental prerequisites to clean up and improve the entire system. In turn, much more solid ideas for improving core in D8 and beyond arose already, but most teams are totally aware of the fact that their component/topic badly needs heavy clean-ups instead of major API changes.
I'm not opposed to having a roadmap. If my vote would count, I'd therefore put the roadmap for D8 this way:
Proper unofficial and official roadmaps, we should discuss for D9 at earliest.
Daniel F. Kudwien
netzstrategen
API clean ups totally
I so agree, I begun by cleaning up (slicing into three) menu APIs. However, Views in core, can you imagine the amount of API clean-ups for that :) ?
whishlist
Drupal 8 =
* HTML 5
* Wysiwyg
* Views in core
* STAGING STAGING STAGING
so, where do we post ?
Do we need a MAP first?
API clean up sounds great. I haven't been around that long, but from my very first experience with core, API clean up became one of my personal goals for when I become more competent and am able to contribute. Sadly, most of the talks around Drupal 8 Initiatives are of new systems, and features. Some of them will help us organize, and make core better, but I would really like to see a group of people (not only chx) working on the clean up of the existing code.
One of my guesses of why it is so hard to organize people to clean core, is because there are only a handful of people competent enough to look at the code and know what to do.
So my first thought is that we need to make core more accessible to newcomers, and I figure that the best way to do that is by having a map of core. If we had a diagram of how thing do (or should) work together it would serve a a roadmap for how we want the clean version of core to be organize, as documentation for new drupalist that want to help on these efforts, and as base to see how the new systems should fit with the current code.
Here in this blog, I attempted to create the simplest diagram (Map) of Drupal I could, while accommodating as many major parts as I could. Hopefully, people would like to build upon it. Let me know what you think!
x