Quick Poll: Y Drive PROs vs CONs

Management is contemplating removal of access to TeamSite (6.5 Windows). It would be great it if you could vote on this (YES to keep the Y:drive, NO to remove it) and provide some feedback regarding the PROs and CONs of maintaining access. I'd also love to know if anyone else has fought this fight along with details.

Some obvious PROs:
1. Increased productivity on the part of developers who can configure Eclipse/CVS to access files directly when TeamSite is used to deploy code.
2. Increased productivity on the part of content contributors, typically Photshop and Dreamweaver users, who use TeamSite workareas as their file spaces.
3. Increased productivity on the part of Sys Admins for multi-server tasks.
4. Simple configuration of external processes, such as data feed programs, that create/update files in TeamSite.
5. The alternative to Y:drive access almost, the File:Import faciltiy, often fails and has a very "unfriendly" interface.

Some CONs:
1. Misuse by poorly trained users resulting in content anomalies such as when the output of a template is modified via the Y:drive versus automatic invocation of templating when the edit link is clicked.
2. Files are not locked when opened for edit via the Y:drive.

Thanks in advance for your thoughts and votes.

Find more posts tagged with

Comments

Antharix

I presume you are working with teamsite installed on Windows environment.

Y: is usually a ts mount which appears when TS is up and running.

Is your environment any different from the above?
Does your management not want to continue with TeamSite?
Or is your management planning to revoke/restrict access to specifig group?

LeggMan

I presume you are working with teamsite installed on Windows environment.

Y: is usually a ts mount which appears when TS is up and running.

Is your environment any different from the above?
Does your management not want to continue with TeamSite?
Or is your management planning to revoke/restrict access to specifig group?

Answers to all your questions are in, or can be inferred from, the title and first sentence of my post. I'm hoping DevNetizens will chime in with their thoughts and experiences related to "Y:drive" access -- be it TeamSite Windows or Unix -- that I can use to bolster my arguments to management to continue allowing such access.

Thanks

nipper

From my experience, the y drive is a nice to have and can make you life easier. I find it hard to work without it, but not impossible. 95% of my assets that are modified are done so with TST and launchpad covers the other small % for images.

Even for me as a developer, since all my changes are on my config branch, I use LP to upload and submit (which deploys to iwhome), I am able to get away without Y access. Still I prefer it if I have it.

The issues you talk about are training issues and can be addressed with a solid workflow.

HTH

Andy

ISCBorisB

Management is contemplating removal of access to TeamSite...

What exactly is the problem your Management is trying to solve? We can argue Pros's and Con's of different alternatives addressing certain
defined issues. It is however (almost) impossible to rationally discuss something as vague as "This is against our Company Security policy".

Adam Stoller

From my experience, the y drive is a nice to have and can make you life easier. I find it hard to work without it, but not impossible. 95% of my assets that are modified are done so with TST and launchpad covers the other small % for images.

Even for me as a developer, since all my changes are on my config branch, I use LP to upload and submit (which deploys to iwhome), I am able to get away without Y access. Still I prefer it if I have it.

The issues you talk about are training issues and can be addressed with a solid workflow.

HTH

Andy

In my experience with TeamSite (on Windows), the Y: drive is mandatory - as TeamSite is not accessible without it. On the other hand, the samba share "IWSERVER" and/or "default" are exceedingly useful from a developer perspective though of questionable usage for content creators.

When I'm working in an environment with multiple developers - I find communication is important regardless of whether or not we have access to the virtual mount point from our individual desktop machines - it just become more important if you do have access to it. Also important is to have editing applications that can recognize when a file has changed from beneath it -- TextPad and Emacs are two such editors, though certainly not the only ones; WordPad [a.k.a. "write.exe"] and NotePad tend to lack this functionality and should be avoided when working in such an environment.

LaunchPad can be used, but it can get a bit frustrating when you're trying to figure out, for a couple of hours, why your code changes aren't working and it turns out it is because you forgot to upload and/or submit them ;-)

nipper

LaunchPad can be used, but it can get a bit frustrating when you're trying to figure out, for a couple of hours, why your code changes aren't working and it turns out it is because you forgot to upload and/or submit them ;-)

You cannot fix stupidity. Yes, I answer that question maybe once a week. But it is like pulling teeth to get IT to install Java on some desktops, so I deal.

LeggMan

What exactly is the problem your Management is trying to solve? We can argue Pros's and Con's of different alternatives addressing certain
defined issues. It is however (almost) impossible to rationally discuss something as vague as "This is against our Company Security policy".

Thanks to nipper and ghoti for their input above!

The Admins of the TeamSite servers I work on cite a recent incident where an HTML developer accessed a document via the Y:drive -- which happend to be generated from a template -- and modified/deployed it instead of clicking the "Edit" link to edit the underlying DCR. Since this involved a disclosure that would have been syndicated to other workareas/sites if the DCR had been processed properly our Compliance folks were rightfully unhappy.

As nipper suggested earlier, this problem can be addressed with training to prevent a re-occurrence. The workflow could also be revisited to make it smarter and recognize when an illegal operation was being attempted. But, instead, the Admins would like to "throw the baby out with the bathwater" and are loathe to consider all the benefits derived from Y:drive access or all the problems that will occur if such access was turned off. I

f I could report that the "thought leaders" on DevNet all advised that turning off the Y:drive was a cure worse than the disease then my arguments might be more influential.

nipper

The Admins of the TeamSite servers I work on cite a recent incident where an HTML developer accessed a document via the Y:drive -- which happend to be generated from a template -- and modified/deployed it instead of clicking the "Edit" link to edit the underlying DCR. Since this involved a disclosure that would have been syndicated to other workareas/sites if the DCR had been processed properly our Compliance folks were rightfully unhappy.

Removing the Y: access won't prevent this from happening if someone *really* wants to avoid the template (they can use edit with). Workflow is the proper way to deal with it. Just a review process *should* have caught this. In my WF I add the DCR if a generated page is submitted (and then regenerate it regardless), in this case the changes would have been lost. I have people who edit and save & then submit (the generated page) later.

LeggMan

Removing the Y: access won't prevent this from happening if someone *really* wants to avoid the template (they can use edit with). Workflow is the proper way to deal with it. Just a review process *should* have caught this. In my WF I add the DCR if a generated page is submitted (and then regenerate it regardless), in this case the changes would have been lost. I have people who edit and save & then submit (the generated page) later.

Unfortunately, neither the business nor technical reviewer noticed or knew enough to catch this. Good point regarding "edit with" outflanking templatized editing. I agree that the workflow should be revisited to prevent this "illegal" operation from occurring... should be pretty simple if all ASPX pages in the workarea or a defined list of folders are generated from DCRs.

--------------

Thanks to ALL for chiming in with genuinely useful perspectives!

LeggMan

What exactly is the problem your Management is trying to solve? We can argue Pros's and Con's of different alternatives addressing certain
defined issues. It is however (almost) impossible to rationally discuss something as vague as "This is against our Company Security policy".

Just noticed that you did not weigh in with an opinion one way or another. If you are not agnostic about this I'd love to know your thoughts about this.

Thanks in advance...

ISCBorisB

Just noticed that you did not weigh in with an opinion one way or another. If you are not agnostic about this I'd love to know your thoughts about this.

Thanks in advance...

Personally, I would vote "for" having the "Y:" access.
Not only the cure is worse than the disease, as pointed by Ghoti and Nipper it's not even a cure

LeggMan

Personally, I would vote "for" having the "Y:" access.
Not only the cure is worse than the disease, as pointed by Ghoti and Nipper it's not even a cure

Thanks again to the bejeweled DevNetizens for chiming in!