Change Details

The process of moving a WM test wiki from the Incubator (or Multilingual Wikisource, or Wikiversity Beta) to its own dedicated subdomain can be confusing and frustrating to the "end users" (i.e., the folks waiting to use their "new" wiki), because the wiki typically shows up in a very incomplete state. This is presumably only going to get worse with our recent move to create new wikis even "earlier in the process", with very minimal configuration that is fleshed out after the wiki is actually created. For context, see the discussion starting at T335969#8953791 and then [[ https://lists.wikimedia.org/hyperkitty/list/langcom@lists.wikimedia.org/thread/CG3E7JL3XH34DJOYSWNCBWD42LBTIRDM/ | this langcom mailing list thread ]]. The new workflow is being tested with tlywiki: T345166, T345316, T345170. For a lot of nitty gritty details, see {T158730}. As it becomes clear which steps in the process are being pushed to a later stage, after the wiki has been created, we need to consider which post-creation configuration steps should be done before the wiki is publicly visible (if this is desired) and (more importantly) before the wiki is publicly //editable//. In other words, I think we should view wiki creation in terms of the following four stages: # before the wiki exists (T158730 seems to be mainly concerned with this stage) # after it exists but before it is publicly visible (is this a thing?) # after it is visible but before it can be edited by the general public (i.e., importing of content, and what else?) # after people are editing it but before all configuration has been "finalized" (I'm not sure if stage 2 should be a separate stage or whether it is, practically speaking, indistinguishable from stage 1.) Thus, I envision changing from the more generic * Create X * Initial configurations for X * Post-cretion work for X system of tasks that we have been using, to the more "results-based": * Create X * Make X publicly viewable * Make X publicly editable * Finish configuring X Or some such. Using more informative names like this, and segregating the configuration steps into their appropriate tasks (i.e., not mixing urgent things with "can do at any time" things), clarifies which step of the processs the wiki is in, and might encourage resolving of the tasks in a more timely manner. [grin] I need people to weigh in here about what steps belong to what stages.

The process of moving a WM test wiki from the Incubator (or Multilingual Wikisource, or Wikiversity Beta) to its own dedicated subdomain can be confusing and frustrating to the "end users" (i.e., the folks waiting to use their "new" wiki), because the wiki typically shows up in a very incomplete state. This is presumably only going to get worse with our recent move to create new wikis even "earlier in the process", with very minimal configuration that is fleshed out after the wiki is actually created. For context, see the discussion starting at T335969#8953791 and then [[ https://lists.wikimedia.org/hyperkitty/list/langcom@lists.wikimedia.org/thread/CG3E7JL3XH34DJOYSWNCBWD42LBTIRDM/ | this langcom mailing list thread ]]. The new workflow is being tested with tlywiki: T345166, T345316, T345170. For a lot of nitty gritty details, see {T158730}. As it becomes clear which steps in the process are being pushed to a later stage, after the wiki has been created, we need to consider which post-creation configuration steps should be done before the wiki is publicly visible (if this is desired) and (more importantly) before the wiki is publicly //editable//. In other words, I think we should view wiki creation in terms of the following four stages: # before the wiki exists (T158730 seems to be mainly concerned with this stage) # after it exists but before it is publicly visible (is this a thing?) # after it is visible but before it can be edited by the general public (i.e., importing of content, and what else?) # after people are editing it but before all configuration has been "finalized" (I'm not sure if stage 2 should be a separate stage or whether it is, practically speaking, indistinguishable from stage 1.) Thus, I envision changing from the more generic * Create X * Initial configurations for X * Post-creation work for X system of tasks that we have been using, to the more "results-based": * Create X * Make X publicly viewable * Make X publicly editable * Finish configuring X Or some such. Using more informative names like this, and segregating the configuration steps into their appropriate tasks (i.e., not mixing urgent things with "can do at any time" things), clarifies which step of the process the wiki is in, and might encourage resolving of the tasks in a more timely manner. [grin] I need people to weigh in here about what steps belong to what stages.

The process of moving a WM test wiki from the Incubator (or Multilingual Wikisource, or Wikiversity Beta) to its own dedicated subdomain can be confusing and frustrating to the "end users" (i.e., the folks waiting to use their "new" wiki), because the wiki typically shows up in a very incomplete state. This is presumably only going to get worse with our recent move to create new wikis even "earlier in the process", with very minimal configuration that is fleshed out after the wiki is actually created. For context, see the discussion starting at T335969#8953791 and then [[ https://lists.wikimedia.org/hyperkitty/list/langcom@lists.wikimedia.org/thread/CG3E7JL3XH34DJOYSWNCBWD42LBTIRDM/ | this langcom mailing list thread ]]. The new workflow is being tested with tlywiki: T345166, T345316, T345170. For a lot of nitty gritty details, see {T158730}. As it becomes clear which steps in the process are being pushed to a later stage, after the wiki has been created, we need to consider which post-creation configuration steps should be done before the wiki is publicly visible (if this is desired) and (more importantly) before the wiki is publicly //editable//. In other words, I think we should view wiki creation in terms of the following four stages: # before the wiki exists (T158730 seems to be mainly concerned with this stage) # after it exists but before it is publicly visible (is this a thing?) # after it is visible but before it can be edited by the general public (i.e., importing of content, and what else?) # after people are editing it but before all configuration has been "finalized" (I'm not sure if stage 2 should be a separate stage or whether it is, practically speaking, indistinguishable from stage 1.) Thus, I envision changing from the more generic * Create X * Initial configurations for X * Post-creation work for X system of tasks that we have been using, to the more "results-based": * Create X * Make X publicly viewable * Make X publicly editable * Finish configuring X Or some such. Using more informative names like this, and segregating the configuration steps into their appropriate tasks (i.e., not mixing urgent things with "can do at any time" things), clarifies which step of the processs the wiki is in, and might encourage resolving of the tasks in a more timely manner. [grin] I need people to weigh in here about what steps belong to what stages.