Change Details

= Session Themes and Topics= * Theme: Architecting our code for change and sustainability * Topic: Definition of Core, how code fits together, architecture, code encapsulation, FE/BE separation, extension interface =Session Leader= * Tim Starling =Facilitator= * Greg Grossmeier =Description= In this session we will discuss what concepts and operations should be modeled in MediaWiki, what are the nouns and verbs that MediaWiki understands? This will help us better define components within the code base, interfaces for extensions, as well as APIs for interacting with clients. Some concepts are obvious like “pages” and “edits”, but some concepts which are currently emulated by extensions may be helpful to introduce into MediaWiki proper, such as “workflows”, “drafts”, or “assessments”. Also, refining our definition and understanding of established concepts could be helpful, for instance to establish whether any curatable object on the wiki should be considered a “page”. =Questions to answer during this session= Question: Which concepts are essential to MediaWiki functionality? Significance: Why is this question important? What is blocked by it remaining unanswered? Establish a shared understanding what the “core” of MediaWiki is about, what functionality the “platform” should provide. Question: Which additional concepts are widely used (via gadgets, extensions, bots, etc) , but not explicitly modeles by MediaWiki? Which of these should be modeled in MediaWiki? Significance: This allows us to develop a plan to remove technical debt, inconsistencies and overhead caused by the need to somehow glue concepts into MediaWiki which it doesn’t support. Paving the cow paths reduces friction, replacing hacks with well defined concepts makes the code more maintainable. Question: Conversely, what functionality currently in core should be factored out into an extension? What extension points would be necessary to do this? Significance: This ties this session into the discussions about modularization and extension interfaces. Moving code for optional functionality into extensions makes core more easy to maintain. Question: What are the criteria for deciding whether a concept should be modeled in core, and if it is supported, to what extent it is fleshed out, or left as a mere extension point. Significance: Having a decision matrix template for this question will allow us to make decisions about what concepts should be in core more quickly, and with more confidence. = Session Structure = * **Define session scope, clarify desired outcomes, present agenda** * Discuss Focus Areas ** Discuss and Adjust. ''Note that we are not trying to come to a final agreement, we are just prioritizing and assigning responsibilities!'' ** For each proposition [add etherpad link here] *** Decides whether there is (mostly) agreement or disagreement and the proposition(s). *** Decide whether there is more need for discussion on the topic, and how urgent or important that is. *** Identify any open questions that need answering from others, and from who (product, ops, etc) *** Decides who will drive the further discussion/decision process (ie: a four month deadline) * Discuss additional strategy questions [add etherpad link here]. For each question: ** Decide whether it is considered important. ** Discuss who should answer it. ** Decide who will follow up on it. * **Wrap up** ---- **Session Leaders** please: [] Add more details to this task description. [] Coordinate any pre-event discussions (here on Phab, IRC, email, hangout, etc). [] Outline the plan for discussing this topic at the event. [] Optionally, include what it will //not// try to solve. [] Update this task with summaries of any pre-event discussions. [] Include ways for people not attending to be involved in discussions before the event and afterwards. ---- Post-event Summary: * ... Action items: * ...

= Session Themes and Topics= * Theme: Architecting our code for change and sustainability * Topic: Definition of Core, how code fits together, architecture, code encapsulation, FE/BE separation, extension interface =Session Leader= * Tim Starling =Facilitator= * Greg Grossmeier =Description= In this session we will discuss what concepts and operations should be modeled in MediaWiki, what are the nouns and verbs that MediaWiki understands? This will help us better define components within the code base, interfaces for extensions, as well as APIs for interacting with clients. Some concepts are obvious like “pages” and “edits”, but some concepts which are currently emulated by extensions may be helpful to introduce into MediaWiki proper, such as “workflows”, “drafts”, or “assessments”. Also, refining our definition and understanding of established concepts could be helpful, for instance to establish whether any curatable object on the wiki should be considered a “page”. =Questions to answer during this session= |**Question**|**Significance: Why is this question important? What is blocked by it remaining unanswered? ** |Which concepts are essential to MediaWiki functionality? |Why is this question important? What is blocked by it remaining unanswered? Establish a shared understanding what the “core” of MediaWiki is about, what functionality the “platform” should provide. | Which additional concepts are widely used (via gadgets, extensions, bots, etc) , but not explicitly modeles by MediaWiki? Which of these should be modeled in MediaWiki? |This allows us to develop a plan to remove technical debt, inconsistencies and overhead caused by the need to somehow glue concepts into MediaWiki which it doesn’t support. Paving the cow paths reduces friction, replacing hacks with well defined concepts makes the code more maintainable. |Conversely, what functionality currently in core should be factored out into an extension? What extension points would be necessary to do this? |This ties this session into the discussions about modularization and extension interfaces. Moving code for optional functionality into extensions makes core more easy to maintain. | What are the criteria for deciding whether a concept should be modeled in core, and if it is supported, to what extent it is fleshed out, or left as a mere extension point. |Having a decision matrix template for this question will allow us to make decisions about what concepts should be in core more quickly, and with more confidence. = Session Structure = * **Define session scope, clarify desired outcomes, present agenda** * Discuss Focus Areas ** Discuss and Adjust. ''Note that we are not trying to come to a final agreement, we are just prioritizing and assigning responsibilities!'' ** For each proposition [add etherpad link here] *** Decides whether there is (mostly) agreement or disagreement and the proposition(s). *** Decide whether there is more need for discussion on the topic, and how urgent or important that is. *** Identify any open questions that need answering from others, and from who (product, ops, etc) *** Decides who will drive the further discussion/decision process (ie: a four month deadline) * Discuss additional strategy questions [add etherpad link here]. For each question: ** Decide whether it is considered important. ** Discuss who should answer it. ** Decide who will follow up on it. * **Wrap up** ---- **Session Leaders** please: [] Add more details to this task description. [] Coordinate any pre-event discussions (here on Phab, IRC, email, hangout, etc). [] Outline the plan for discussing this topic at the event. [] Optionally, include what it will //not// try to solve. [] Update this task with summaries of any pre-event discussions. [] Include ways for people not attending to be involved in discussions before the event and afterwards. ---- Post-event Summary: * ... Action items: * ...

= Session Themes and Topics= * Theme: Architecting our code for change and sustainability * Topic: Definition of Core, how code fits together, architecture, code encapsulation, FE/BE separation, extension interface =Session Leader= * Tim Starling =Facilitator= * Greg Grossmeier =Description= In this session we will discuss what concepts and operations should be modeled in MediaWiki, what are the nouns and verbs that MediaWiki understands? This will help us better define components within the code base, interfaces for extensions, as well as APIs for interacting with clients. Some concepts are obvious like “pages” and “edits”, but some concepts which are currently emulated by extensions may be helpful to introduce into MediaWiki proper, such as “workflows”, “drafts”, or “assessments”. Also, refining our definition and understanding of established concepts could be helpful, for instance to establish whether any curatable object on the wiki should be considered a “page”. =Questions to answer during this session= |**Question: Which concepts are essential to MediaWiki functionality? Significance:**|**Significance: Why is this question important? What is blocked by it remaining unanswered? ** Why is this question important? What is blocked by it remaining unanswered? Establish a shared understanding what the “core” of MediaWiki is about, what functionality the “platform” should provide. Question: Which additional concepts are widely used (via gadgets, extensions,|Which concepts are essential to MediaWiki functionality? bots,|Why is this question important? etc) ,What is blocked by it remaining unanswered? but not explicitly modeles byEstablish a shared understanding what the “core” of MediaWiki?i is about, Which of these should be modeled in MediaWiki? Significance:what functionality the “platform” should provide. This allows us to develop a plan to remove technical debt| Which additional concepts are widely used (via gadgets, extensions, inconsistencies and overhead caused by the need to somehow glue concepts into MediaWiki which it doesn’t support.bots, Paving the cow paths reduces frictionetc) , replacing hacks with well defined concepts makes the code more maintainable. Question: Conversely,but not explicitly modeles by MediaWiki? Which of these should be modeled in MediaWiki? what functionality currently in core should be factored out into an extension?|This allows us to develop a plan to remove technical debt, What extension points would be necessary to do this? Significance: This ties this session into the discussions about modularization and extension interfacesinconsistencies and overhead caused by the need to somehow glue concepts into MediaWiki which it doesn’t support. Paving the cow paths reduces friction, replacing hacks with well defined concepts makes the code more maintainable. Moving code for optional functionality into extensions makes core more easy to maintain. Question: What are the criteria for deciding whether a concept should be modeled in core|Conversely, and if it is supported,what functionality currently in core should be factored out into an extension? to wWhat extent it is fleshed out,sion points would be necessary to do this? or left as a mere extension point. Significance:|This ties this session into the discussions about modularization and extension interfaces. Moving code for optional functionality into extensions makes core more easy to maintain. | What are the criteria for deciding whether a concept should be modeled in core, and if it is supported, to what extent it is fleshed out, or left as a mere extension point. |Having a decision matrix template for this question will allow us to make decisions about what concepts should be in core more quickly, and with more confidence. = Session Structure = * **Define session scope, clarify desired outcomes, present agenda** * Discuss Focus Areas ** Discuss and Adjust. ''Note that we are not trying to come to a final agreement, we are just prioritizing and assigning responsibilities!'' ** For each proposition [add etherpad link here] *** Decides whether there is (mostly) agreement or disagreement and the proposition(s). *** Decide whether there is more need for discussion on the topic, and how urgent or important that is. *** Identify any open questions that need answering from others, and from who (product, ops, etc) *** Decides who will drive the further discussion/decision process (ie: a four month deadline) * Discuss additional strategy questions [add etherpad link here]. For each question: ** Decide whether it is considered important. ** Discuss who should answer it. ** Decide who will follow up on it. * **Wrap up** ---- **Session Leaders** please: [] Add more details to this task description. [] Coordinate any pre-event discussions (here on Phab, IRC, email, hangout, etc). [] Outline the plan for discussing this topic at the event. [] Optionally, include what it will //not// try to solve. [] Update this task with summaries of any pre-event discussions. [] Include ways for people not attending to be involved in discussions before the event and afterwards. ---- Post-event Summary: * ... Action items: * ...