[Micronet] OE Website quality

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Micronet] OE Website quality

Christopher Brooks
Is it just me, or are we getting lame websites in the name of OE?

Caltime requires logging in to a machine using RDP.  I see no mention of
the business reason for this.  In addition, the RDP file is
misconfigured, under Mac OS, I was prompted to share my disk? This was
brought up on Micronet, but was there any resolution?  This seems like a
huge security hole.

BearBuy is a pathetic pastiche of a website.  It is obvious that various
pieces have been tacked on. For example, draft carts are not found on
the left with the carts in process, one has to click in the far right..
BearBuy asks me every week or so  to click through a page about
personally identifiable information.  A more robust solution would be to
scan the data for PII. BearBuy's UI is far to complex for someone who
wants to simply purchase an couple of items.  The email that is sent has
no mention of what is being purchased (I'm told this will be fixed). The
PI cannot review authorizations. etc.

The campus Footprints configuration does not include the entire email
trail, nor does it have link to a website where a user may view the
trail. In addition, it seems to give no indication of who is getting
cc'd on a message.  Footprints seems to be configured to close tickets
quickly, not provide meaningful support.

Connexxus, the campus travel "solution" does not have a back button.  
Travelocity and Orbitz have a back button, why doesn't Connexxus?

Before OE, Blu was rolled out half done.  At the time it seemed like the
vendor needed a sale, and we were "it".

It seems like there is no user-acceptance testing of these sites. If we
put 10 users in front of these sites and recorded their observations, I
don't think they would be accepted as "done" and ready for use.

The issue is that once the purchase is made, Berkeley is put in the pool
with the rest of users and the odds of getting meaningful fixes is low.

Rather than continuing with the litany of shortcomings of these
products, as a group, could we have discussion about what sort of
changes should be made in the purchasing process to avoid these issues?  
Many of us are providing support to people who are using these sites, or
are using these sites ourselves, so getting these sites right is important.

My suggestion is user acceptance testing as a part of the purchase process.

Does anyone have any other concrete, positive suggestions for how to
purchase enterprise-wide websites?

_Christopher

--
Christopher Brooks, PMP                       University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841                                (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Bruce Satow
I've been mentioning the same issues.  I think some of the problems is that there is a big disconnect between IT groups.  I've tried to make a point of this for years. 

Basically I have been saying that there are three IT support groups here on campus with different needs.  Academic, Research(scientific), and Administrative.   Most of the people here, I feel tend to deal with more of the academic issues and the focus is toward them.

Sometimes I feel that campus doesn't understand this and tries to blanket the entire campus with the one size fits all solution, and not realizing the problems.  For example, I think RDP was used for Caltime because I think Caltime will not work on newer browsers.  Look at BFS, BearBuy, BAIRS, etc.  the only certified browsers are IE 8 and Firefox 3.5 or 3.6.

http://www.bai.berkeley.edu/support/SupportedOS_Browsers.htm

What's the business reason for this?  I don't think campus wants to spend money to update these campus business services to run on newer browsers, but rather leave it up to the IT department to figure out how to keep campus computer secure and still be able to provide access to these services.  I don't know if there is an UX desginer for campus online business apps.

Oh, b.t.w.  is your Mac RDP set to share your local disks?  I think you can turn off in some preference setting.  Then Caltime won't complain.

Someone told me that Bain wrote the OE report... is this rumor?  I dunno...





On 11/7/2012 4:22 PM, Christopher Brooks wrote:
Is it just me, or are we getting lame websites in the name of OE?

Caltime requires logging in to a machine using RDP.  I see no mention of 
the business reason for this.  In addition, the RDP file is 
misconfigured, under Mac OS, I was prompted to share my disk? This was 
brought up on Micronet, but was there any resolution?  This seems like a 
huge security hole.

BearBuy is a pathetic pastiche of a website.  It is obvious that various 
pieces have been tacked on. For example, draft carts are not found on 
the left with the carts in process, one has to click in the far right.. 
BearBuy asks me every week or so  to click through a page about 
personally identifiable information.  A more robust solution would be to 
scan the data for PII. BearBuy's UI is far to complex for someone who 
wants to simply purchase an couple of items.  The email that is sent has 
no mention of what is being purchased (I'm told this will be fixed). The 
PI cannot review authorizations. etc.

The campus Footprints configuration does not include the entire email 
trail, nor does it have link to a website where a user may view the 
trail. In addition, it seems to give no indication of who is getting 
cc'd on a message.  Footprints seems to be configured to close tickets 
quickly, not provide meaningful support.

Connexxus, the campus travel "solution" does not have a back button.  
Travelocity and Orbitz have a back button, why doesn't Connexxus?

Before OE, Blu was rolled out half done.  At the time it seemed like the 
vendor needed a sale, and we were "it".

It seems like there is no user-acceptance testing of these sites. If we 
put 10 users in front of these sites and recorded their observations, I 
don't think they would be accepted as "done" and ready for use.

The issue is that once the purchase is made, Berkeley is put in the pool 
with the rest of users and the odds of getting meaningful fixes is low.

Rather than continuing with the litany of shortcomings of these 
products, as a group, could we have discussion about what sort of 
changes should be made in the purchasing process to avoid these issues?  
Many of us are providing support to people who are using these sites, or 
are using these sites ourselves, so getting these sites right is important.

My suggestion is user acceptance testing as a part of the purchase process.

Does anyone have any other concrete, positive suggestions for how to 
purchase enterprise-wide websites?

_Christopher


--
Bruce Satow
University of California at Berkeley
Space Sciences Laboratory
7 Gauss Way
Berkeley, California 94720-7450
[hidden email]
(510) 643-2348

Si hoc legere scis nimium eruditionis habes


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Ian Crew

On Nov 8, 2012, at 12:37 PM, Bruce Satow <[hidden email]> wrote:

Someone told me that Bain wrote the OE report... is this rumor?  I dunno...

Yes, Bain and Company was involved with the OE diagnostic phase, at least according to http://oe.berkeley.edu/phase1/execsum.shtml.  Per http://en.wikipedia.org/wiki/Bain_%26_Company#Relationship_with_Bain_Capital that's a different company from the Bain Capital of notoriety in the recent presidential race.

Ian

___
Ian Crew
Platform and Services Manager, Research Hub

Content Management Technologies
IST-Architecture, Middleware and Common Applications
Earl Warren Hall, Second Floor
University of California, Berkeley


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Bruce Satow
Interestingly they are related though... in the 90's Mitt Romney was asked to rejoin and lead Bain & Co. as interim CEO.

http://en.wikipedia.org/wiki/Bain_%26_Company#1990s

anyways... I would like to mention that I was able to get a MAK from SHI under our campus Microsoft agreement.  I installed Win 8 64 bit on an older Athlon 64 X2 with 3 gb RAM on a 250 gb Seagate SATA drive and it runs extremely well.  Seems much more peppier than Win 7. 

UI is intuitive, more so than previous iterations although there is a learning curve on finding out what all the new locations of where things are, and customizations.  No need for a touch screen.

Windows 8 is starting to come in pre-installed on new computers and has Internet Explorer 10 pre-installed.

Not sure what campus is going to do regarding campus online business services (BearBuy, BFS, etc) in the long run.  I know that a remote app solution is being investigated but it seems like a short term solution or workaround to a continuing problem.  I am hoping that it will work.




On 11/8/2012 12:44 PM, Ian Crew wrote:

On Nov 8, 2012, at 12:37 PM, Bruce Satow <[hidden email]> wrote:

Someone told me that Bain wrote the OE report... is this rumor?  I dunno...

Yes, Bain and Company was involved with the OE diagnostic phase, at least according to http://oe.berkeley.edu/phase1/execsum.shtml.  Per http://en.wikipedia.org/wiki/Bain_%26_Company#Relationship_with_Bain_Capital that's a different company from the Bain Capital of notoriety in the recent presidential race.

Ian

___
Ian Crew
Platform and Services Manager, Research Hub

Content Management Technologies
IST-Architecture, Middleware and Common Applications
Earl Warren Hall, Second Floor
University of California, Berkeley


--
Bruce Satow
University of California at Berkeley
Space Sciences Laboratory
7 Gauss Way
Berkeley, California 94720-7450
[hidden email]
(510) 643-2348

Si hoc legere scis nimium eruditionis habes


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Michael Sinatra-3
In reply to this post by Bruce Satow
Part of the issue here is that there doesn't appear to be adequate
*technical* communication between the OE implementation groups and the
technical audience on campus.  Liz Marsh and others have done a fine job
of communicating high-level issues from the OCIO's perspective, and I
understand that OE and/or Shared Services have their own communication
team(s).  But that's not the issue I am talking about.

   * Basic questions, such as the *repeated* inquiries to Micronet as to
how mail will be forwarded once bMail is implemented, have simply gone
unanswered (after Gabriel's answer about a year ago, which now seems to
be incongruent with what is actually being implemented).  Most recently,
I asked, via Micronet, someone to clarify the issue and it has been
almost *two weeks* with no answer.  This isn't a big issue for me, as I
will likely cancel my calmail account rather than migrate it, but I can
see it being a problem for those who are on mailing lists with security
and privacy concerns that cause them to prohibit use of third-party
"free" mail services.

   * Christopher raises good questions that have also repeatedly been
discussed on Micronet.  Caltime is an example: Why does it need to be in
campus-routable RFC1918 space?  There may be a very good reason for
this, but nobody has bothered to communicate that reason.  Why does it
require RDP?  Again, could be good reasons, but who knows?

I don't know as much about the other issues, but the all seem to have
causes: There is no transparency in the technical decision making
process.  We (the Micronet community) don't know what decisions are
being made, we can't contribute to the decisions, despite the impressive
technical knowledge-base of Micronet, and we don't even know when a
decision has been made or why!  I am kind of surprised at the deafening
silence.  Micronet used to be a place where we hashed out technical
service questions like these--with the service providers actively
participating.

michael

On 11/8/12 12:37 PM, Bruce Satow wrote:

> I've been mentioning the same issues.  I think some of the problems is
> that there is a big disconnect between IT groups.  I've tried to make a
> point of this for years.
>
> Basically I have been saying that there are three IT support groups here
> on campus with different needs.  Academic, Research(scientific), and
> Administrative.   Most of the people here, I feel tend to deal with more
> of the academic issues and the focus is toward them.
>
> Sometimes I feel that campus doesn't understand this and tries to
> blanket the entire campus with the one size fits all solution, and not
> realizing the problems.  For example, I think RDP was used for Caltime
> because I think Caltime will not work on newer browsers.  Look at BFS,
> BearBuy, BAIRS, etc.  the only certified browsers are IE 8 and Firefox
> 3.5 or 3.6.
>
> http://www.bai.berkeley.edu/support/SupportedOS_Browsers.htm
>
> What's the business reason for this?  I don't think campus wants to
> spend money to update these campus business services to run on newer
> browsers, but rather leave it up to the IT department to figure out how
> to keep campus computer secure and still be able to provide access to
> these services.  I don't know if there is an UX desginer for campus
> online business apps.
>
> Oh, b.t.w.  is your Mac RDP set to share your local disks?  I think you
> can turn off in some preference setting.  Then Caltime won't complain.
>
> Someone told me that Bain wrote the OE report... is this rumor?  I dunno...
>
>
>
>
>
> On 11/7/2012 4:22 PM, Christopher Brooks wrote:
>> Is it just me, or are we getting lame websites in the name of OE?
>>
>> Caltime requires logging in to a machine using RDP.  I see no mention of
>> the business reason for this.  In addition, the RDP file is
>> misconfigured, under Mac OS, I was prompted to share my disk? This was
>> brought up on Micronet, but was there any resolution?  This seems like a
>> huge security hole.
>>
>> BearBuy is a pathetic pastiche of a website.  It is obvious that various
>> pieces have been tacked on. For example, draft carts are not found on
>> the left with the carts in process, one has to click in the far right..
>> BearBuy asks me every week or so  to click through a page about
>> personally identifiable information.  A more robust solution would be to
>> scan the data for PII. BearBuy's UI is far to complex for someone who
>> wants to simply purchase an couple of items.  The email that is sent has
>> no mention of what is being purchased (I'm told this will be fixed). The
>> PI cannot review authorizations. etc.
>>
>> The campus Footprints configuration does not include the entire email
>> trail, nor does it have link to a website where a user may view the
>> trail. In addition, it seems to give no indication of who is getting
>> cc'd on a message.  Footprints seems to be configured to close tickets
>> quickly, not provide meaningful support.
>>
>> Connexxus, the campus travel "solution" does not have a back button.  
>> Travelocity and Orbitz have a back button, why doesn't Connexxus?
>>
>> Before OE, Blu was rolled out half done.  At the time it seemed like the
>> vendor needed a sale, and we were "it".
>>
>> It seems like there is no user-acceptance testing of these sites. If we
>> put 10 users in front of these sites and recorded their observations, I
>> don't think they would be accepted as "done" and ready for use.
>>
>> The issue is that once the purchase is made, Berkeley is put in the pool
>> with the rest of users and the odds of getting meaningful fixes is low.
>>
>> Rather than continuing with the litany of shortcomings of these
>> products, as a group, could we have discussion about what sort of
>> changes should be made in the purchasing process to avoid these issues?  
>> Many of us are providing support to people who are using these sites, or
>> are using these sites ourselves, so getting these sites right is important.
>>
>> My suggestion is user acceptance testing as a part of the purchase process.
>>
>> Does anyone have any other concrete, positive suggestions for how to
>> purchase enterprise-wide websites?
>>
>> _Christopher
>>
>
> --
> *Bruce Satow*
> University of California at Berkeley
> Space Sciences Laboratory
> 7 Gauss Way
> Berkeley, California 94720-7450
> [hidden email] <mailto:[hidden email]>
> (510) 643-2348
>
> /Si hoc legere scis nimium eruditionis habes/
>
>
>
>  
> -------------------------------------------------------------------------
> The following was automatically added to this message by the list server:
>
> To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:
>
> http://micronet.berkeley.edu
>
> Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
>


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

paul rivers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


This doesn't really address your overall point about technical
communication or transparency.  But in the interest of speaking to
some of your specific example issues, I can add a comment or two on
each in spite of not being on the project team of either.  Comments
inline below:


On 11/19/2012 08:56 AM, Michael Sinatra wrote:

> Part of the issue here is that there doesn't appear to be adequate
>  *technical* communication between the OE implementation groups
> and the technical audience on campus.  Liz Marsh and others have
> done a fine job of communicating high-level issues from the OCIO's
> perspective, and I understand that OE and/or Shared Services have
> their own communication team(s).  But that's not the issue I am
> talking about.
>
> * Basic questions, such as the *repeated* inquiries to Micronet as
> to how mail will be forwarded once bMail is implemented, have
> simply gone unanswered (after Gabriel's answer about a year ago,
> which now seems to be incongruent with what is actually being
> implemented).  Most recently, I asked, via Micronet, someone to
> clarify the issue and it has been almost *two weeks* with no
> answer.  This isn't a big issue for me, as I will likely cancel my
> calmail account rather than migrate it, but I can see it being a
> problem for those who are on mailing lists with security and
> privacy concerns that cause them to prohibit use of third-party
> "free" mail services.

I took a renewed interest based on that email, because it sounded as
if the decision was made to move the berkeley.edu MX record
off-campus.  It turns out that's not the case: the MX record will
remain on-campus.

The calmail self-service web management portal to do things like
maintain forwards will almost surely not remain as is, however.  So
while berkeley.edu mail will first arrive at Berkeley before going to
Google, you would setup any forwards on the Google side.


> * Christopher raises good questions that have also repeatedly been
>  discussed on Micronet.  Caltime is an example: Why does it need
> to be in campus-routable RFC1918 space?  There may be a very good
> reason for this, but nobody has bothered to communicate that
> reason.  Why does it require RDP?  Again, could be good reasons,
> but who knows?

I don't know about the RFC1918 issue, and could only guess.

On RDP, I suspect (but do not know) this is is due to out of date
software required for the system.  The intention is probably to keep
out of date software from being installed on numerous desktops around
campus.

We (campus security) have started a conversation with the Caltime
folks to see if we can look at the RDP file they are using, so that it
addresses the concerns raised on Micronet.


> I don't know as much about the other issues, but the all seem to
> have causes: There is no transparency in the technical decision
> making process.  We (the Micronet community) don't know what
> decisions are being made, we can't contribute to the decisions,
> despite the impressive technical knowledge-base of Micronet, and
> we don't even know when a decision has been made or why!  I am kind
> of surprised at the deafening silence.  Micronet used to be a
> place where we hashed out technical service questions like
> these--with the service providers actively participating.
>
> michael
>
> On 11/8/12 12:37 PM, Bruce Satow wrote:
>> I've been mentioning the same issues.  I think some of the
>> problems is that there is a big disconnect between IT groups.
>> I've tried to make a point of this for years.
>>
>> Basically I have been saying that there are three IT support
>> groups here on campus with different needs.  Academic,
>> Research(scientific), and Administrative.   Most of the people
>> here, I feel tend to deal with more of the academic issues and
>> the focus is toward them.
>>
>> Sometimes I feel that campus doesn't understand this and tries to
>> blanket the entire campus with the one size fits all solution,
>> and not realizing the problems.  For example, I think RDP was
>> used for Caltime because I think Caltime will not work on newer
>> browsers.  Look at BFS, BearBuy, BAIRS, etc.  the only certified
>> browsers are IE 8 and Firefox 3.5 or 3.6.
>>
>> http://www.bai.berkeley.edu/support/SupportedOS_Browsers.htm
>>
>> What's the business reason for this?  I don't think campus wants
>> to spend money to update these campus business services to run
>> on newer browsers, but rather leave it up to the IT department
>> to figure out how to keep campus computer secure and still be
>> able to provide access to these services.  I don't know if there
>> is an UX desginer for campus online business apps.
>>
>> Oh, b.t.w.  is your Mac RDP set to share your local disks?  I
>> think you can turn off in some preference setting.  Then Caltime
>> won't complain.
>>
>> Someone told me that Bain wrote the OE report... is this rumor? I
>> dunno...
>>
>>
>>
>>
>>
>> On 11/7/2012 4:22 PM, Christopher Brooks wrote:
>>> Is it just me, or are we getting lame websites in the name of
>>> OE?
>>>
>>> Caltime requires logging in to a machine using RDP.  I see no
>>> mention of the business reason for this.  In addition, the RDP
>>> file is misconfigured, under Mac OS, I was prompted to share
>>> my disk? This was brought up on Micronet, but was there any
>>> resolution?  This seems like a huge security hole.
>>>
>>> BearBuy is a pathetic pastiche of a website.  It is obvious
>>> that various pieces have been tacked on. For example, draft
>>> carts are not found on the left with the carts in process, one
>>> has to click in the far right.. BearBuy asks me every week or
>>> so  to click through a page about personally identifiable
>>> information.  A more robust solution would be to scan the data
>>> for PII. BearBuy's UI is far to complex for someone who wants
>>> to simply purchase an couple of items.  The email that is sent
>>> has no mention of what is being purchased (I'm told this will
>>> be fixed). The PI cannot review authorizations. etc.
>>>
>>> The campus Footprints configuration does not include the
>>> entire email trail, nor does it have link to a website where a
>>> user may view the trail. In addition, it seems to give no
>>> indication of who is getting cc'd on a message.  Footprints
>>> seems to be configured to close tickets quickly, not provide
>>> meaningful support.
>>>
>>> Connexxus, the campus travel "solution" does not have a back
>>> button. Travelocity and Orbitz have a back button, why doesn't
>>> Connexxus?
>>>
>>> Before OE, Blu was rolled out half done.  At the time it
>>> seemed like the vendor needed a sale, and we were "it".
>>>
>>> It seems like there is no user-acceptance testing of these
>>> sites. If we put 10 users in front of these sites and recorded
>>> their observations, I don't think they would be accepted as
>>> "done" and ready for use.
>>>
>>> The issue is that once the purchase is made, Berkeley is put
>>> in the pool with the rest of users and the odds of getting
>>> meaningful fixes is low.
>>>
>>> Rather than continuing with the litany of shortcomings of
>>> these products, as a group, could we have discussion about what
>>> sort of changes should be made in the purchasing process to
>>> avoid these issues? Many of us are providing support to people
>>> who are using these sites, or are using these sites ourselves,
>>> so getting these sites right is important.
>>>
>>> My suggestion is user acceptance testing as a part of the
>>> purchase process.
>>>
>>> Does anyone have any other concrete, positive suggestions for
>>> how to purchase enterprise-wide websites?
>>>
>>> _Christopher
>>>
>>
>> -- *Bruce Satow* University of California at Berkeley Space
>> Sciences Laboratory 7 Gauss Way Berkeley, California 94720-7450
>> [hidden email] <mailto:[hidden email]> (510)
>> 643-2348
>>
>> /Si hoc legere scis nimium eruditionis habes/
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>>
>>
>>
The following was automatically added to this message by the list server:

>>
>> To learn more about Micronet, including how to subscribe to or
>> unsubscribe from its mailing list and how to find out about
>> upcoming meetings, please visit the Micronet Web site:
>>
>> http://micronet.berkeley.edu
>>
>> Messages you send to this mailing list are public and
>> world-viewable, and the list's archives can be browsed and
>> searched on the Internet.  This means these messages can be
>> viewed by (among others) your bosses, prospective employers, and
>> people who have known you in the past.
>>
>
>
>
> -------------------------------------------------------------------------
>
>
>
The following was automatically added to this message by the list server:

>
> To learn more about Micronet, including how to subscribe to or
> unsubscribe from its mailing list and how to find out about
> upcoming meetings, please visit the Micronet Web site:
>
> http://micronet.berkeley.edu
>
> Messages you send to this mailing list are public and
> world-viewable, and the list's archives can be browsed and
> searched on the Internet.  This means these messages can be viewed
> by (among others) your bosses, prospective employers, and people
> who have known you in the past.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlCqc4MACgkQLLt1RCPoUIydnQCgvYIOC0oKFAbI/QpdxKD7uUgG
pv4AoOR7K1wWF6uqYmkq95QsfUiVHsAx
=YPvT
-----END PGP SIGNATURE-----

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Michael Sinatra-3
On 11/19/12 9:59 AM, paul rivers wrote:
>
> This doesn't really address your overall point about technical
> communication or transparency.  But in the interest of speaking to
> some of your specific example issues, I can add a comment or two on
> each in spite of not being on the project team of either.  Comments
> inline below:

Thanks for taking the time to answer, Paul.  As you can imagine, this
raises more questions, which I address to you, but I realize that you
probably don't have the answers and that the appropriate OE project
implementation group does.  Still hoping to get a response from them.

[snip]

> I took a renewed interest based on that email, because it sounded as
> if the decision was made to move the berkeley.edu MX record
> off-campus.  It turns out that's not the case: the MX record will
> remain on-campus.
>
> The calmail self-service web management portal to do things like
> maintain forwards will almost surely not remain as is, however.  

Why?  Is it really that hard to maintain?

> So
> while berkeley.edu mail will first arrive at Berkeley before going to
> Google, you would setup any forwards on the Google side.

I guess my question then is, why bother keeping the MX record on campus
if the mail is just going to go to Google regardless of a user's
forwarding configuration?  In this case, the Berkeley MX serves only to
obfuscate the destination of the email.  Moreover, by just switching to
a Google MX, UCB would have a dual-stack (IPv4/IPv6) MX, something it
has needed for a while.  Two birds with one stone...

>> * Christopher raises good questions that have also repeatedly been
>>  discussed on Micronet.  Caltime is an example: Why does it need
>> to be in campus-routable RFC1918 space?  There may be a very good
>> reason for this, but nobody has bothered to communicate that
>> reason.  Why does it require RDP?  Again, could be good reasons,
>> but who knows?
>
> I don't know about the RFC1918 issue, and could only guess.

I am betting that there was a desire to "force" the use of the VPN or
similar pre-authentication mechanism before getting to the service.
RFC1918 forces this issue, while saving globally-routable IPv4
addresses.  To me, this seems like a reasonable decision, but that's
because I am trying to infer a logical decision from an implementation
detail. Hence my point... :)

> On RDP, I suspect (but do not know) this is is due to out of date
> software required for the system.  The intention is probably to keep
> out of date software from being installed on numerous desktops around
> campus.
>
> We (campus security) have started a conversation with the Caltime
> folks to see if we can look at the RDP file they are using, so that it
> addresses the concerns raised on Micronet.

michael


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

jon kuroda-2
In reply to this post by paul rivers
On Mon, Nov 19, 2012 at 09:59:32AM -0800, paul rivers wrote:
[trimmed for brevity]
...
> On 11/19/2012 08:56 AM, Michael Sinatra wrote:
...

> > * Christopher raises good questions that have also repeatedly been
> >  discussed on Micronet.  Caltime is an example: Why does it need
> > to be in campus-routable RFC1918 space?  There may be a very good
> > reason for this, but nobody has bothered to communicate that
> > reason.  Why does it require RDP?  Again, could be good reasons,
> > but who knows?
>
> I don't know about the RFC1918 issue, and could only guess.
>
> On RDP, I suspect (but do not know) this is is due to out of date
> software required for the system.  The intention is probably to keep
> out of date software from being installed on numerous desktops around
> campus.
>
> We (campus security) have started a conversation with the Caltime
> folks to see if we can look at the RDP file they are using, so that it
> addresses the concerns raised on Micronet.

I have gotten uncomfortably used to (read: apathetic about) the lack of
transparency in campus-wide technology and other decisions. That things
like CalTime make it to PrimeTime as 'fait (ne pas) accompli' no longer
fazes me; it just reminds me of the words of a former manager of mine:

  I am not disappointed - I am displeased.
  Disappointment would imply I had expectations of something better.

What does disappoint me is that CalTime apparently did not consult with
Campus Security on the design and deployment of this service - at least
it seems that way to me if Campus Security is in the position of having
to start a conversation with the CalTime Team ex post facto.

If the version of Kronos Workforce Central used for CalTime is outdated
then I would have thought it would required getting an exception to the
Campus MSSND from Campus Security:

- 1. Software Patch Updates

- Campus networked devices must only run software for which security
- patches are made available in a timely fashion.  All currently
- available security patches must be applied on a schedule appropriate
- to the severity of the risk they mitigat

To me, this raises the question of "Did CalTime get any security review
by an external party - at a minimum someone other than the CalTime team
or the vendor - before going Primetime?"

Curmudgeonly, Jon

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

paul rivers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/19/2012 11:17 AM, jon kuroda wrote:

> On Mon, Nov 19, 2012 at 09:59:32AM -0800, paul rivers wrote:
> [trimmed for brevity] ...
>> On 11/19/2012 08:56 AM, Michael Sinatra wrote:
> ...
>>> * Christopher raises good questions that have also repeatedly
>>> been discussed on Micronet.  Caltime is an example: Why does it
>>> need to be in campus-routable RFC1918 space?  There may be a
>>> very good reason for this, but nobody has bothered to
>>> communicate that reason.  Why does it require RDP?  Again,
>>> could be good reasons, but who knows?
>>
>> I don't know about the RFC1918 issue, and could only guess.
>>
>> On RDP, I suspect (but do not know) this is is due to out of
>> date software required for the system.  The intention is probably
>> to keep out of date software from being installed on numerous
>> desktops around campus.
>>
>> We (campus security) have started a conversation with the
>> Caltime folks to see if we can look at the RDP file they are
>> using, so that it addresses the concerns raised on Micronet.
>
> I have gotten uncomfortably used to (read: apathetic about) the
> lack of transparency in campus-wide technology and other decisions.
> That things like CalTime make it to PrimeTime as 'fait (ne pas)
> accompli' no longer fazes me; it just reminds me of the words of a
> former manager of mine:
>
> I am not disappointed - I am displeased. Disappointment would imply
> I had expectations of something better.
>
> What does disappoint me is that CalTime apparently did not consult
> with Campus Security on the design and deployment of this service -
> at least it seems that way to me if Campus Security is in the
> position of having to start a conversation with the CalTime Team ex
> post facto.
>
> If the version of Kronos Workforce Central used for CalTime is
> outdated then I would have thought it would required getting an
> exception to the Campus MSSND from Campus Security:
>
> - 1. Software Patch Updates
>
> - Campus networked devices must only run software for which
> security - patches are made available in a timely fashion.  All
> currently - available security patches must be applied on a
> schedule appropriate - to the severity of the risk they mitigat
>
> To me, this raises the question of "Did CalTime get any security
> review by an external party - at a minimum someone other than the
> CalTime team or the vendor - before going Primetime?"
>
> Curmudgeonly, Jon
>
>

To be fair to Caltime, some of the responsibility here is on security.

In the past, we were missing a number of prerequisites that would
allow us to do a security review of a system such as CalTime prior to
deployment.  Those missing things:

1) Sufficient staff to do assessments, consulting and/or write guidelines

2) A clear data classification standard

3) Data security standards for each protection level in the campus
data classification standard

4) Focus campus info-sec budget on implementing campus-level programs
to help units meet the requirements in #3 (i.e. avoid the "unfunded
mandate" where possible for complex or expensive controls)

5) Formalize an overall information system risk management process so
that procurement, the technology program office, etc., are aware of
security requirements early in the build/buy process

We've made some headway all of these, with of course much more to do:

- - We've hired several new staff in the last year, who are now engaged
in doing these assessments, consulting, and writing guidelines.

- - Our Policy Officer has published he data classification standard,
which you can see at https://security.berkeley.edu/data-classification

- - A data security standard for protection level 2 data is approved and
will take effect this coming summer.  You can read about that at
https://security.berkeley.edu/mssei

- - There is an effort underway to complete the data security standard
for protection level 1 data now.  If you are interested in following
this or making suggestions, please consider both attending Security
Operations Workgroup meetings (https://security.berkeley.edu/node/95)
or subscribing to UCB-security
(https://security.berkeley.edu/ucb-security).  If you don't want to do
either of those, I'm sure Lisa Ho ([hidden email]), our Policy
Officer, would take your comments directly.

- - SNS is implementing log correlation and application security testing
to help campus meet the protection level 2 security requirements.  You
can read a summary of the application security testing program at
https://security.berkeley.edu/astp.  If you have protection level 2
systems, be sure they are registered in the campus RDM, and SNS will
make sure you get scheduled for these services.

- - We (security, policy) have just started outreach efforts to talk to
the TPO, ITLG, on the evolving information risk management process,
and putting hooks into early parts of the build/buy cycle.  There have
been discussions already with the TPO, and there is an upcoming
discussion to the ITLG on this topic.


If you are interested in more detail on the above, I am happy to talk
with you online or offline.

But the gist of this is we've not really been in a position to
properly assess risk to information systems in a more systematic and
comprehensive way.  But that's exactly what we're working to do now.
It'll take some time before we're ahead of the curve and can both do a
risk assessment on and provide a more complete set of security
services for all new campus-level systems or protection level 2 or 3
systems before they are in production.

Regards,
Paul



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlCqkNMACgkQLLt1RCPoUIwrowCeIjO62UD6Uim5WjeUYZI9LzSY
+GsAni3lq9GhR0NJIvjOnucikok0OTu2
=0TiF
-----END PGP SIGNATURE-----

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Lynne Grigsby
I understand the difficulties but one of the things I find frustrating on campus is that no one seems to ask or consult other groups. The Library was (one of) the beta testers of Kronos and so we have been using it for months.  My unit has been complaining for months that Kronos wants a version of java that we don't have as our machines get upgraded.  We have ONE computer in our unit that we can all use Kronos to log our leave. 

No one has asked us what we think of the system, any IT issues, etc.  So, even without staffing, some of these blatant security issues would have been discovered if we had been asked.

Lynne


On 11/19/2012 12:04 PM, paul rivers wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/19/2012 11:17 AM, jon kuroda wrote:
On Mon, Nov 19, 2012 at 09:59:32AM -0800, paul rivers wrote: 
[trimmed for brevity] ...
On 11/19/2012 08:56 AM, Michael Sinatra wrote:
...
* Christopher raises good questions that have also repeatedly
been discussed on Micronet.  Caltime is an example: Why does it
need to be in campus-routable RFC1918 space?  There may be a
very good reason for this, but nobody has bothered to
communicate that reason.  Why does it require RDP?  Again,
could be good reasons, but who knows?
I don't know about the RFC1918 issue, and could only guess.

On RDP, I suspect (but do not know) this is is due to out of
date software required for the system.  The intention is probably
to keep out of date software from being installed on numerous
desktops around campus.

We (campus security) have started a conversation with the
Caltime folks to see if we can look at the RDP file they are
using, so that it addresses the concerns raised on Micronet.
I have gotten uncomfortably used to (read: apathetic about) the
lack of transparency in campus-wide technology and other decisions.
That things like CalTime make it to PrimeTime as 'fait (ne pas)
accompli' no longer fazes me; it just reminds me of the words of a
former manager of mine:

I am not disappointed - I am displeased. Disappointment would imply
I had expectations of something better.

What does disappoint me is that CalTime apparently did not consult
with Campus Security on the design and deployment of this service -
at least it seems that way to me if Campus Security is in the
position of having to start a conversation with the CalTime Team ex
post facto.

If the version of Kronos Workforce Central used for CalTime is
outdated then I would have thought it would required getting an
exception to the Campus MSSND from Campus Security:

- 1. Software Patch Updates

- Campus networked devices must only run software for which
security - patches are made available in a timely fashion.  All
currently - available security patches must be applied on a
schedule appropriate - to the severity of the risk they mitigat

To me, this raises the question of "Did CalTime get any security
review by an external party - at a minimum someone other than the
CalTime team or the vendor - before going Primetime?"

Curmudgeonly, Jon


To be fair to Caltime, some of the responsibility here is on security.

In the past, we were missing a number of prerequisites that would
allow us to do a security review of a system such as CalTime prior to
deployment.  Those missing things:

1) Sufficient staff to do assessments, consulting and/or write guidelines

2) A clear data classification standard

3) Data security standards for each protection level in the campus
data classification standard

4) Focus campus info-sec budget on implementing campus-level programs
to help units meet the requirements in #3 (i.e. avoid the "unfunded
mandate" where possible for complex or expensive controls)

5) Formalize an overall information system risk management process so
that procurement, the technology program office, etc., are aware of
security requirements early in the build/buy process

We've made some headway all of these, with of course much more to do:

- - We've hired several new staff in the last year, who are now engaged
in doing these assessments, consulting, and writing guidelines.

- - Our Policy Officer has published he data classification standard,
which you can see at https://security.berkeley.edu/data-classification

- - A data security standard for protection level 2 data is approved and
will take effect this coming summer.  You can read about that at
https://security.berkeley.edu/mssei

- - There is an effort underway to complete the data security standard
for protection level 1 data now.  If you are interested in following
this or making suggestions, please consider both attending Security
Operations Workgroup meetings (https://security.berkeley.edu/node/95)
or subscribing to UCB-security
(https://security.berkeley.edu/ucb-security).  If you don't want to do
either of those, I'm sure Lisa Ho ([hidden email]), our Policy
Officer, would take your comments directly.

- - SNS is implementing log correlation and application security testing
to help campus meet the protection level 2 security requirements.  You
can read a summary of the application security testing program at
https://security.berkeley.edu/astp.  If you have protection level 2
systems, be sure they are registered in the campus RDM, and SNS will
make sure you get scheduled for these services.

- - We (security, policy) have just started outreach efforts to talk to
the TPO, ITLG, on the evolving information risk management process,
and putting hooks into early parts of the build/buy cycle.  There have
been discussions already with the TPO, and there is an upcoming
discussion to the ITLG on this topic.


If you are interested in more detail on the above, I am happy to talk
with you online or offline.

But the gist of this is we've not really been in a position to
properly assess risk to information systems in a more systematic and
comprehensive way.  But that's exactly what we're working to do now.
It'll take some time before we're ahead of the curve and can both do a
risk assessment on and provide a more complete set of security
services for all new campus-level systems or protection level 2 or 3
systems before they are in production.

Regards,
Paul



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlCqkNMACgkQLLt1RCPoUIwrowCeIjO62UD6Uim5WjeUYZI9LzSY
+GsAni3lq9GhR0NJIvjOnucikok0OTu2
=0TiF
-----END PGP SIGNATURE-----

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.




 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Rune Stromsness
In reply to this post by jon kuroda-2
On 19-Nov-12 11:17, jon kuroda wrote:
> On Mon, Nov 19, 2012 at 09:59:32AM -0800, paul rivers wrote:
> [trimmed for brevity]
> ...
>> On 11/19/2012 08:56 AM, Michael Sinatra wrote:
> ...
[...]
> What does disappoint me is that CalTime apparently did not consult with
> Campus Security on the design and deployment of this service - at least
> it seems that way to me if Campus Security is in the position of having
> to start a conversation with the CalTime Team ex post facto.
>
> If the version of Kronos Workforce Central used for CalTime is outdated

I know that Kronos is infamous for requiring old versions of browsers
and/or Java in order to run their full client.  So while Kronos may be
up-to-date there is a good chance that it requires other software to not
be patched.

> then I would have thought it would required getting an exception to the
> Campus MSSND from Campus Security:
>
> - 1. Software Patch Updates
>
> - Campus networked devices must only run software for which security
> - patches are made available in a timely fashion.  All currently
> - available security patches must be applied on a schedule appropriate
> - to the severity of the risk they mitigat
>
> To me, this raises the question of "Did CalTime get any security review
> by an external party - at a minimum someone other than the CalTime team
> or the vendor - before going Primetime?"
It would also seem that using terminal servers like this

"Systems that are most often accessed remotely and are exposed to more
than 50 unique CalNet IDs per day, such as terminal services machines
and..."

https://wikihub.berkeley.edu/display/calnet/Proxied+CalNet+Authentication+Exception+Requests

should trigger the requirement for a review by the CalNet Tech team
regarding proxied authentication and then a decision by CISPC on whether
the proxied authentication is allowed or not.


Rune


> Curmudgeonly, Jon
>
>  
> -------------------------------------------------------------------------
> The following was automatically added to this message by the list server:
>
> To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:
>
> http://micronet.berkeley.edu
>
> Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
>


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.

signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Greg Merritt
In reply to this post by Michael Sinatra-3

On Nov 19, 2012, at 10:21 AM, Michael Sinatra wrote:

>> I don't know about the RFC1918 issue, and could only guess.
>
> I am betting that there was a desire to "force" the use of the VPN or
> similar pre-authentication mechanism before getting to the service.
> RFC1918 forces this issue, while saving globally-routable IPv4
> addresses.  To me, this seems like a reasonable decision, but that's
> because I am trying to infer a logical decision from an implementation
> detail. Hence my point... :)



We're promised, soon, an updated CalTime.rdp file that will point to the non-RFC1918 of the load balancer in front of the "real" CalTime servers.  Up until now, the "test" machine, at an RFC1918 address, has been what we early-movers-to-CalTime have been using to enter and approve leave time.

-Greg
 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Yolanda Jaggers
In reply to this post by Lynne Grigsby

Lynne,

 

With the roll out of Caltime you will no longer need to worry about what version of Java is on your desktop.  The deployment method Caltime uses was not an option when Kronos v6.1 was rolled out to Library. As a result, Caltime will be accessible from any pc in your unit.

 

Yolanda C. Jaggers[hidden email]

University of California, Berkeley

Information Services Technology - EAS- PPS

Bancroft Building - 5th floor, 502D

2111 Bancroft Way

Berkeley, CA 94720-3814

Phone: 510.643.5013

Fax: 510.643.2925

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Lynne Grigsby
Sent: Monday, November 19, 2012 12:45 PM
To: paul rivers
Cc: [hidden email]
Subject: Re: [Micronet] OE Website quality

 

I understand the difficulties but one of the things I find frustrating on campus is that no one seems to ask or consult other groups. The Library was (one of) the beta testers of Kronos and so we have been using it for months.  My unit has been complaining for months that Kronos wants a version of java that we don't have as our machines get upgraded.  We have ONE computer in our unit that we can all use Kronos to log our leave. 

No one has asked us what we think of the system, any IT issues, etc.  So, even without staffing, some of these blatant security issues would have been discovered if we had been asked.

Lynne

On 11/19/2012 12:04 PM, paul rivers wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
On 11/19/2012 11:17 AM, jon kuroda wrote:
On Mon, Nov 19, 2012 at 09:59:32AM -0800, paul rivers wrote: 
[trimmed for brevity] ...
On 11/19/2012 08:56 AM, Michael Sinatra wrote:
...
* Christopher raises good questions that have also repeatedly
been discussed on Micronet.  Caltime is an example: Why does it
need to be in campus-routable RFC1918 space?  There may be a
very good reason for this, but nobody has bothered to
communicate that reason.  Why does it require RDP?  Again,
could be good reasons, but who knows?
 
I don't know about the RFC1918 issue, and could only guess.
 
On RDP, I suspect (but do not know) this is is due to out of
date software required for the system.  The intention is probably
to keep out of date software from being installed on numerous
desktops around campus.
 
We (campus security) have started a conversation with the
Caltime folks to see if we can look at the RDP file they are
using, so that it addresses the concerns raised on Micronet.
 
I have gotten uncomfortably used to (read: apathetic about) the
lack of transparency in campus-wide technology and other decisions.
That things like CalTime make it to PrimeTime as 'fait (ne pas)
accompli' no longer fazes me; it just reminds me of the words of a
former manager of mine:
 
I am not disappointed - I am displeased. Disappointment would imply
I had expectations of something better.
 
What does disappoint me is that CalTime apparently did not consult
with Campus Security on the design and deployment of this service -
at least it seems that way to me if Campus Security is in the
position of having to start a conversation with the CalTime Team ex
post facto.
 
If the version of Kronos Workforce Central used for CalTime is
outdated then I would have thought it would required getting an
exception to the Campus MSSND from Campus Security:
 
- 1. Software Patch Updates
 
- Campus networked devices must only run software for which
security - patches are made available in a timely fashion.  All
currently - available security patches must be applied on a
schedule appropriate - to the severity of the risk they mitigat
 
To me, this raises the question of "Did CalTime get any security
review by an external party - at a minimum someone other than the
CalTime team or the vendor - before going Primetime?"
 
Curmudgeonly, Jon
 
 
 
To be fair to Caltime, some of the responsibility here is on security.
 
In the past, we were missing a number of prerequisites that would
allow us to do a security review of a system such as CalTime prior to
deployment.  Those missing things:
 
1) Sufficient staff to do assessments, consulting and/or write guidelines
 
2) A clear data classification standard
 
3) Data security standards for each protection level in the campus
data classification standard
 
4) Focus campus info-sec budget on implementing campus-level programs
to help units meet the requirements in #3 (i.e. avoid the "unfunded
mandate" where possible for complex or expensive controls)
 
5) Formalize an overall information system risk management process so
that procurement, the technology program office, etc., are aware of
security requirements early in the build/buy process
 
We've made some headway all of these, with of course much more to do:
 
- - We've hired several new staff in the last year, who are now engaged
in doing these assessments, consulting, and writing guidelines.
 
- - Our Policy Officer has published he data classification standard,
which you can see at https://security.berkeley.edu/data-classification
 
- - A data security standard for protection level 2 data is approved and
will take effect this coming summer.  You can read about that at
https://security.berkeley.edu/mssei
 
- - There is an effort underway to complete the data security standard
for protection level 1 data now.  If you are interested in following
this or making suggestions, please consider both attending Security
Operations Workgroup meetings (https://security.berkeley.edu/node/95)
or subscribing to UCB-security
(https://security.berkeley.edu/ucb-security).  If you don't want to do
either of those, I'm sure Lisa Ho ([hidden email]), our Policy
Officer, would take your comments directly.
 
- - SNS is implementing log correlation and application security testing
to help campus meet the protection level 2 security requirements.  You
can read a summary of the application security testing program at
https://security.berkeley.edu/astp.  If you have protection level 2
systems, be sure they are registered in the campus RDM, and SNS will
make sure you get scheduled for these services.
 
- - We (security, policy) have just started outreach efforts to talk to
the TPO, ITLG, on the evolving information risk management process,
and putting hooks into early parts of the build/buy cycle.  There have
been discussions already with the TPO, and there is an upcoming
discussion to the ITLG on this topic.
 
 
If you are interested in more detail on the above, I am happy to talk
with you online or offline.
 
But the gist of this is we've not really been in a position to
properly assess risk to information systems in a more systematic and
comprehensive way.  But that's exactly what we're working to do now.
It'll take some time before we're ahead of the curve and can both do a
risk assessment on and provide a more complete set of security
services for all new campus-level systems or protection level 2 or 3
systems before they are in production.
 
Regards,
Paul
 
 
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
 
iEYEARECAAYFAlCqkNMACgkQLLt1RCPoUIwrowCeIjO62UD6Uim5WjeUYZI9LzSY
+GsAni3lq9GhR0NJIvjOnucikok0OTu2
=0TiF
-----END PGP SIGNATURE-----
 
 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:
 
To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:
 
http://micronet.berkeley.edu
 
Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
 
 

 


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Lucy Greco
In reply to this post by Rune Stromsness
really people its getting to hard to follow this thread. i have no
idea what any of you are saying any more . as far as i can tell the
last ten messages on this thread have been so and so said and so on
what are you all saying i know you all hate top posting but this is
incredibly hard to read and your all saying OE can't communicate well
say what you want to say then quote others expletive !!!!!

On 11/19/12, Rune Stromsness <[hidden email]> wrote:

> On 19-Nov-12 11:17, jon kuroda wrote:
>> On Mon, Nov 19, 2012 at 09:59:32AM -0800, paul rivers wrote:
>> [trimmed for brevity]
>> ...
>>> On 11/19/2012 08:56 AM, Michael Sinatra wrote:
>> ...
> [...]
>> What does disappoint me is that CalTime apparently did not consult with
>> Campus Security on the design and deployment of this service - at least
>> it seems that way to me if Campus Security is in the position of having
>> to start a conversation with the CalTime Team ex post facto.
>>
>> If the version of Kronos Workforce Central used for CalTime is outdated
>
> I know that Kronos is infamous for requiring old versions of browsers
> and/or Java in order to run their full client.  So while Kronos may be
> up-to-date there is a good chance that it requires other software to not
> be patched.
>
>> then I would have thought it would required getting an exception to the
>> Campus MSSND from Campus Security:
>>
>> - 1. Software Patch Updates
>>
>> - Campus networked devices must only run software for which security
>> - patches are made available in a timely fashion.  All currently
>> - available security patches must be applied on a schedule appropriate
>> - to the severity of the risk they mitigat
>>
>> To me, this raises the question of "Did CalTime get any security review
>> by an external party - at a minimum someone other than the CalTime team
>> or the vendor - before going Primetime?"
>
> It would also seem that using terminal servers like this
>
> "Systems that are most often accessed remotely and are exposed to more
> than 50 unique CalNet IDs per day, such as terminal services machines
> and..."
>
> https://wikihub.berkeley.edu/display/calnet/Proxied+CalNet+Authentication+Exception+Requests
>
> should trigger the requirement for a review by the CalNet Tech team
> regarding proxied authentication and then a decision by CISPC on whether
> the proxied authentication is allowed or not.
>
>
> Rune
>
>
>> Curmudgeonly, Jon
>>
>>
>> -------------------------------------------------------------------------
>> The following was automatically added to this message by the list server:
>>
>> To learn more about Micronet, including how to subscribe to or unsubscribe
>> from its mailing list and how to find out about upcoming meetings, please
>> visit the Micronet Web site:
>>
>> http://micronet.berkeley.edu
>>
>> Messages you send to this mailing list are public and world-viewable, and
>> the list's archives can be browsed and searched on the Internet.  This
>> means these messages can be viewed by (among others) your bosses,
>> prospective employers, and people who have known you in the past.
>>
>
>
>


--
Lucia Greco
Web Access Analyst
IST-Campus Technology Services
University of California, Berkeley
(510) 289-6008
http://webaccess.berkeley.edu

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Tom Holub
In reply to this post by Michael Sinatra-3
Top-posting on Lucy's behalf, which plays into part of my comments below about
the nature of the Micronet mailing list:

Micronet was indeed once a place where technical issues were hashed out, but,
there has always been a disconnect between functional owners (who are largely
non-technical) and the Micronet community, which is largely technical.  Some
functional owners don't understand the desktop-level impacts of choices they
make; others may understand that there are impacts, but due to funding or
timing constraints be unable to address them.  Some functional owners view the
IT operation as existing to implement the system as the functional owner has
specified.  There are governance and funding issues around functional
ownership which play into the current state of Micronet discussions, and
addressing those issues should be a priority of the next CIO.

However, there are other factors at play.  One is the general decline of the
relevance of email lists.  Every public email list I'm a part of has less
traffic and less meaningful content than it did five years ago.  Part of the
reason for that is that email has been found to be a poor medium for general
discussion, for various reasons.  One reason is that email's presentation of
thread content is really not very good because of a lack of meta-data.  Lucy
would like to have everyone top-post because her screen reader can't parse an
inline-posted message due to lack of meta-data.  People who grew up using
Usenet prefer inline-posting because inline-posting is necessary to be able to
understand complex discussions involving multiple points.

Speaking as a usually inline-poster, it's obvious that top-posting has won the
debate of "how 'should' email responses be sent," to the point that a major
campus ticketing system deletes your response if you don't top-post it.  There
are many reasons that top-posting won out, and that's beyond the scope of this
current treatise, but one of the implications is that the kind of discussion
which occurred on Usenet is hard to do in email, because with top-posting it
is difficult to tie your responses to specific points in the message you're
responding to.  So, email has become a poor tool for having substantive
discussion (if it were ever a good tool for that).

Another general factor affecting email lists, partly caused by the dominance
of top-posting and partly caused by the asynchronous and pseudo-anonymous
nature of the medium, is that they tend towards people with strong opinions
expressing them forcefully.  Who wants to put a lot of effort into a balanced
response when it's going to get shouted down from both sides?  So, some of the
best contributors step back from participation, and the list becomes either
more combative or more one-sided and shrill, as The Usual Suspects make their
usual assertions.

Specifically in the case of Micronet, there is an unfortunate tendency towards
negativity, both on the email list and at meetings.  The Micronet reception of
the Adobe and Microsoft licensing deal is a good example; here we were getting
something that the campus community had wanted for years (rational licensing
mechanisms for commonly-used software), and the reception on Micronet was
mostly umbrage that Micronet hadn't been consulted first, and nit-picking at
implementation details.

Frankly, if I were a campus functional owner, I wouldn't want to bring my
project to Micronet.  Why expose yourself to that kind of energy when you're
not going to hear from most of the campus IT community anyway?

If Micronet wants to be relevant, it's going to need to reinvent itself and
develop ways to provide broad, productive input.  Or, the campus IT community
and IT governance structure will need to get broad campus input (where
appropriate) through other mechanisms.

On 11/19/12 8:56 AM, Michael Sinatra wrote:

>
> I don't know as much about the other issues, but the all seem to have
> causes: There is no transparency in the technical decision making
> process.  We (the Micronet community) don't know what decisions are
> being made, we can't contribute to the decisions, despite the impressive
> technical knowledge-base of Micronet, and we don't even know when a
> decision has been made or why!  I am kind of surprised at the deafening
> silence.  Micronet used to be a place where we hashed out technical
> service questions like these--with the service providers actively
> participating.


--
Tom Holub ([hidden email], 510-642-9069)
Director of Computing, College of Letters & Science
101.D Durant Hall
<http://LSCR.berkeley.edu/>


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Christopher Brooks
Tom,
This is an excellent summary of the situation.

I agree that focusing on positive solutions and methodologies will have
greater
impact than kvetching about some detail in a campus situation.  I'd
rather solve
the problem for the next time.

For example, there was an Agile brown bag about having the customer in
the process.  If such a methodology was followed, then many of these issues
would have been identified and fixed before roll out.


I try to focus on top posting because when I inline-post the tone of the
email
seems more like a detail-oriented argument.  In addition, top-posting is
more
ADA-compliant, which is a good choice.

You mentioned a campus ticketing system.  My beef with the current
configuration of Footprints is that it seems to be returning only the
response
of the support person, it does not include the entire thread.  Since
there is no
way for me to access the Footprints database, I have to poke around in
my email
trash and sent folders to piece together the thread.  This is like top
posting
without providing the rest of the thread, which some people prefer (I
don't).
This makes the conversation multi-threaded, hard to track and risks the
loss of information.  In an email message on a mailing list, this is
acceptable.
In a support ticket that passes back and forth between two people, there is
no reason not to include the entire history.

In addition, if multiple issues are raised in a ticket, the typically
only one issue
is handled.  The current configuration of Footprints is designed to
close tickets
as quickly as possible, not to provide meaningful support.    I believe that
Footprints was modified to not include the entire thread because the
messages
from Footprints were not really human readable.  This is a bug in
Footprints,
one solution is to strip out formatting.

Finally, because the tickets are not publicly available, I end up depending
on Micronet to provide an early warning system about what sorts of problems
are in my future.  I agree that some tickets should be not readable
campus-wide,
but I don't enjoy replicating work tracking down an issue if that issue has
already been reported.  Thus, I end up depending on Micronet.

You comment about being afraid to bring a project to Micronet is
interesting.
For a campus-wide project, sooner or later, people on Micronet will end up
dealing with that project.  Having a more measured roll-out with an actual
documented plan for evaluation and usability testing would help avoid
negative issues.

My position is this:

It is great that we are moving towards more modern systems for timekeeping,
purchasing, travel etc.  What I object to is being a beta-tester for so many
poorly designed and deployed systems in so short a period of time with
Footprints being misconfigured.

I think Michael Sinatra brought up a really good point about transparency.
Transparency also allows users to feel like their voices are heard and
their input matters.  Transparency brings users and developers on to the
same side.

One issue with transparency is that we don't all have time to contribute to
all projects.  I'm happy to contribute on some campus-wide initiatives,
but I don't have the time beta-test everything.  In the end, I'm
pleading for
a little more planning and testing in campus-wide products that affect
many people.

_Christopher



On 11/20/12 1:55 PM, Tom Holub wrote:

> Top-posting on Lucy's behalf, which plays into part of my comments below about
> the nature of the Micronet mailing list:
>
> Micronet was indeed once a place where technical issues were hashed out, but,
> there has always been a disconnect between functional owners (who are largely
> non-technical) and the Micronet community, which is largely technical.  Some
> functional owners don't understand the desktop-level impacts of choices they
> make; others may understand that there are impacts, but due to funding or
> timing constraints be unable to address them.  Some functional owners view the
> IT operation as existing to implement the system as the functional owner has
> specified.  There are governance and funding issues around functional
> ownership which play into the current state of Micronet discussions, and
> addressing those issues should be a priority of the next CIO.
>
> However, there are other factors at play.  One is the general decline of the
> relevance of email lists.  Every public email list I'm a part of has less
> traffic and less meaningful content than it did five years ago.  Part of the
> reason for that is that email has been found to be a poor medium for general
> discussion, for various reasons.  One reason is that email's presentation of
> thread content is really not very good because of a lack of meta-data.  Lucy
> would like to have everyone top-post because her screen reader can't parse an
> inline-posted message due to lack of meta-data.  People who grew up using
> Usenet prefer inline-posting because inline-posting is necessary to be able to
> understand complex discussions involving multiple points.
>
> Speaking as a usually inline-poster, it's obvious that top-posting has won the
> debate of "how 'should' email responses be sent," to the point that a major
> campus ticketing system deletes your response if you don't top-post it.  There
> are many reasons that top-posting won out, and that's beyond the scope of this
> current treatise, but one of the implications is that the kind of discussion
> which occurred on Usenet is hard to do in email, because with top-posting it
> is difficult to tie your responses to specific points in the message you're
> responding to.  So, email has become a poor tool for having substantive
> discussion (if it were ever a good tool for that).
>
> Another general factor affecting email lists, partly caused by the dominance
> of top-posting and partly caused by the asynchronous and pseudo-anonymous
> nature of the medium, is that they tend towards people with strong opinions
> expressing them forcefully.  Who wants to put a lot of effort into a balanced
> response when it's going to get shouted down from both sides?  So, some of the
> best contributors step back from participation, and the list becomes either
> more combative or more one-sided and shrill, as The Usual Suspects make their
> usual assertions.
>
> Specifically in the case of Micronet, there is an unfortunate tendency towards
> negativity, both on the email list and at meetings.  The Micronet reception of
> the Adobe and Microsoft licensing deal is a good example; here we were getting
> something that the campus community had wanted for years (rational licensing
> mechanisms for commonly-used software), and the reception on Micronet was
> mostly umbrage that Micronet hadn't been consulted first, and nit-picking at
> implementation details.
>
> Frankly, if I were a campus functional owner, I wouldn't want to bring my
> project to Micronet.  Why expose yourself to that kind of energy when you're
> not going to hear from most of the campus IT community anyway?
>
> If Micronet wants to be relevant, it's going to need to reinvent itself and
> develop ways to provide broad, productive input.  Or, the campus IT community
> and IT governance structure will need to get broad campus input (where
> appropriate) through other mechanisms.
>
> On 11/19/12 8:56 AM, Michael Sinatra wrote:
>> I don't know as much about the other issues, but the all seem to have
>> causes: There is no transparency in the technical decision making
>> process.  We (the Micronet community) don't know what decisions are
>> being made, we can't contribute to the decisions, despite the impressive
>> technical knowledge-base of Micronet, and we don't even know when a
>> decision has been made or why!  I am kind of surprised at the deafening
>> silence.  Micronet used to be a place where we hashed out technical
>> service questions like these--with the service providers actively
>> participating.
>

--
Christopher Brooks, PMP                       University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841                                (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Christopher Brooks
[Grumble.  There seems to be something with how lines are broken
in my email to Micronet.  Here's the message refilled slightly...]

I agree that focusing on positive solutions and methodologies will
have greater impact than kvetching about some detail in a campus
situation.  I'd rather solve the problem for the next time.

For example, there was an Agile brown bag about having the customer in
the process.  If such a methodology was followed, then many of these
issues would have been identified and fixed before roll out.


I try to focus on top posting because when I inline-post the tone of
the email seems more like a detail-oriented argument.  In addition,
top-posting is more ADA-compliant, which is a good choice.

You mentioned a campus ticketing system.  My beef with the current
configuration of Footprints is that it seems to be returning only the
response of the support person, it does not include the entire thread.
Since there is no way for me to access the Footprints database, I have
to poke around in my email trash and sent folders to piece together
the thread.  This is like top posting without providing the rest of
the thread, which some people prefer (I don't).  This makes the
conversation multi-threaded, hard to track and risks the loss of
information.  In an email message on a mailing list, this is
acceptable.  In a support ticket that passes back and forth between
two people, there is no reason not to include the entire history.

In addition, if multiple issues are raised in a ticket, the typically
only one issue is handled.  The current configuration of Footprints is
designed to close tickets as quickly as possible, not to provide
meaningful support.  I believe that Footprints was modified to not
include the entire thread because the messages from Footprints were
not really human readable.  This is a bug in Footprints, one solution
is to strip out formatting.

Finally, because the tickets are not publicly available, I end up
depending on Micronet to provide an early warning system about what
sorts of problems are in my future.  I agree that some tickets should
be not readable campus-wide, but I don't enjoy replicating work
tracking down an issue if that issue has already been reported. Thus,
I end up depending on Micronet.

You comment about being afraid to bring a project to Micronet is
interesting.  For a campus-wide project, sooner or later, people on
Micronet will end up dealing with that project.  Having a more
measured roll-out with an actual documented plan for evaluation and
usability testing would help avoid negative issues.

My position is this:

It is great that we are moving towards more modern systems for
timekeeping, purchasing, travel etc.  What I object to is being a
beta-tester for so many poorly designed and deployed systems in so
short a period of time with Footprints being misconfigured.

I think Michael Sinatra brought up a really good point about
transparency.  Transparency also allows users to feel like their
voices are heard and their input matters.  Transparency brings users
and developers on to the same side.

One issue with transparency is that we don't all have time to
contribute to all projects.  I'm happy to contribute on some
campus-wide initiatives, but I don't have the time beta-test
everything.  In the end, I'm pleading for a little more planning and
testing in campus-wide products that affect many people.

On 11/20/12 3:53 PM, Christopher Brooks wrote:

> I agree that focusing on positive solutions and methodologies will have
> greater
> impact than kvetching about some detail in a campus situation.  I'd
> rather solve
> the problem for the next time.
>
> For example, there was an Agile brown bag about having the customer in
> the process.  If such a methodology was followed, then many of these issues
> would have been identified and fixed before roll out.
>
>
> I try to focus on top posting because when I inline-post the tone of the
> email
> seems more like a detail-oriented argument.  In addition, top-posting is
> more
> ADA-compliant, which is a good choice.
>
> You mentioned a campus ticketing system.  My beef with the current
> configuration of Footprints is that it seems to be returning only the
> response
> of the support person, it does not include the entire thread.  Since
> there is no
> way for me to access the Footprints database, I have to poke around in
> my email
> trash and sent folders to piece together the thread.  This is like top
> posting
> without providing the rest of the thread, which some people prefer (I
> don't).
> This makes the conversation multi-threaded, hard to track and risks the
> loss of information.  In an email message on a mailing list, this is
> acceptable.
> In a support ticket that passes back and forth between two people, there is
> no reason not to include the entire history.
>
> In addition, if multiple issues are raised in a ticket, the typically
> only one issue
> is handled.  The current configuration of Footprints is designed to
> close tickets
> as quickly as possible, not to provide meaningful support.    I believe that
> Footprints was modified to not include the entire thread because the
> messages
> from Footprints were not really human readable.  This is a bug in
> Footprints,
> one solution is to strip out formatting.
>
> Finally, because the tickets are not publicly available, I end up depending
> on Micronet to provide an early warning system about what sorts of problems
> are in my future.  I agree that some tickets should be not readable
> campus-wide,
> but I don't enjoy replicating work tracking down an issue if that issue has
> already been reported.  Thus, I end up depending on Micronet.
>
> You comment about being afraid to bring a project to Micronet is
> interesting.
> For a campus-wide project, sooner or later, people on Micronet will end up
> dealing with that project.  Having a more measured roll-out with an actual
> documented plan for evaluation and usability testing would help avoid
> negative issues.
>
> My position is this:
>
> It is great that we are moving towards more modern systems for timekeeping,
> purchasing, travel etc.  What I object to is being a beta-tester for so many
> poorly designed and deployed systems in so short a period of time with
> Footprints being misconfigured.
>
> I think Michael Sinatra brought up a really good point about transparency.
> Transparency also allows users to feel like their voices are heard and
> their input matters.  Transparency brings users and developers on to the
> same side.
>
> One issue with transparency is that we don't all have time to contribute to
> all projects.  I'm happy to contribute on some campus-wide initiatives,
> but I don't have the time beta-test everything.  In the end, I'm
> pleading for
> a little more planning and testing in campus-wide products that affect
> many people.

--
Christopher Brooks, PMP                       University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841                                (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Nils Ohlson
In reply to this post by Tom Holub
Tom,
I'm going to give my perspective as a not-very-technical person who still has some tech understanding and has to deal with, or directly support those who deal with, almost every Campus-specific widely used computer applications. And I'm going to try modified top-posting so let's see how that goes.

TOPICS:
[1] Micronet
[2] E-mail
[3] Dealing w/ negativity
[4] Inclusivity and keeping informed the people who have to deal with the issues.

[1] Micronet itself- If there is another forum where just about everyone can address and get news about Campus computer-related issues, I'd like to know what it is. In the absence of a better one, I think we should still expect Micronet to be a place where technical problems can be hashed out, AND where technical rollouts can be introduced and input be solicited.

[2] E-mail as communication method: If there is a better mode of communication than e-mail, please let me know what it is. It's inclusive, the messages can be long enough to be meaningful (vs Twitter), you don't have to have a website open to track the traffic, it's democratic (see topic 4), you can ignore it if it's irrelevant. If you don't like the way replies are posted, i.e. top-posting vs inline, let's have an etiquette discussion.

[3] Negativity- please just be tough-skinned and if the shoe doesn't fit, don't wear it. Do please call people out if they're rude; otherwise, expect "forceful" comments; people with strong opinions will express them strongly. It's vital that those like Michael be able to be heard by the larger community. If you find that worthwhile projects are not getting an honest hearing because the response is unduly harsh or rude, then let's work on that as a community, develop some basic rules of politeness. Remember, killing messengers is not nice!

[4] Inclusivity- we have seen far to many computer application rollouts, that is to say practically every one since 1999, where the people who are actually going to use it, or support the users, are not given *any* input until the silly thing (apologies for rudeness) is set in stone and $50 million dollars already committed to it. Micronet cannot be the only way this can be remedied. In fact it will continue to be relegated to the role of responding after the fact by its very nature. But I think it can serve as a forum wherein lobbying can be conducted for a more inclusive, more bottom-up application testing and design approach to new applications.

Thanks for your time.

-Nils
Nils Ohlson
Financial Services Analyst
College of Chemistry Business Office
410 Latimer Hall #1460
Berkeley, CA 94720-1460
(510) 642-1325 phone
(510) 642-4313 fax
[hidden email]
On 11/20/2012 1:55 PM, Tom Holub wrote:
Top-posting on Lucy's behalf, which plays into part of my comments below about
the nature of the Micronet mailing list:
TOPIC [1] Micronet:
Micronet was indeed once a place where technical issues were hashed out, but,
there has always been a disconnect between functional owners (who are largely
non-technical) and the Micronet community, which is largely technical.  Some
functional owners don't understand the desktop-level impacts of choices they
make; others may understand that there are impacts, but due to funding or
timing constraints be unable to address them.  Some functional owners view the
IT operation as existing to implement the system as the functional owner has
specified.  There are governance and funding issues around functional
ownership which play into the current state of Micronet discussions, and
addressing those issues should be a priority of the next CIO.
TOPIC [2] E-mail:
However, there are other factors at play.  One is the general decline of the
relevance of email lists.  Every public email list I'm a part of has less
traffic and less meaningful content than it did five years ago.  Part of the
reason for that is that email has been found to be a poor medium for general
discussion, for various reasons.  One reason is that email's presentation of
thread content is really not very good because of a lack of meta-data.  Lucy
would like to have everyone top-post because her screen reader can't parse an
inline-posted message due to lack of meta-data.  People who grew up using
Usenet prefer inline-posting because inline-posting is necessary to be able to
understand complex discussions involving multiple points.

Speaking as a usually inline-poster, it's obvious that top-posting has won the
debate of "how 'should' email responses be sent," to the point that a major
campus ticketing system deletes your response if you don't top-post it.  There
are many reasons that top-posting won out, and that's beyond the scope of this
current treatise, but one of the implications is that the kind of discussion
which occurred on Usenet is hard to do in email, because with top-posting it
is difficult to tie your responses to specific points in the message you're
responding to.  So, email has become a poor tool for having substantive
discussion (if it were ever a good tool for that).
TOPIC [3] Negativity

Another general factor affecting email lists, partly caused by the dominance
of top-posting and partly caused by the asynchronous and pseudo-anonymous
nature of the medium, is that they tend towards people with strong opinions
expressing them forcefully.  Who wants to put a lot of effort into a balanced
response when it's going to get shouted down from both sides?  So, some of the
best contributors step back from participation, and the list becomes either
more combative or more one-sided and shrill, as The Usual Suspects make their
usual assertions.

Specifically in the case of Micronet, there is an unfortunate tendency towards
negativity, both on the email list and at meetings.  The Micronet reception of
the Adobe and Microsoft licensing deal is a good example; here we were getting
something that the campus community had wanted for years (rational licensing
mechanisms for commonly-used software), and the reception on Micronet was
mostly umbrage that Micronet hadn't been consulted first, and nit-picking at
implementation details.

Frankly, if I were a campus functional owner, I wouldn't want to bring my
project to Micronet.  Why expose yourself to that kind of energy when you're
not going to hear from most of the campus IT community anyway?

If Micronet wants to be relevant, it's going to need to reinvent itself and
develop ways to provide broad, productive input.  Or, the campus IT community
and IT governance structure will need to get broad campus input (where
appropriate) through other mechanisms.

On 11/19/12 8:56 AM, Michael Sinatra wrote:
TOPIC [4] Inclusivity

      
I don't know as much about the other issues, but the all seem to have
causes: There is no transparency in the technical decision making
process.  We (the Micronet community) don't know what decisions are
being made, we can't contribute to the decisions, despite the impressive
technical knowledge-base of Micronet, and we don't even know when a
decision has been made or why!  I am kind of surprised at the deafening
silence.  Micronet used to be a place where we hashed out technical
service questions like these--with the service providers actively
participating.



 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Claudia A. WATERS

Thank you so much, Nils, for this thoughtful response.  I have been writing a response since yesterday, but yours succinctly captures what I wanted to say.  As chair of Micronet, I have tried to put together meetings where important issues could be discussed.  IT leaders on campus have generously given of their time to speak when I invited them.   This is a time of great change and many have strong opinions on these changes because they feel  passionate about this university.   The Micronet list, more than the meetings,  is a great form of communication on all IT issues.

 

Several IT folks have suggested that we call a Micronet meeting to discuss the issues posed by Tom’s question and the many responses.   Please email the list or me to let me know if I should call a meeting on this topic.

 

Possible dates:

Wednesday, December 12, 10:30-noon

Wednesday, January 23, 10:30-noon

 

Thanks.

Claudia

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Nils Ohlson
Sent: Wednesday, November 21, 2012 8:38 AM
To: Tom Holub
Cc: [hidden email]
Subject: Re: [Micronet] OE Website quality

 

Tom,
I'm going to give my perspective as a not-very-technical person who still has some tech understanding and has to deal with, or directly support those who deal with, almost every Campus-specific widely used computer applications. And I'm going to try modified top-posting so let's see how that goes.

TOPICS:
[1] Micronet
[2] E-mail
[3] Dealing w/ negativity
[4] Inclusivity and keeping informed the people who have to deal with the issues.

[1] Micronet itself- If there is another forum where just about everyone can address and get news about Campus computer-related issues, I'd like to know what it is. In the absence of a better one, I think we should still expect Micronet to be a place where technical problems can be hashed out, AND where technical rollouts can be introduced and input be solicited.

[2] E-mail as communication method: If there is a better mode of communication than e-mail, please let me know what it is. It's inclusive, the messages can be long enough to be meaningful (vs Twitter), you don't have to have a website open to track the traffic, it's democratic (see topic 4), you can ignore it if it's irrelevant. If you don't like the way replies are posted, i.e. top-posting vs inline, let's have an etiquette discussion.

[3] Negativity- please just be tough-skinned and if the shoe doesn't fit, don't wear it. Do please call people out if they're rude; otherwise, expect "forceful" comments; people with strong opinions will express them strongly. It's vital that those like Michael be able to be heard by the larger community. If you find that worthwhile projects are not getting an honest hearing because the response is unduly harsh or rude, then let's work on that as a community, develop some basic rules of politeness. Remember, killing messengers is not nice!

[4] Inclusivity- we have seen far to many computer application rollouts, that is to say practically every one since 1999, where the people who are actually going to use it, or support the users, are not given *any* input until the silly thing (apologies for rudeness) is set in stone and $50 million dollars already committed to it. Micronet cannot be the only way this can be remedied. In fact it will continue to be relegated to the role of responding after the fact by its very nature. But I think it can serve as a forum wherein lobbying can be conducted for a more inclusive, more bottom-up application testing and design approach to new applications.

Thanks for your time.

-Nils

Nils Ohlson
Financial Services Analyst
College of Chemistry Business Office
410 Latimer Hall #1460
Berkeley, CA 94720-1460
(510) 642-1325 phone
(510) 642-4313 fax
[hidden email]

On 11/20/2012 1:55 PM, Tom Holub wrote:

Top-posting on Lucy's behalf, which plays into part of my comments below about
the nature of the Micronet mailing list:

TOPIC [1] Micronet:

 
Micronet was indeed once a place where technical issues were hashed out, but,
there has always been a disconnect between functional owners (who are largely
non-technical) and the Micronet community, which is largely technical.  Some
functional owners don't understand the desktop-level impacts of choices they
make; others may understand that there are impacts, but due to funding or
timing constraints be unable to address them.  Some functional owners view the
IT operation as existing to implement the system as the functional owner has
specified.  There are governance and funding issues around functional
ownership which play into the current state of Micronet discussions, and
addressing those issues should be a priority of the next CIO.

TOPIC [2] E-mail:

 
However, there are other factors at play.  One is the general decline of the
relevance of email lists.  Every public email list I'm a part of has less
traffic and less meaningful content than it did five years ago.  Part of the
reason for that is that email has been found to be a poor medium for general
discussion, for various reasons.  One reason is that email's presentation of
thread content is really not very good because of a lack of meta-data.  Lucy
would like to have everyone top-post because her screen reader can't parse an
inline-posted message due to lack of meta-data.  People who grew up using
Usenet prefer inline-posting because inline-posting is necessary to be able to
understand complex discussions involving multiple points.
 
Speaking as a usually inline-poster, it's obvious that top-posting has won the
debate of "how 'should' email responses be sent," to the point that a major
campus ticketing system deletes your response if you don't top-post it.  There
are many reasons that top-posting won out, and that's beyond the scope of this
current treatise, but one of the implications is that the kind of discussion
which occurred on Usenet is hard to do in email, because with top-posting it
is difficult to tie your responses to specific points in the message you're
responding to.  So, email has become a poor tool for having substantive
discussion (if it were ever a good tool for that).

TOPIC [3] Negativity


 
Another general factor affecting email lists, partly caused by the dominance
of top-posting and partly caused by the asynchronous and pseudo-anonymous
nature of the medium, is that they tend towards people with strong opinions
expressing them forcefully.  Who wants to put a lot of effort into a balanced
response when it's going to get shouted down from both sides?  So, some of the
best contributors step back from participation, and the list becomes either
more combative or more one-sided and shrill, as The Usual Suspects make their
usual assertions.
 
Specifically in the case of Micronet, there is an unfortunate tendency towards
negativity, both on the email list and at meetings.  The Micronet reception of
the Adobe and Microsoft licensing deal is a good example; here we were getting
something that the campus community had wanted for years (rational licensing
mechanisms for commonly-used software), and the reception on Micronet was
mostly umbrage that Micronet hadn't been consulted first, and nit-picking at
implementation details.
 
Frankly, if I were a campus functional owner, I wouldn't want to bring my
project to Micronet.  Why expose yourself to that kind of energy when you're
not going to hear from most of the campus IT community anyway?
 
If Micronet wants to be relevant, it's going to need to reinvent itself and
develop ways to provide broad, productive input.  Or, the campus IT community
and IT governance structure will need to get broad campus input (where
appropriate) through other mechanisms.
 
On 11/19/12 8:56 AM, Michael Sinatra wrote:

TOPIC [4] Inclusivity

 
 
I don't know as much about the other issues, but the all seem to have
causes: There is no transparency in the technical decision making
process.  We (the Micronet community) don't know what decisions are
being made, we can't contribute to the decisions, despite the impressive
technical knowledge-base of Micronet, and we don't even know when a
decision has been made or why!  I am kind of surprised at the deafening
silence.  Micronet used to be a place where we hashed out technical
service questions like these--with the service providers actively
participating.
 
 

 


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] OE Website quality

Tom Holub
In reply to this post by Nils Ohlson
[1] There are other forums, but overall the campus clearly lack a place
where input is consistently sought and valued.

[2] I used to be on the "gobears" mailing list.  Had many arguments with
Steve Finacom and Nad Permaul on it.  It's dead.  California Golden
Blogs now has an order of magnitude more traffic than the email list
ever did; public, "democratic" and threaded.  The first of several
Tedford posts currently has 902 comments.  It's not a question of email
etiquette; the point is that email listservs are simply not as good at
providing a place for threaded discussions.  Google and even Facebook
also provide real threading and an interface that's not constrained by
the fact that VT-100 terminals were 80 characters wide.

The point is, neither top-posting nor inline-posting work well for
threaded discussion in email due to the limitations of the medium.

[3] "Please just be tough-skinned" is completely missing the point.  If
Micronet was less negative, it would be more effective.  The fact that
rollouts happen without consulting Micronet stems at least partly from
the impression system owners have about the quality of input they'll get
from Micronet.  And I'm not calling out Sinatra here; it is possible to
be critical without being negative.

[4] Yes, there is a problem with many major rollouts occurring without
checking alignment with campus requirements.  If we want that to change,
we'll have to do more than stamp our feet on Micronet, because the
audience isn't here.


On 11/21/12 8:37 AM, Nils Ohlson wrote:

> Tom,
> I'm going to give my perspective as a not-very-technical person who
> still has some tech understanding and has to deal with, or directly
> support those who deal with, almost every Campus-specific widely used
> computer applications. And I'm going to try modified top-posting so
> let's see how that goes.
>
> TOPICS:
> [1] Micronet
> [2] E-mail
> [3] Dealing w/ negativity
> [4] Inclusivity and keeping informed the people who have to deal with
> the issues.
>
> [1] Micronet itself- If there is another forum where just about everyone
> can address and get news about Campus computer-related issues, I'd like
> to know what it is. In the absence of a better one, I think we should
> still expect Micronet to be a place where technical problems can be
> hashed out, AND where technical rollouts can be introduced and input be
> solicited.
>
> [2] E-mail as communication method: If there is a better mode of
> communication than e-mail, please let me know what it is. It's
> inclusive, the messages can be long enough to be meaningful (vs
> Twitter), you don't have to have a website open to track the traffic,
> it's democratic (see topic 4), you can ignore it if it's irrelevant. If
> you don't like the way replies are posted, i.e. top-posting vs inline,
> let's have an etiquette discussion.
>
> [3] Negativity- please just be tough-skinned and if the shoe doesn't
> fit, don't wear it. Do please call people out if they're rude;
> otherwise, expect "forceful" comments; people with strong opinions will
> express them strongly. It's vital that those like Michael be able to be
> heard by the larger community. If you find that worthwhile projects are
> not getting an honest hearing because the response is unduly harsh or
> rude, then let's work on that as a community, develop some basic rules
> of politeness. Remember, killing messengers is not nice!
>
> [4] Inclusivity- we have seen far to many computer application rollouts,
> that is to say practically every one since 1999, where the people who
> are actually going to use it, or support the users, are not given *any*
> input until the silly thing (apologies for rudeness) is set in stone and
> $50 million dollars already committed to it. Micronet cannot be the only
> way this can be remedied. In fact it will continue to be relegated to
> the role of responding after the fact by its very nature. But I think it
> can serve as a forum wherein lobbying can be conducted for a more
> inclusive, more bottom-up application testing and design approach to new
> applications.
>
> Thanks for your time.
>
> -Nils
>
> Nils Ohlson
> Financial Services Analyst
> College of Chemistry Business Office
> 410 Latimer Hall #1460
> Berkeley, CA 94720-1460
> (510) 642-1325 phone
> (510) 642-4313 fax
> [hidden email]
>
> On 11/20/2012 1:55 PM, Tom Holub wrote:
>> Top-posting on Lucy's behalf, which plays into part of my comments below about
>> the nature of the Micronet mailing list:
> TOPIC [1] Micronet:
>> Micronet was indeed once a place where technical issues were hashed out, but,
>> there has always been a disconnect between functional owners (who are largely
>> non-technical) and the Micronet community, which is largely technical.  Some
>> functional owners don't understand the desktop-level impacts of choices they
>> make; others may understand that there are impacts, but due to funding or
>> timing constraints be unable to address them.  Some functional owners view the
>> IT operation as existing to implement the system as the functional owner has
>> specified.  There are governance and funding issues around functional
>> ownership which play into the current state of Micronet discussions, and
>> addressing those issues should be a priority of the next CIO.
> TOPIC [2] E-mail:
>> However, there are other factors at play.  One is the general decline of the
>> relevance of email lists.  Every public email list I'm a part of has less
>> traffic and less meaningful content than it did five years ago.  Part of the
>> reason for that is that email has been found to be a poor medium for general
>> discussion, for various reasons.  One reason is that email's presentation of
>> thread content is really not very good because of a lack of meta-data.  Lucy
>> would like to have everyone top-post because her screen reader can't parse an
>> inline-posted message due to lack of meta-data.  People who grew up using
>> Usenet prefer inline-posting because inline-posting is necessary to be able to
>> understand complex discussions involving multiple points.
>>
>> Speaking as a usually inline-poster, it's obvious that top-posting has won the
>> debate of "how 'should' email responses be sent," to the point that a major
>> campus ticketing system deletes your response if you don't top-post it.  There
>> are many reasons that top-posting won out, and that's beyond the scope of this
>> current treatise, but one of the implications is that the kind of discussion
>> which occurred on Usenet is hard to do in email, because with top-posting it
>> is difficult to tie your responses to specific points in the message you're
>> responding to.  So, email has become a poor tool for having substantive
>> discussion (if it were ever a good tool for that).
> TOPIC [3] Negativity
>
>> Another general factor affecting email lists, partly caused by the dominance
>> of top-posting and partly caused by the asynchronous and pseudo-anonymous
>> nature of the medium, is that they tend towards people with strong opinions
>> expressing them forcefully.  Who wants to put a lot of effort into a balanced
>> response when it's going to get shouted down from both sides?  So, some of the
>> best contributors step back from participation, and the list becomes either
>> more combative or more one-sided and shrill, as The Usual Suspects make their
>> usual assertions.
>>
>> Specifically in the case of Micronet, there is an unfortunate tendency towards
>> negativity, both on the email list and at meetings.  The Micronet reception of
>> the Adobe and Microsoft licensing deal is a good example; here we were getting
>> something that the campus community had wanted for years (rational licensing
>> mechanisms for commonly-used software), and the reception on Micronet was
>> mostly umbrage that Micronet hadn't been consulted first, and nit-picking at
>> implementation details.
>>
>> Frankly, if I were a campus functional owner, I wouldn't want to bring my
>> project to Micronet.  Why expose yourself to that kind of energy when you're
>> not going to hear from most of the campus IT community anyway?
>>
>> If Micronet wants to be relevant, it's going to need to reinvent itself and
>> develop ways to provide broad, productive input.  Or, the campus IT community
>> and IT governance structure will need to get broad campus input (where
>> appropriate) through other mechanisms.
>>
>> On 11/19/12 8:56 AM, Michael Sinatra wrote:
> TOPIC [4] Inclusivity
>>> I don't know as much about the other issues, but the all seem to have
>>> causes: There is no transparency in the technical decision making
>>> process.  We (the Micronet community) don't know what decisions are
>>> being made, we can't contribute to the decisions, despite the impressive
>>> technical knowledge-base of Micronet, and we don't even know when a
>>> decision has been made or why!  I am kind of surprised at the deafening
>>> silence.  Micronet used to be a place where we hashed out technical
>>> service questions like these--with the service providers actively
>>> participating.
>>
>


--
Tom Holub ([hidden email], 510-642-9069)
Director of Computing, College of Letters & Science
101.D Durant Hall
<http://LSCR.berkeley.edu/>

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
12