You could argue that if you have global wikis, you may want global tickets to allow for "Update global documentation"-type tickets.
I'm skeptical about both global tickets and global wikis from a UX perspective as they represent a 'miscellaneous' category, which we should discourage because they often end up like the attics that no one ever cares to clean out. - Joe On 22 February 2013 10:41, Jure Zitnik <[email protected]> wrote: > On 2/22/13 3:03 AM, Branko Čibej wrote: > >> On 21.02.2013 18:05, Olemis Lang wrote: >> >>> On 2/21/13, Jure Zitnik <[email protected]> wrote: >>> >>>> On 2/20/13 5:21 PM, Olemis Lang wrote: >>>> >>>>> On 2/20/13, Andrej Golcov <[email protected]> wrote: >>>>> >>>> [...] >>> >>>> My suggestion is to keep things simple here: if there is already >>>>>> product named "Default', let's assign global tickets to this product. >>>>>> There should be reason why this product was called "Default" :) >>>>>> >>>>>> -1 ... IMO we the prefix for the global environment should be an >>>>> empty >>>>> string (i.e. '') or NULL (/me slightly in favor of the former) . That >>>>> will allow us to reserve special behavior for that prefix value (if >>>>> needed) and will not clash with any other valid product prefix since >>>>> it's a required field in create product web form (... admin command , >>>>> ...) >>>>> >>>>> Just to clarify, the prefix of the 'global environment' is an empty >>>> string (''). This will, at the moment, only be used for permissions. >>>> >>>> Yes , understood . >>> ;) >>> >>> The 'default' prefix (or 'def') is used for a product to which all the >>>> tickets that don't have product assigned are migrated to (during the >>>> database upgrade process). The product itself is automatically added >>>> during the upgrade/migration process. >>>> >>>> That's kind of what I was meaning in my reply . >>> >>> 1. Consider ticket without product before migration to be >>> tickets filed against the global environment . >>> 2. Use gobal env just like any other product env with >>> prefix = '' , not just permissions >>> 3. No need to create 'default' product while on upgrade >>> >>> PS: In the migration process we should also replicate (i.e. in DB) or >>> inherit product configs from a single file . I advocate for the later >>> . >>> >> I have to say that for once I completely agree with Olemis. NULL table >> column, and empty UI prefix equals "it all looks exactly like it used to >> before the migration" and it also can't collide with any existing >> product names or prefixes. >> >> Furthermore, doing it this way, if a user installs Bloodhound but >> doesn't want to bother with product namespaces, everything will Just Work. >> >> I agree with the 'Just Work' part, I don't agree with tickets in global > scope. > > My understanding was, based on the mailing list discussions, that we don't > want tickets in global scope. That is why current implementation creates > the 'default' product and migrates the tickets. I think that the 'Just > Work' part is more of the UI/UX issue. I think that each ticket should be > linked to a product, it's up to the UI to make it easy for the user to use > environments with only one product (default one). I find tickets in global > scope confusing as it's not exactly clear what they relate to. > > I would advocate global wikis for example, as it makes more sense. > > Cheers, > Jure > > > -- Joe Dreimann UX Designer | WANdisco <http://www.wandisco.com/> * * *Transform your software development department. Register for a free SVN HealthCheck <http://go.wandisco.com/HealthCheck-Sig.html> *
