On 24 April 2013 11:54, Joachim Dreimann <[email protected]>wrote:
> > On 24 April 2013 10:19, Matevž Bradač <[email protected]> wrote: > >> >> On 23. Apr, 2013, at 16:49, Gary Martin wrote: >> >> > On 23/04/13 10:45, Matevž Bradač wrote: >> >> On 22. Apr, 2013, at 17:17, Gary Martin wrote: >> >> >> >>> On 22/04/13 13:29, Matevž Bradač wrote: >> >>>> On 1. Apr, 2013, at 17:54, Branko Čibej wrote: >> > >> >>>>> I think everyone is focusing a bit too much on implementation >> details >> >>>>> and failing to ask the important question, which is: what role do >> system >> >>>>> wiki pages play in a multiproduct setup? >> >>>>> >> >>>>> Answer that question, and most of the debate falls by the wayside. >> >>>>> >> >>>>> 1. If system wiki pages are meant to support the whole BH >> installation, >> >>>>> then I see no good reason for anyone but system admins to be >> able to >> >>>>> modify them. There's potentially room for a new role here (system >> >>>>> wiki admin), that could only modify the system wiki, but not >> other >> >>>>> aspects of the system-wide setup; however, that's not an >> immediate >> >>>>> concern, IMO. >> >>>>> 2. On the other hand, if these "system wiki" pages are modifiable by >> >>>>> /product/ admins, or even ordinary users who have access to a >> >>>>> product, then it follows that each product can have its own >> version >> >>>>> of those pages, which implies these are no longer "system" pages >> at >> >>>>> all and you're back to square one -- deciding what to do with the >> >>>>> "real" system wiki pages, and whether or not they even exist. >> >>>>> >> >>>>> >> >>>>> IMO, pick one; but I suspect that #1 is the saner alternative. >> >>>>> >> >>>>> -- Brane >> >>>>> >> >>>>> -- >> >>>>> Branko Čibej >> >>>>> Director of Subversion | WANdisco | www.wandisco.com >> >>>>> >> >>>> Hi, >> >>>> >> >>>> I'm continuing with this topic since there doesn't seem to be a >> general >> >>>> agreement on how the (system) wikis should function in multiproduct >> >>>> environments. >> >>>> >> >>>> As Brane pointed out, it's firstly a decision on what role system >> wikis >> >>>> should assume. I'm leaning more towards #1, as having an >> >>>> installation-wide wiki may make sense, even if products are not >> directly >> >>>> connected with each other. Should we move in that direction? >> >>> As I said before, this is the approach that I would advocate. If >> users disagree then it shouldn't stop them from migrating pages to a >> product. >> >> Ok, moving into that direction then. >> >> >> >>>> The second issue would be how to handle wikis form the installation >> and >> >>>> upgrade point of view. Before multiproduct (MP) support, there was >> only >> >>>> one set of wiki pages to handle. With MP however, each product now >> gets >> >>>> its set of wiki pages, plus there is also a global scope which may >> (or >> >>>> may not) be used for system-wide wikis. >> >>> I think that it would help us to distinguish upgrade and import. For >> upgrading we could (should?) choose to leave the entire global wiki in >> place and let our users decide what they want to move into a product. For >> importing, we should probably import any global wiki into it's own project, >> and we could even ask for a name for this product in the process. Any >> products that we are importing can retain their names as long as there is >> no clash. If we don't want this to fail on those rare occasions, we can >> just append a uuid to the namespace names or something similar. >> >>> >> >>> Trying to think through clever solutions is probably not worth it if >> we can instead just provide appropriate tools for the users to sort >> themselves out. >> >>> Cheers, >> >>> Gary >> >> I'm not sure what you mean by import, would this perhaps be importing >> an >> >> existing Bloodhound or Trac environment into a specific product? If so >> >> I think we should postpone resolving this for now, IIRC it should be >> out >> >> of scope for upcoming releases? >> > >> > That is probably fair for now. I imagine that eventually users may want >> to consolidate separate installations into a single database (be that >> individual trac environments into a single new product or bloodhound >> environments into, potentially, multiple products). Of course, I may be >> wrong. >> >> I completely agree, it's one of the use cases we eventually have to cover, >> there just wasn't much emphasis or focus on import so far. >> >> > >> >> For upgrade I think your proposal doesn't fit into 1-3, so we can treat >> >> it as a separate one: >> >> 4. Leave all wikis in global scope >> >> + consistent with (current) clean installation behaviour >> >> - broken ticket links (wiki -> ticket, because tickets are moved into >> >> product scope) >> >> - empty product dashboard (but this is minor) >> >> >> >> I'll think about it a bit more, but this one seems to be the cleanest >> >> solution so far. >> > >> > While this might be a little off the current topic, I am still not >> entirely sure of the reason to move tickets into a different scope unless >> the users choose to do this. Providing the means for a user to easily >> migrate the global product tickets and optionally a wiki into a new product >> makes a bit more sense to me. Until a user explicitly does this, why would >> we need the tickets to be in anything other than the null product? Another >> nice aspect of this approach is that the wiki -> ticket links should remain >> available once users decide to move tickets into a different product as I >> believe previous links are meant to remain as synonyms specifically to >> maintain old links; the very fact that the tickets were in the null product >> should mean that they can still be referred to as if they are still in the >> null product. Redirection in this sense should be fine with the caveat that >> permissions of the current product in which the ticket resides should be >> respected. >> >> Wouldn't this bring us back to square one though? Global environment is >> currently considered as a "parent" to all product environments, and as >> such >> it allows for global configuration which specific products then inherit. >> If >> we change the role of the global environment to being "just a product", >> we'd >> have to rethink on how to handle global configuration. It's certainly >> doable, >> but likely at a substantial cost (design- and implementation wise). >> >> But that's just my opinion, I'll wait for others to chime in. =) >> > > From the interface perspective I've always said that there should be no > product until a user decides to create one. I have changed my mind now > after seeing some of the issues that brings and our discussions. > > We could just prompt the user to name the default product during > installation: > *Name for initial product:* > > During upgrade from trac users get prompted for an upgrade trac command, > so we can do the same there. > > Wouldn't that make it much easier to ship a decent implementation of this > in 0.6? > Just to be clear I would then leave system wikis at a global level (matched by page name) and all other wiki pages and tickets etc moved to the default product. Permissions to edit the system wiki can remain with the admin for now. Incorrect links (#1 should really lead to #PRODA-1) should be dealt with by providing disambiguation. > > - Joe > > >> >> > >> > Anyway, I'm trying to work out whether it is worth suggesting another >> orthogonal wiki on a different path for the Guide pages so that we can >> separate out concerns. So, if there is a path/to/wiki/ for each product's >> wiki, path/to/guide/ could be for system pages and then we would only have >> to consider upgrading the Guide pages in the Guide wiki and only actually >> at a single location and we can drop any excuse to meddle with the product >> wikis. >> >> That makes a lot of sense, and is IMO closely related to proposal 2 - >> global >> wikis moved to default product, empty global wiki populated with links to >> product wikis. Would it make sense to replace the global WikiStart with >> the >> Guide page in this case? >> >> > >> > Many of the same problems remain, including page duplication but the >> general disambiguation link solution is equally valid here. This wiki >> solution also seems consistent with subdomain setups that Olemis is so keen >> on. >> > >> > Cheers, >> > Gary >> >> >> -- >> matevz >> >> > > > -- > Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/> > > @jdreimann <https://twitter.com/jdreimann> >
