Learning patterns/Planning existing structures for ease of future access

From Meta, a Wikimedia project coordination wiki
A learning pattern forteamwork
Planning existing structures for ease of future access
problemTo reduce the amount of future transition issues while a Project is currently being built
solutionAll planning must necessarily consider future ease of access and factor that while building the project
creatorSoni
endorse
created on27 April, 2015
status:DRAFT


What problem does this solve?[edit]

Often when creating a new project, we fail to account for future editors taking over the maintenance and handling of the pages and do not really consider how complicated things can be when done in first draft. This often will lead to issues in the future when other developers need to take over the project and might end up in, to some extent, stagnancy in the project space.

Another issue that it leads to is that there is a consistent dependency on a few to modify parts of the project in cases where there needs to be minor maintenance to quickly fix bugs that appear later on.

What is the solution?[edit]

One possible way to deal with this is to ensure all planning is done keeping future understanding in mind. There needs to be a minimum amount of documentation for everything in the project, as well as easy to understand Project Maps that others can quickly browse through. Another way is to have the members of the Project think of possible places where the project might be hard to understand from an outsider point of view, and try to simply the documentations for them as much as possible.

Another possibility worth considering is for the project members to make sure there are built resources that can be of use in the future, even though they currently would not be that important. For example, running future analytics on a Wikiproject might be much easier if there is extensive use of well built Categories for even a layman to start using the information, rather than a need for extensive coding or bot-writing abilities. There could be other ways to build more resources that don't have immediate short term importance but might be likely to be used in the longer term.

Things to consider[edit]

  • When making maps/layouts, the terms used must be consistent throughout the documentation as well as with the rest of the project, for ease of understanding. For example, referring to editors as "mentors" at one location and "teachers" at another would be confusing.

When to use[edit]

  • In scenarios where there might be expected maintainance of the project, even if one editor is dedicated to mantaining it for the short term
  • Wherever the structure of the space is not readily apparent. For example, in cases where a trancluded template is called by another template, the nesting might be hard to follow for those not adept with using templates in general.

See also[edit]

  • Map, which contains the documentation for Co-op project on the English Wikipedia.

Related patterns[edit]

External links[edit]

References[edit]