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?
- 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>
