Change Details

= Session= * Track: Standardization Decisions * Topic: Developing in Mediawiki without breaking Gadgets =Description= Gadgets are the essential part of working on wikis, especially for experienced and active users. When creating new features Product Managers often formulate a quite reasonable requirement to developers that //no gadgets should be broken when the new things is being shipped//. While there is no other interface that gadgets rely on than HTML/DOM structure of the page, such requirement makes introducing new functionality and doing any user-facing changes quite challenging. Taken to the extreme not wanting to break gadgets would mean that nothing can be changed. Lack of defined interface gadgets use, and also not knowing, nor being able to predict what gadgets could be affected by changes results in bug reports from gadget authors. Apart from social impact, this also extends the length of the development and release cycle of new software, hence negatively affects developer productivity. It also stops innovation, or significantly limits it. In the lack of well-defined gadget interface, knowing what gadgets //cannot be broken// would allow, to certain degree, to reverse-define what parts of page structure should be kept in what form to allow these gadgets to continue working. In this workshop-style session we'll share our experiences of successes and failures in the development of software in MediaWiki environment and how it worked with existing gadgets. What helped and what we find particularly problematic? Have we identified which gadgets to particularly look after? Are there any other ideas and practices that others could adapt in their work? Is introducing a dedicated API for gadgets the only ultimate solution? Would it be useful to create some sort of inventory of gadgets (not necessarily names/URLs of the most used/important user scripts, but possibly an inventory of functionalities and workflows that editors use gadgets for)? If so, could we leverage the know-how in the room to make a start? =Questions to answer and discuss= **Question:** **Significance:** **Question:** **Significance:** = Related Issues = * ... * ... =Pre-reading for all Participants= * [add links here] ---- =Notes document(s)= [link to notes document (gdoc and / or etherpad)] =Notes and Facilitation guidance= https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019/NotesandFacilitation ---- =Session Leader(s)= * [name] * [name] =Session Scribes= * [name] * [name] =Session Facilitator= * [name] =Session Style / Format= * [what type of format will this session be?] ---- **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 this session 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: * ... Post-event action items: * ...

= Session= * Track: Standardization Decisions * Topic: Developing in Mediawiki without breaking Gadgets =Description= Gadgets are the essential part of working on wikis, especially for experienced and active users. When creating new features Product Managers often formulate a quite reasonable requirement to developers that //no gadgets should be broken when the new things is being shipped//. While there is no other interface that gadgets rely on than HTML/DOM structure of the page, such requirement makes introducing new functionality and doing any user-facing changes quite challenging. Taken to the extreme not wanting to break gadgets would mean that nothing can be changed. Lack of defined interface gadgets use, and also not knowing, nor being able to predict what gadgets could be affected by changes results in bug reports from gadget authors. Apart from social impact, this also extends the length of the development and release cycle of new software, hence negatively affects developer productivity. It also stops innovation, or significantly limits it. In the lack of well-defined gadget interface, knowing what gadgets //cannot be broken// would allow, to certain degree, to reverse-define what parts of page structure should be kept in what form to allow these gadgets to continue working. In this workshop-style session we'll share our experiences of successes and failures in the development of software in MediaWiki environment and how it worked with existing gadgets. What helped and what we find particularly problematic? Have we identified which gadgets to particularly look after? Are there any other ideas and practices that others could adapt in their work? Is introducing a dedicated API for gadgets the only ultimate solution? Would it be useful to create some sort of inventory of gadgets (not necessarily names/URLs of the most used/important user scripts, but possibly an inventory of functionalities and workflows that editors use gadgets for)? If so, could we leverage the know-how in the room to make a start? =Questions to answer and discuss= **Question:** **Significance:** **Question:** **Significance:** = Related Issues = * ... * ... =Pre-reading for all Participants= * [add links here] ---- =Notes document(s)= [link to notes document (gdoc and / or etherpad)] =Notes and Facilitation guidance= https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019/NotesandFacilitation ---- =Session Leader(s)= * Amir E. Aharoni (@Amire80) * Leszek Manicki (@WMDE-leszek) =Session Scribes= * [name] * [name] =Session Facilitator= * [name] =Session Style / Format= * [what type of format will this session be?] ---- **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 this session 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: * ... Post-event action items: * ...

= Session= * Track: Standardization Decisions * Topic: Developing in Mediawiki without breaking Gadgets =Description= Gadgets are the essential part of working on wikis, especially for experienced and active users. When creating new features Product Managers often formulate a quite reasonable requirement to developers that //no gadgets should be broken when the new things is being shipped//. While there is no other interface that gadgets rely on than HTML/DOM structure of the page, such requirement makes introducing new functionality and doing any user-facing changes quite challenging. Taken to the extreme not wanting to break gadgets would mean that nothing can be changed. Lack of defined interface gadgets use, and also not knowing, nor being able to predict what gadgets could be affected by changes results in bug reports from gadget authors. Apart from social impact, this also extends the length of the development and release cycle of new software, hence negatively affects developer productivity. It also stops innovation, or significantly limits it. In the lack of well-defined gadget interface, knowing what gadgets //cannot be broken// would allow, to certain degree, to reverse-define what parts of page structure should be kept in what form to allow these gadgets to continue working. In this workshop-style session we'll share our experiences of successes and failures in the development of software in MediaWiki environment and how it worked with existing gadgets. What helped and what we find particularly problematic? Have we identified which gadgets to particularly look after? Are there any other ideas and practices that others could adapt in their work? Is introducing a dedicated API for gadgets the only ultimate solution? Would it be useful to create some sort of inventory of gadgets (not necessarily names/URLs of the most used/important user scripts, but possibly an inventory of functionalities and workflows that editors use gadgets for)? If so, could we leverage the know-how in the room to make a start? =Questions to answer and discuss= **Question:** **Significance:** **Question:** **Significance:** = Related Issues = * ... * ... =Pre-reading for all Participants= * [add links here] ---- =Notes document(s)= [link to notes document (gdoc and / or etherpad)] =Notes and Facilitation guidance= https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019/NotesandFacilitation ---- =Session Leader(s)= * [name]* Amir E. Aharoni (@Amire80) * [name]* Leszek Manicki (@WMDE-leszek) =Session Scribes= * [name] * [name] =Session Facilitator= * [name] =Session Style / Format= * [what type of format will this session be?] ---- **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 this session 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: * ... Post-event action items: * ...