ميزات إضافة التقويم لجعلها مفيدة حقًا لنا

ميزة
1

متابعةً للنقاش من تقويم Discourse:

مشروع Fedora لديه حاليًا تطبيق ويب خاص بالتقويم، Fedocal. حان وقت تحديثه، وأفكر فيما إذا كان بإمكاننا استبدال التقويمات الموجودة في Discourse بدلاً من إعادة كتابة التطبيق المستقل. هذا ليس طلب ميزة حقًا، بل هو تجميع لحالات الاستخدام الخاصة بنا وما أراه مفقودًا أثناء تقييم ما يجب فعله.

حالات الاستخدام

هناك ثلاث حالات استخدام مهمة أراها لـ Fedocal. إذا كانت هناك حالات أخرى، فيرجى إخباري وسأضيفها إلى الاعتبار.

  1. جدولة الاجتماعات. هذا هو الأكثر أهمية بفارق كبير.
  2. السماح للأشخاص بمشاركة مدى توفرهم. حاليًا نطلب من الأشخاص المسؤولين في المشروع إدخال ذلك للإجازات، لكن قلة قليلة من الناس يفعلون ذلك بالفعل. (أنا شخصياً أجد الأمر مرهقًا للغاية عندما أتذكر ذلك).
  3. عرض فعاليات Fedora مثل Flock to Fedora، أسبوع التنوع، أو حفلات الإصدار. نحن لا نفعل ذلك حاليًا.

إمكانيات أخرى

  • حاولنا استخدام Fedocal لجدول مؤتمر Flock في عام 2013، لكننا لم نفعل ذلك منذ ذلك الحين. سيكون من الرائع أن يكون لدينا حل يجعل ذلك جذابًا وسهلاً.
  • عرض جدول إصدارات Fedora نفسه. حاليًا، أعتقد أننا نستخدم هذا فقط لجدولة اجتماعات “go/no-go”، وليس الجدول الفعلي. إذا فعلنا ذلك، فيجب أن يأتي تلقائيًا من Fedora Project schedules بدلاً من الحاجة إلى إدخال يدوي.

أوجه القصور في إضافة تقويم Discourse الحالية

نظام “الأحداث” “events” system الذي تتم إضافته إليه خاطئ حاليًا لما نحتاجه. (يجمع “الأحداث” من المشاركات عبر الموقع بأكمله ويضعها في تقويم عالمي واحد. نحتاج إلى أكثر من ذلك بكثير.

افترضي الأول هو أننا سنركز على توسيع الجزء “التقليدي” من إضافة التقويم، والتي تحتوي على تقويم في الرد الأول على موضوع يتم “تغذيته” بالردود على هذا الموضوع وحده. ومع ذلك، قد يكون النهج الآخر - جمع الأحداث عبر الموقع - أفضل. في هذه الحالة، سنحتاج إلى توسيعه ليكون قادرًا على الحصول على تقويمات متعددة للاستهداف. (وفي هذه الحالة سيكون من الرائع أن نتمكن من تضمينها في المواضيع المثبتة، وليس فقط إخفائها في قائمة الهامبرغر.)

لذلك، مع أخذ ذلك في الاعتبار، إليك بعض الأشياء التي سنحتاجها:

بشكل عام

  1. عرض التقويم نفسه بدائي للغاية.
  • يمكن أن يكون أجمل بكثير
  • لا يتكيف أو يتكيف مع كيفية عرضه بأي شكل من الأشكال
  • إنه مبرمج بشكل ثابت لأسابيع الاثنين-الأحد على الطراز الأوروبي
  • يبدو أنه يعرض الأيام دائمًا بتوقيت UTC، على الرغم من أن الإدخالات بتوقيتات محلية، مما يجعل الأحداث التي تستمر ليوم كامل في توقيت محلي تبدو وكأنها تمتد ليومين في التقويم. (فريق Discourse على علم بهذه المشكلة.)
  • يعرض عرض الشهر حاليًا الأحرف القليلة الأولى فقط من وصف الحدث. هذا جيد إذا كان التقويم يتعلق بشيء واحد بسيط (انظر قيد الاستخدام هنا لساعة Fedora الاجتماعية، ولكن ليس جيدًا لتقويم به الكثير من الأشياء المختلفة.
  • حاليًا، يمكن لإصدار “العطلات” من التقويم تعيين ألوان للأحداث، ولكنه يفعل ذلك باستخدام قيمة مشتقة برمجيًا من اسم المستخدم. يجب أن يكون هذا قابلاً للتكوين لكل حدث، وينطبق على جميع التقويمات وليس فقط تقويم العطلات.
  1. لا أعتقد أن هناك موجز .ical؟ سيكون من الجيد أن يتمكن الأشخاص من إضافته إلى تقويم Google الخاص بهم أو ما شابه.
  2. من الجيد توفره: القدرة على إنشاء رسائل تذكير يتم إرسالها إلى القوائم البريدية، وليس فقط للمستخدمين المشتركين. لم ينضم الجميع إلى Discourse بعد!
  3. من الجيد توفره: عرض تقويم شخصي حيث تختار بالضبط الإدخالات التي تريد تتبعها.

حالة استخدام الاجتماعات

  1. لدى Fedocal “محورين” أساسيين - المجموعة التي ينتمي إليها إدخال التقويم (مثل “المجلس”) والموقع (مثل “#fedora-meeting”). يمكن لإضافة التقويم القيام بأحد هذين المحورين: يمكننا إنشاء موضوع “اجتماعات مجلس Fedora” أو موضوع “قناة اجتماعات Fedora”، ولكن لن يتم ربط الإدخالات. لست متأكدًا تمامًا من أفضل تصميم لذلك كإضافة - أعتقد أننا بحاجة إلى بعض خبرة مصمم تجربة المستخدم في التفكير في ذلك.
  • سيكون جيدًا إذا كان محور “المجموعة” هو مجموعات Discourse، خاصة لأننا سنقوم بربط مجموعات Discourse بمعرف تسجيل الدخول الأحادي الخاص بنا (SSO) يومًا ما قريبًا آمل.
  • أو، ربما، يمكن أن يكون محور “المجموعة” للتقويم علامة. قد يكون ذلك أكثر مرونة، وسيعمل معنا لأننا نخطط لربط المجموعات بالعلامات لتنظيم موقعنا.
  • محور “المواقع” قصير - لدينا عدد قليل من قنوات الاجتماعات، ومن المحتمل أن يكون كافياً للسماح بموقع “آخر” للحالات الغريبة.
  1. حرج: يجب على النظام منع - أو على الأقل التحذير من - التعارضات على كلا المحورين. أي، لا يمكن أن يكون هناك اجتماعان لمجموعة المجلس في نفس الوقت، ولا يمكن أن يكون هناك اجتماعان من مجموعة مختلفة في نفس الموقع في نفس الوقت.
  • باستثناء ما إذا كان لدينا “آخر” شامل … لذا، أعتقد أنه يجب أن تسمح بعض المواقع بالتداخل.
  1. بناء الجملة للأحداث المتكررة غريب بعض الشيء، ولكنه مقبول. ومع ذلك، تظهر الأحداث المتكررة في شبكة التقويم على أنها متكررة (وفي التذكير يتم تحديثها إلى الحدث التالي)، ولا شيء أكثر من ذلك. ويجب أن يكون هناك المزيد:
  • حرج: يجب أن يكون المستخدمون قادرين على الاشتراك في إشعار لكل حدث متكرر، على أساس كل إدخال تقويم.
  • من الجيد توفره: تكوين لكل مجموعة Discourse للإشعارات الافتراضية لتقويم معين، بحيث على سبيل المثال، أعضاء مجموعة المجلس يحصلون افتراضيًا على إشعارات لإدخالات تقويم المجلس.
  • من الجيد توفره: القدرة على تكوين إشعارات تحذيرية لمدة 15 دقيقة للاجتماعات القادمة
  • مهم: يجب أن يكون من الممكن تحديد أحداث معينة لتخطيها (أو عقدها في وقت مختلف) دون تغيير كل شيء.
  1. حاليًا، يتم التعامل مع مدة الحدث بإدخالات مثل [date=2021-11-28 time=12:00:00 timezone="America/New_York"] → [date=2021-11-28 time=13:00:00 timezone="America/New_York"]. هذا ممل للإدخال والنتيجة (2021-11-28T17:00:00Z → 2021-11-28T18:00:00Z) ليست واضحة على الفور. سيكون من الجيد استخدام [date=2021-11-28 time=12:00:00 timezone="America/New_York" duration="1 hour"] بدلاً من ذلك.
  2. من الجيد توفره: يجب أن تكون الإدخالات التي لا تحتوي على مدة مختلفة بصريًا - وربما مسموح بها فقط للإدخالات “طوال اليوم”.
  3. من الجيد توفره: يمكن أن يحتوي كل إدخال تقويم (بشكل منفصل للأحداث المتكررة) على رابط لموضوع جدول الأعمال + الملاحظات. لن يتم إنشاء هذا الموضوع تلقائيًا بدون تفاعل، ولكن يجب أن يكون من السهل البدء بنقرة واحدة، وبمجرد إنشائه، يتم ربطه تلقائيًا.

حالة استخدام “العطلات”

  1. يجب أن يكون تقويم العطلات على دراية بالمجموعات أيضًا. حاليًا لديه بعض المعالجة الخاصة للموظفين (موقع Discourse) - يجب تعميم ذلك وتكوينه، والسماح بتقويمات مختلفة لمجموعات مختلفة بالإضافة إلى تقويم عالمي.
  2. في تكوينه الافتراضي، يعرض تقويم العطلات العطلات الوطنية القياسية لكل شخص لديه منطقته المحلية معدة. إذا كان هذا أكثر من خمسة أشخاص في مكانين مختلفين على الأكثر، فإنه يطغى على كل شيء آخر. قدم لنا Discourse حلاً مؤقتًا لإخفاء ذلك، على الرغم من ذلك.
  3. من الجيد توفره: حاليًا يحصل الموظفون على رمز تعبيري :palm_tree: بجوار اسم المستخدم الخاص بهم عندما يكونون في إجازة، ولا يراه سوى الموظفين الآخرين. يجب أن يكون عرض هذا الرمز قابلاً للتكوين.
  4. من الجيد توفره: السماح بتكوين الرمز التعبيري الذي يتم عرضه.
  • مكافأة جيدة: السماح للمستخدمين بالاختيار من قائمة من الرموز التعبيرية والأسباب لوقت عدم التوفر المحدد (إجازة، مرض، سفر، إلخ)

فعاليات Fedora

في الواقع، أعتقد أن ما لدينا اليوم يمكن أن يعمل لهذا الغرض. ومع ذلك، فإن بعض ما سبق - عرض تقويم أجمل وأكثر مرونة، وإشعارات، وألوان - سيكون مفيدًا.

لإمكانيات أخرى

  • حالة استخدام جدول المؤتمر هي مجرد حالة استخدام جدول الاجتماعات، ولكن بشكل مكثف للغاية. يصبح تتبع التعارضات يدويًا مستحيلاً. لهذا، قد نحتاج إلى محور على مستوى المستخدم بدلاً من محور على مستوى المجموعة. (لا يمكن أن يكون المتحدثون في مكانين في وقت واحد.) وعلى عكس مواقع غرف الاجتماعات لدينا، التي لم تتغير كثيرًا في 15 عامًا (باستثناء تحديثات عناوين URL) ولن تتغير على الأرجح في 15 عامًا أخرى، فإن كل حدث له مجموعته الخاصة من المواقع.
  • تقويم جدول الإصدار: أعتقد أن هذا هو في الغالب مسألة أتمتة في استيراد بيانات الجدول الحالية. يمكن لإضافة التقويم الحالية أن تعمل في الغالب، أعتقد. مرة أخرى، كما هو الحال مع فعاليات Fedora، سيكون الترميز اللوني لطيفًا.
14 إعجابًا
2

Pavilion is working on a Discourse Events Integration Plugin (DEIP), which, inter alia, will allow you to publish events to Discourse from other services and platforms. We submitted a proposal to DAPSI (an EU NGI program), which was accepted for funding. The program just kicked off (last night) and we’re starting work on it. This will overlap with some of the points you raised.

Edited version of the executive summary from the proposal

There is no abstract data model for calendar events in regular use by online event services. We will first specify and prototype a working data model based on an assimilation of previous standardisation attempts and the data models of popular event services (“DEIP Specification and Prototype”). We will then productize this specification in the form of an open source Discourse plugin that will allow online communities to easily transfer calendar event data between popular event management platforms (initially Eventbrite, Meetup and Zoom) and Discourse, the most popular open source community software (“DEIP Product”). We will be offering service-orientated subscriptions to businesses using the MVP to ensure the plugin’s continued viability over time.

The DEIP Product will be a commercially-viable open-source alternative to Facebook’s recently-launched Official Events API, which provides similar functionality, but for Facebook’s “walled garden” of community data. Facebook has been investing in its community features for some time, and that investment is growing. Facebook’s continued focus on this aspect of its product means open-source alternatives need to be continually improving equivalent offerings to stay viable. The DEIP Specification and Product will be vital tools in that struggle.

Discourse is one of the few truly viable open source platforms for online communities. It’s the most popular community project on github, and recently raised $20 Million USD to further grow its expanding organisation (55 employees supporting over 32,000 communities). Discourse’s platform is 100% open source and is deeply embedded in open source software communities and culture.

Pavilion (the Applicant) is a co-operative of developers and product managers and an official partner of Discourse. We’ve been working with Discourse for over 6 years and have built a substantial portion of the extant 3rd-party plugins for Discourse, including the most popular Discourse plugin and a number of plugins which have subsequently been adopted (made “official”) by Discourse.org.

The combined Specification and Product will serve as both an exponent of calendar event data model standardisation, and provide an efficient open-source solution for event management on the tens of thousands of online communities using Discourse.

Summary (Problem and Solution)

The primary problem faced by online communities managing events is service integration. Communities use a mixture of marketing platforms such as Eventbrite, discovery platforms such as meetup.com, meeting tools such as Zoom, or all-in-one solutions such as Facebook. The difficulty of managing a community across multiple services means there is an incentive to use proprietary solutions which offer convenience over transparency and portability.

The DEIP will be both a calendar event data model specification and prototype, and an open-source commercially-viable Discourse plugin. In summary, the DEIP will:

  1. Define a practical calendar event data model specification.
  2. Implement the specification in a working prototype.
  3. Develop the prototype into a Discourse Plugin with support for importing from popular event services, and exporting using common calendaring standards.
  4. Release the plugin as an open source product, with a subscription service targeted at business users.

Specification (The Research Component)

The main standards in the management of calendar events are RFC 5545 (.ics format) and RFC 4791 (CalDAV, or “ical feeds”). The problem with these standards is that they are not currently used to model calendar event data available from modern APIs. The equivalent objects available via the Eventbrite, Meetup and Zoom APIs do not translate to RFC 5545, or to each other. Attempts by industry bodies to develop an Abstract Calendaring API have yet to bear fruit, despite some recent attempts. Moreover, proprietary services do not provide group/site/community-wide CalDAV feeds (they sometimes provide user-specific feeds). In short, there is a significant paucity of calendar event data model standardisation.

The primary research component of the DEIP will be to specify an abstract event data model that implements the existing standardization attempts, while maintaining practical usability vis-a-vis the most popular proprietary event-related services (the “DEIP Specification”). This specification will then be converted into a working prototype (initially in Ruby; subsequently in other languages), allowing for the creation, reading, update and deletion of generic calendar events (the “DEIP Prototype”). Depending on the outcomes of this work, we may seek to package the DEIP Prototype for distribution via different package systems, e.g. ruby gems.

As well as forming the basis of the MVP (see below), the specification and prototype will be published on the DEIP landing page with accompanying explanations of the thinking behind it. We will also dedicate a section of our own community to it for further discussion. We want to be an active part of efforts to bring event software services closer to the use of standard data models to improve service interoperability and portability.

Development (The Development Component)

We will develop the DEIP Specification and Prototype into an MVP Discourse Plugin offering the following features:

  • Discourse Event API with Create, Read and Delete support. Update support (i.e. two-way communication) will be added in a later product version.
  • Specific support for popular services. Initially Eventbrite, Meetup and Zoom.
  • Integration with the Discourse Event Plugin to display events within Discourse topics and provide an Events Calendar within Discourse itself.
  • A CalDAV server to provide a unified feed of all events in a community, with the ability to filter by category and user.
  • Integration with the Legal Tools Plugin for GDPR support and the Locations Plugin for GeoJSON location mapping using open source mapping solutions.

Deployment (Relevance, impact and benefits)

Pavilion supports thousands of online communities through our paid consulting work and unpaid open source work, many of which have evinced a clear need for the DEIP Product, including university researchers, health support communities, hobbists, small businesses, neighbourhoods, startups, non-profits, Fortune-500 companies, fantasy novelists and nature photography enthusiasts. For a sampling of this need, see here, here, here, here, here, here and here. The lack of ease of event portability and integration is frequently a key factor in the choice between locked-in proprietary solutions like Facebook and open source solutions like Discourse.

Pavilion members will be personally deploying the DEIP Product for our existing clients who run events, as well as assisting the many open source users of our work, like those linked above. In addition to Pavilion’s work within the Discourse community, the DEIP will have:

Our goal is for the DEIP Product to be a viable alternative to event management on proprietary community platforms and for the DEIP Specification and Prototype to advance efforts in calendar event data model standardisation.

Business Model (Commercial Exploitation)

Pavilion has developed a subscription model for our open source Discourse plugins that maintains our commitments to open source and supporting non-profit communities, while ensuring our members get properly compensated for their work. The model has the following features

  • 100% open source code.
  • Selected “business” features that are not visible on the application client unless the community manager has purchased a subscription.
  • Free subscriptions for non-profit communities that use the “business” features.
  • Business-orientated services for paid subscribers.

Feature-restriction in a 100% open source code base can be programmatically overcome, however this is not relevant to the target market for paid subscriptions. Businesses want to pay for services that benefit them, and those that choose to overcome the restrictions are not the target customers for that aspect of the product.

We could potentially expand the scope of this project to include some of the other things you’ve mentioned, i.e. those focused on event features within Discourse itself, however we’d need additional funding. If you want to discuss this further you can PM me about it. In any event, I’ll be sharing more details about the DEIP project here on meta as we progress.

10 إعجابات
3

تهانينا يا أنجوس!!! هذا رائع. هذا لديه القدرة على المساهمة بشكل كبير في عالم أفضل (وليس مجرد مجموعة من المنتديات، ولكن هذا رائع أيضًا). أتمنى أن تنجح في ذلك!

8 إعجابات
4

مرحباً يا أنجوس،

هل أحرزت أي تقدم في هذا الشأن؟ إنها مشكلة دائمة لجميع منتدياتي، وتدفع الناس إلى منصات أخرى للاجتماعات وما شابه.

إعجابَين (2)
5

مرحباً ناثان، سيكون لدينا بعض الأمور لمشاركتها في غضون شهر تقريباً. في غضون ذلك، يمكنك التواصل معي على انفراد عبر coop.pavilion.tech ويمكنني مساعدتك في إعداد فعاليات على منتدى الخاص بك.

بالإضافة إلى مشروع DEIP، نفكر في إحياء إضافة الفعاليات وقد نستخدمها لمعالجة بعض المخاوف المذكورة أعلاه.

4 إعجابات
6

كما وعدت، إليك التقرير الكامل عن المرحلة الأولى من مشروع المكون الإضافي لتكامل أحداث Discourse.

https://docs.google.com/document/d/1-oJsXivT_KRBZ-wUQ-TbHdO7Z-qf7z4GeiRiJ014V-E/edit?usp=sharing

وهنا نموذج التنفيذ لنموذج بيانات الأحداث (جوهرة روبي). لاحظ أن الجوهرة قيد التطوير وليست جاهزة للاستخدام الإنتاجي.

https://github.com/paviliondev/omnievent

كما ستلاحظ عند قراءة تقرير البحث، سيتم بناء المكون الإضافي نفسه في المرحلة الثانية من المشروع.

4 إعجابات
7

عمل رائع يا أنجوس. أتطلع لرؤية الثمار خلال الفترة القادمة!

أنا مفتون بعدد أوجه التشابه مع مجال معلوماتية الصحة الخاص بي. نعاني من نفس المشاكل المتعلقة بنماذج البيانات الخاصة المتعددة التي نمت بشكل عضوي والتي لا تعمل بشكل جيد. ويعاني المرضى نتيجة لذلك.

هناك مشروع بيانات مفتوحة مثير للإعجاب يسعى أساسًا إلى فعل الشيء نفسه لجميع البيانات الصحية:

إعجابَين (2)
8

مجرد تحديث آخر للإشارة إلى أن عملنا في المرحلة الأولى تمت مراجعته بشكل إيجابي من قبل DAPSI وأن هذا المشروع يتقدم إلى المرحلة الثانية، أي بناء إضافة تكامل الأحداث. سيتضمن جزء من هذا تجديدًا لإضافة أحداث Pavilion.

بالفعل. أجريت محادثة جيدة مع @pacharanero حول هذا التداخل على الغداء في يورك.

5 إعجابات
9

ملاحظة أخيرة هنا وهي أن النسخة التجريبية من المكون الإضافي لدمج الأحداث متاحة الآن :slight_smile:

سأقوم بنشر المزيد من التحديثات في هذا الموضوع.

5 إعجابات