Datetime Community meeting on May 27, 2021

:two: Updates on action items from last meeting

mandclu
We didn't really identify any new action items last meeting, but as an updated to an action item from the previous meeting, I did create the page for us to capture use cases

:three: Document for date and time use cases: Use Cases for Working With Dates and Times

mandclu
Any feedback on this? I know there could be a lot more content, but these were what came to mind when I sat down to write. Would love to hear from others

erik.erskine
One use case I’m dealing with at the moment: a field that represent this content is relevant for the period ….

erik.erskine
It’s used for views filtering (eg. show me all the content for 2020). Values are typically things like “2021” or “Q3 2020". Technically a date range, but ideally I’d have a simpler UI

:four: Defining a set of goals and/or a roadmap map for what we'd like to accomplish (edited)

mandclu
@highermath I believe you raised this in the last meeting, but I don't think we really got to discuss it in any detail. Do you have some thoughts?

highermath
I think that we need to
set priorities,
determine the difficulty and importance of each priority,
use those data to organize them into sprints
Find someone to lead each sprint
Determine a workable timeframe
(edited)

mandclu
Here are some thoughts I have on what our priorities might be:
Get better date functionality in core - we know that this will likely be a slow process, but if we can keep it moving, hopefully we can start to build momentum
Identify gaps in Drupal's date/time ecosystem - what use cases are still really hard to address in Drupal? What's the best/most efficient way to address each of them?
Reduce duplication in the ecosystem - There is significant overlap in the modules available. Could we reduce the duplication, and make it clear which modules are best used in certain situations?
Make it easier for site builders to solve common use cases

highermath
I think that we are going to need to get the PreviousNext folks involved to move this forward.

highermath
I like your list.

mandclu
Organizing sprints would require having a commitment of time from people, likely on an ongoing basis. Who is willing to step up and commit to taking on some tasks?
I agree that if the PreviousNext folks could commit resources to helping, that would be huge

highermath
I think that #3 is particularly important, as we need to get our stakeholders on the same page

highermath
I will commit to dedicating some time to this at the organizational level.

mandclu
I agree, and I think that making progress on #3 could free up time to work on some of the other items. #4 will probably get more important as the project browser initiative gathers momentum

highermath
And #2 is the other big one. Whether and when some or all of what we do gets into core is a meta-goal.

highermath
I think that #4 is more of a guiding principle.

mandclu
Yes and no. I've started the Configuration Kits projects as a way to encourage the development of "solutions" and not just tools. I think for site builders, the ability to quickly install a functioning system would be huge, especially if it's something they can continue to tweak and refine, and adapt to their sites's specific needs

mandclu
Configuration Kits

highermath
Do you work for that Digital furry thing company?

mandclu
I do, but my community work is on a volunteer basis

mandclu
ACTION: I'll start a document to act as a manifesto/plan, and capture the discussion above

Warped
Consolidation of features is great for making site building easier. Less chance for conflict between modules. Hopefully increasing participation from the other module developers if they can see it as shared work of managing a single module instead of separate issue queues, etc. Providing upgrade/migrate paths from other modules would also help those maintainers who want to join.

erik.erskine
#2 is a good start, and will probably drive #1 and #3 to some extent.
Especially so if we can identify shortcomings in core’s datetime handling. A good starting point would be to look at some contrib alternatives and ask why they exist and what gap they fill. (Looking at you, smart date!)
Lots of litle contrib modules aren’t bad per-se - if they all play nicely together. That’s when a good API in core comes into it’s own, even if the functionality alongside it has limited functionality.
Media is good example of this - core has the API plus one implementation for videos hosted on youtube. Useful but by no means comprehensive. But now other modules can use that as a reference implementation, eg flickr photos, tweets etc. (edited)

mandclu
Ha I'm always happy to talk about Smart Date and what gaps it was designed to fill, but you may regret having gotten me started :stuck_out_tongue:
More seriously, do you have idea where you think that examination of alternatives should happen? Theoretically maybe it could be a section on https://www.drupal.org/docs/comparison-of-contributed-modules/comparison..., or were you thinking of this as more of a discussion within a meeting?