[DG: User Experience] Reporting bugs for 3akai

[Clay Fenlason-3]

A few of us at Georgia Tech have been doing some browser/visual
artefact testing against 3akai.sakaiproject.org, and I wanted to start
putting our results into JIRA, but I wanted to be clear about the rev
against which these tests are conducted. Not sure how to get this from
the server, or if its deployment routine affords this sort of
systematic treatment just now.  Advice?

~Clay
_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Nicolaas Matthijs]

Good to hear that some testing is being done :)!

I'm not entirely sure what the current revision is, but there is a way to tell
how old the code is you're working with. If you connect to
3akai.sakaiproject.org using WebDav, you should look at the "Date Modified"
for the index.html page in the root folder, which will be the date when the
server has been redeployed. In other words, the current 3akai deployment is
working with the trunk code from Monday 14th of September, 13:32. We can
translate that into specific revision numbers using SVN, but just the
timestamp should be sufficient for the developers ...

Thanks,
Nicolaas

> Quoting Clay Fenlason <clay.fenlason@...>:
>
> A few of us at Georgia Tech have been doing some browser/visual
> artefact testing against 3akai.sakaiproject.org, and I wanted to start
> putting our results into JIRA, but I wanted to be clear about the rev
> against which these tests are conducted. Not sure how to get this from
> the server, or if its deployment routine affords this sort of
> systematic treatment just now.  Advice?
>
> ~Clay
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
> with a subject of "unsubscribe"
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Jason Shao (CampusEAI Consortium)]

Ahh... that's somewhat opaque. I'll admit to doing some (stealth) poking, and would love to have an easier way to triangulate issues if I saw them.

Any possibility of something more explicit, maybe the inclusion of a SHA1 tag or the like?

Jason

--
Jason Shao
Director of Product Development
CampusEAI Consortium
1940 East 6th Street, 11th Floor
Cleveland, OH 44114
Tel: [phone]x249
Fax: [phone]

-----Original Message-----
From: sakai-ux-bounces@... [mailto:sakai-ux-bounces@...] On Behalf Of Nicolaas Matthijs
Sent: Tuesday, September 22, 2009 5:20 AM
To: Clay Fenlason
Cc: Sakai UX
Subject: Re: [DG: User Experience] Reporting bugs for 3akai

Good to hear that some testing is being done :)!

I'm not entirely sure what the current revision is, but there is a way to tell
how old the code is you're working with. If you connect to
3akai.sakaiproject.org using WebDav, you should look at the "Date Modified"
for the index.html page in the root folder, which will be the date when the
server has been redeployed. In other words, the current 3akai deployment is
working with the trunk code from Monday 14th of September, 13:32. We can
translate that into specific revision numbers using SVN, but just the
timestamp should be sufficient for the developers ...

Thanks,
Nicolaas

> Quoting Clay Fenlason <clay.fenlason@...>:
>
> A few of us at Georgia Tech have been doing some browser/visual
> artefact testing against 3akai.sakaiproject.org, and I wanted to start
> putting our results into JIRA, but I wanted to be clear about the rev
> against which these tests are conducted. Not sure how to get this from
> the server, or if its deployment routine affords this sort of
> systematic treatment just now.  Advice?
>
> ~Clay
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
> with a subject of "unsubscribe"
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

Your input is important to improve upon our continuous efforts to service you better. Please e-mail my manager at anjli_jain@... with any feedback.

CONFIDENTIALITY NOTICE:
This e-mail together with any attachments is proprietary and confidential; intended for only the recipient(s) named above and may contain information that is privileged. You should not retain, copy or use this e-mail or any attachments for any purpose, or disclose all or any part of the contents to any person. Any views or opinions expressed in this e-mail are those of the author and do not represent those of CampusEAI Consortium or the Open Student Television Network. If you have received this e-mail in error, or are not the named recipient(s), you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited by the sender and to do so might constitute a violation of the Electronic Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the sender and delete this e-mail and any attachments from your computer. Warning: Although precautions have been taken to make sure no viruses are present in this e
 -mail, the companies cannot accept responsibility for any loss or damage that arise from the use of this e-mail or attachments.
_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Oszkar Nagy]

I will redeploy the server with debug info constantly displayed in the
footer sometime later today. This will enable testers to easily tie bugs
to deployed versions and specific pages.

Clay: I will look into the the major page edit issue as well, which
should work by now.

Hope this will help a bit,
Oszkar

On 22/09/2009 20:34, Jason Shao (CampusEAI Consortium) wrote:

> Ahh... that's somewhat opaque. I'll admit to doing some (stealth) poking, and would love to have an easier way to triangulate issues if I saw them.
>
> Any possibility of something more explicit, maybe the inclusion of a SHA1 tag or the like?
>
> Jason
>
> --
> Jason Shao
> Director of Product Development
> CampusEAI Consortium
> 1940 East 6th Street, 11th Floor
> Cleveland, OH 44114
> Tel: [phone]x249
> Fax: [phone]
>
> -----Original Message-----
> From: sakai-ux-bounces@... [mailto:sakai-ux-bounces@...] On Behalf Of Nicolaas Matthijs
> Sent: Tuesday, September 22, 2009 5:20 AM
> To: Clay Fenlason
> Cc: Sakai UX
> Subject: Re: [DG: User Experience] Reporting bugs for 3akai
>
> Good to hear that some testing is being done :)!
>
> I'm not entirely sure what the current revision is, but there is a way to tell
> how old the code is you're working with. If you connect to
> 3akai.sakaiproject.org using WebDav, you should look at the "Date Modified"
> for the index.html page in the root folder, which will be the date when the
> server has been redeployed. In other words, the current 3akai deployment is
> working with the trunk code from Monday 14th of September, 13:32. We can
> translate that into specific revision numbers using SVN, but just the
> timestamp should be sufficient for the developers ...
>
> Thanks,
> Nicolaas
>
>
>    
>> Quoting Clay Fenlason<clay.fenlason@...>:
>>
>> A few of us at Georgia Tech have been doing some browser/visual
>> artefact testing against 3akai.sakaiproject.org, and I wanted to start
>> putting our results into JIRA, but I wanted to be clear about the rev
>> against which these tests are conducted. Not sure how to get this from
>> the server, or if its deployment routine affords this sort of
>> systematic treatment just now.  Advice?
>>
>> ~Clay
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>> with a subject of "unsubscribe"
>>
>>      
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"
>
> Your input is important to improve upon our continuous efforts to service you better. Please e-mail my manager at anjli_jain@... with any feedback.
>
> CONFIDENTIALITY NOTICE:
> This e-mail together with any attachments is proprietary and confidential; intended for only the recipient(s) named above and may contain information that is privileged. You should not retain, copy or use this e-mail or any attachments for any purpose, or disclose all or any part of the contents to any person. Any views or opinions expressed in this e-mail are those of the author and do not represent those of CampusEAI Consortium or the Open Student Television Network. If you have received this e-mail in error, or are not the named recipient(s), you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited by the sender and to do so might constitute a violation of the Electronic Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the sender and delete this e-mail and any attachments from your computer. Warning: Although precautions have been taken to make sure no viruses are present in this

  e
>   -mail, the companies cannot accept responsibility for any loss or damage that arise from the use of this e-mail or attachments.
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"
>    


_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Oszkar Nagy]

Dear All,

I have made a confluence page with some basic QA information and a live
list of open JIRA issues (which will be updated to the proper JIRA
component as soon as we have the component set up for this work) which
is intended to provide information for anybody who is doing QA on Sakai
3 front-end.

The page can be found here:
http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information

Please feel free to add things, or let me know if I missed out anything.

Additionally, the current version on the dev server now displays debug
information in the title bar, which might help connecting bugs to
specific SVN revisions, deployment dates and pages.

All the best,
Oszkar
_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Michael Korcuska-2]

I should explain our intentions for Jira with respect to Sakai 3.  
We've created two jira projects for the Sakai 3 work:  K2 and "Sakai 3  
Core".  K2 is the kernel and will include most server-side work  
(including the Groups work).  Those working on K2 will determine what  
components that project needs to keep things organized.

"Sakai 3 Core" is intended for non-kernel work and there are two  
components currently, "3akai" for the general UX framework and  
"Groups" for UX efforts on group management. We'll add other  
components as other projects related to creating Sakai 3 need them. It  
is arguable that we didn't need to create a separate component for the  
Groups project, actually. Note that non-kernel service work (a  
business logic layer) is likely to be tracked in Sakai 3 core as well.

The goal is to minimize the number of projects and to use components  
within these two "master" projects to organize the work. The main  
reason for two separate project is that K2 is likely to have a  
different release cycle from Sakai 3 and this strongly implies (if not  
requires) a separate jira project. When add-ons/extensions to Sakai 3  
become available (contrib work) they will likely also be separate  
projects as they will have different release cycles.

The Sakai Foundation staff has recently spent some time thinking this  
through (also Confluence, Mailman, SVN) and I expect Pieter to produce  
some documentation for community comment RSN.

Michael

On Sep 25, 2009, at 03:29, Oszkar Nagy wrote:

> Dear All,
>
> I have made a confluence page with some basic QA information and a  
> live
> list of open JIRA issues (which will be updated to the proper JIRA
> component as soon as we have the component set up for this work) which
> is intended to provide information for anybody who is doing QA on  
> Sakai
> 3 front-end.
>
> The page can be found here:
> http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information
>
> Please feel free to add things, or let me know if I missed out  
> anything.
>
> Additionally, the current version on the dev server now displays debug
> information in the title bar, which might help connecting bugs to
> specific SVN revisions, deployment dates and pages.
>
> All the best,
> Oszkar
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>  with a subject of "unsubscribe"

--
Michael Korcuska
Executive Director, Sakai Foundation
mkorcuska@...
phone: [phone] (google voice)
skype: mkorcuska




_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Oszkar Nagy]

Thanks Michael, that makes perfect sense to me. In fact that's why we
had asked for the "3akai" component to be created under "Sakai 3 Core",
and I think this organisation works well.

Oszkar

On 28/09/2009 17:32, Michael Korcuska wrote:

> I should explain our intentions for Jira with respect to Sakai 3.
> We've created two jira projects for the Sakai 3 work:  K2 and "Sakai 3
> Core".  K2 is the kernel and will include most server-side work
> (including the Groups work).  Those working on K2 will determine what
> components that project needs to keep things organized.
>
> "Sakai 3 Core" is intended for non-kernel work and there are two
> components currently, "3akai" for the general UX framework and
> "Groups" for UX efforts on group management. We'll add other
> components as other projects related to creating Sakai 3 need them. It
> is arguable that we didn't need to create a separate component for the
> Groups project, actually. Note that non-kernel service work (a
> business logic layer) is likely to be tracked in Sakai 3 core as well.
>
> The goal is to minimize the number of projects and to use components
> within these two "master" projects to organize the work. The main
> reason for two separate project is that K2 is likely to have a
> different release cycle from Sakai 3 and this strongly implies (if not
> requires) a separate jira project. When add-ons/extensions to Sakai 3
> become available (contrib work) they will likely also be separate
> projects as they will have different release cycles.
>
> The Sakai Foundation staff has recently spent some time thinking this
> through (also Confluence, Mailman, SVN) and I expect Pieter to produce
> some documentation for community comment RSN.
>
> Michael
>
> On Sep 25, 2009, at 03:29, Oszkar Nagy wrote:
>
>> Dear All,
>>
>> I have made a confluence page with some basic QA information and a live
>> list of open JIRA issues (which will be updated to the proper JIRA
>> component as soon as we have the component set up for this work) which
>> is intended to provide information for anybody who is doing QA on Sakai
>> 3 front-end.
>>
>> The page can be found here:
>> http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information
>>
>> Please feel free to add things, or let me know if I missed out anything.
>>
>> Additionally, the current version on the dev server now displays debug
>> information in the title bar, which might help connecting bugs to
>> specific SVN revisions, deployment dates and pages.
>>
>> All the best,
>> Oszkar
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-ux-unsubscribe@... with a subject of
>> "unsubscribe"
>

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[jrnorman]

I confess I find these distinctions a bit confusing. I think it is  
worth having some discussion around what an alien arriving at planet  
Sakai should expect to understand by K2 and Core.

My sense is that when we discussed kernel in the K1 days, the goal was  
to get to some minimal kernel of services that could be performance-
tested and honed independently of the big release cycle. I *think*  
that in K2, that concept has become larger, in part as a result of the  
'everything is content' philosophy and the result is a rather fatter  
kernel than we aspired to in the days of starting to talk of kernels.  
This may be the right thing, but the current boundary is potentially  
an arbitrary boundary of the "services necessary to support the 3akai  
UX" and once the UX boundary expands, the original logic of the  
current boundary *may* disappear. Thus I believe it would be worth  
working through the services currently being implemented as K2 and  
asking if they really belong in a minimal kernel. I could read the  
post below to indicate K2 is a project name that covers kernel+kernel  
services and other non-kernel services. This sounds like all the back-
end services. If that is what is intended, then a name other than K2  
may make sense - e.g. Sakai 3 Services (a set of service components  
that includes a kernel component).

Similarly for 3akai. If the work contains some general framework  
elements that belong in a generic grouping of framework-ish code, then  
that might make sense, but if 'groups' UX is to be separated out, then  
I would argue much of the functionality of 3akai needs teasing out  
into components too - e.g. Search - which is a UX element that will  
need to continue to develop as more things become searchable and  
tagging allows more sophisticated searches. If we take this path, then  
I would argue that 3akai then becomes the "UX framework" component and  
the general name becomes - e.g. Sakai 3 UX components.

It is not clear why the release cycle of contrib projects would affect  
'core' (where 'core' is presumably defined as everything that is in a  
Sakai 3 release that is not claimed by the K2 team to be in the K2  
release - hardly a transparent definition). A more reasonable  
definition of 'core' in my view, would be a minimal set of UX and  
services that needs to be released together. Other combinations of UX  
and service that can be deployed optionally (and therefore on a  
different release cycle) might be called... well, 'options'. Whether  
the support status is 'officially supported' or 'contributor  
supported' is a separate issue IMO.

I'm probably being thick, but this looks more like working around the  
results of some accidents of history rather than a logical  
segmentation of work. Happy to be convinced otherwise.

John

On 28 Sep 2009, at 17:32, Michael Korcuska wrote:

> I should explain our intentions for Jira with respect to Sakai 3.
> We've created two jira projects for the Sakai 3 work:  K2 and "Sakai 3
> Core".  K2 is the kernel and will include most server-side work
> (including the Groups work).  Those working on K2 will determine what
> components that project needs to keep things organized.
>
> "Sakai 3 Core" is intended for non-kernel work and there are two
> components currently, "3akai" for the general UX framework and
> "Groups" for UX efforts on group management. We'll add other
> components as other projects related to creating Sakai 3 need them. It
> is arguable that we didn't need to create a separate component for the
> Groups project, actually. Note that non-kernel service work (a
> business logic layer) is likely to be tracked in Sakai 3 core as well.
>
> The goal is to minimize the number of projects and to use components
> within these two "master" projects to organize the work. The main
> reason for two separate project is that K2 is likely to have a
> different release cycle from Sakai 3 and this strongly implies (if not
> requires) a separate jira project. When add-ons/extensions to Sakai 3
> become available (contrib work) they will likely also be separate
> projects as they will have different release cycles.
>
> The Sakai Foundation staff has recently spent some time thinking this
> through (also Confluence, Mailman, SVN) and I expect Pieter to produce
> some documentation for community comment RSN.
>
> Michael
>
> On Sep 25, 2009, at 03:29, Oszkar Nagy wrote:
>
>> Dear All,
>>
>> I have made a confluence page with some basic QA information and a
>> live
>> list of open JIRA issues (which will be updated to the proper JIRA
>> component as soon as we have the component set up for this work)  
>> which
>> is intended to provide information for anybody who is doing QA on
>> Sakai
>> 3 front-end.
>>
>> The page can be found here:
>> http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information
>>
>> Please feel free to add things, or let me know if I missed out
>> anything.
>>
>> Additionally, the current version on the dev server now displays  
>> debug
>> information in the title bar, which might help connecting bugs to
>> specific SVN revisions, deployment dates and pages.
>>
>> All the best,
>> Oszkar
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>> with a subject of "unsubscribe"
>
> --
> Michael Korcuska
> Executive Director, Sakai Foundation
> mkorcuska@...
> phone: [phone] (google voice)
> skype: mkorcuska
>
>
>
>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>  with a subject of "unsubscribe"

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Michael Korcuska-2]

On Sep 28, 2009, at 12:25, John Norman wrote:

> I confess I find these distinctions a bit confusing. I think it is
> worth having some discussion around what an alien arriving at planet
> Sakai should expect to understand by K2 and Core.
>
> My sense is that when we discussed kernel in the K1 days, the goal was
> to get to some minimal kernel of services that could be performance-
> tested and honed independently of the big release cycle. I *think*
> that in K2, that concept has become larger, in part as a result of the
> 'everything is content' philosophy and the result is a rather fatter
> kernel than we aspired to in the days of starting to talk of kernels.
> This may be the right thing, but the current boundary is potentially
> an arbitrary boundary of the "services necessary to support the 3akai
> UX" and once the UX boundary expands, the original logic of the
> current boundary *may* disappear. Thus I believe it would be worth
> working through the services currently being implemented as K2 and
> asking if they really belong in a minimal kernel. I could read the
> post below to indicate K2 is a project name that covers kernel+kernel
> services and other non-kernel services. This sounds like all the back-
> end services. If that is what is intended, then a name other than K2
> may make sense - e.g. Sakai 3 Services (a set of service components
> that includes a kernel component).

No, sorry for the unclear language, the K2 jira project should just be  
the kernel, not other service work. I won't comment on how big that  
should be, but it should contain the components we intended to release/
test as you state.  If the current work is bigger than it should be  
for that goal then that's a separate discussion that should be had on  
the K2 list. We can adjust jira to reflect that. Other services work  
should be in Sakai 3 Core. Perhaps thats where "Groups" belongs, but I  
think that the service-side work there is properly part of kernel. If  
not, again, we can move the issues around as needed.

>
> Similarly for 3akai. If the work contains some general framework
> elements that belong in a generic grouping of framework-ish code, then
> that might make sense, but if 'groups' UX is to be separated out, then
> I would argue much of the functionality of 3akai needs teasing out
> into components too - e.g. Search - which is a UX element that will
> need to continue to develop as more things become searchable and
> tagging allows more sophisticated searches. If we take this path, then
> I would argue that 3akai then becomes the "UX framework" component and
> the general name becomes - e.g. Sakai 3 UX components.

I find too many components to be confusing to outsiders (what  
component should I add this issue to?) but components can be helpful  
when you're trying to organize work (what is left to be done on the  
Search UX work?).  Part of this is driven by logical separations in  
the software but part of it is also driven by groups of people who are  
working together on something (and trying to make their work easier).  
So there are tensions here that are not simply about having it make  
sense to aliens.

That said, 3akai is a component in the Sakai 3 Core project. It was  
created in the absence of other efforts on the Sakai 3 UX and without  
seeing a need to break it down into smaller pieces. It can be renamed/
split/whatever. How fine-grained the components inside a project  
should be is hard to settle on in advance. I think we need to be  
comfortable with some fluidity here and work with the project teams to  
try to meet their needs without creating a huge jumble that is  
intimidating to outsiders.

>
> It is not clear why the release cycle of contrib projects would affect
> 'core' (where 'core' is presumably defined as everything that is in a
> Sakai 3 release that is not claimed by the K2 team to be in the K2
> release - hardly a transparent definition). A more reasonable
> definition of 'core' in my view, would be a minimal set of UX and
> services that needs to be released together. Other combinations of UX
> and service that can be deployed optionally (and therefore on a
> different release cycle) might be called... well, 'options'. Whether
> the support status is 'officially supported' or 'contributor
> supported' is a separate issue IMO.

The release cycle of contrib projects don't affect core.  I was just  
pointing out that contrib projects would get their own jira projects  
whereas the functionality in the main Sakai release would *not* be in  
a separate project (although might have a component). An incubation  
project may start with

Now there is an interesting point here that I've wrestled with but  
don't think we can come to a conclusion at this date, namely, how many  
"layers" will there be in Sakai 3. We have at least this in theory:

Kernel: The base backend services
Sakai 3: The official release
Sakai 3 contrib/extensions: Unofficial functionality you may want to  
deploy

The suggestion is that we could have, instead something like the  
following:

Kernel: The base backend services
Sakai 3 Core: Some minimal base functionality
Sakai 3 T&L: The above + teaching and learning extensions
Sakai 3 Portfolio: The Core + portfolio functionality
Sakai 3 Research: The Core + research functionality
Sakai 3 Complete: All of the above
Sakai 3 contrib/extensions: Unofficial functionality you may want to  
deploy

But deployment profiles are different from jira projects. I don't  
think we (yet) know that we are doing something like this and, if we  
do, whether we would use separate release cycles (they could be  
deployment profiles of a common release). So for now I think we have a  
jira project for K2 and and project for "the rest of Sakai 3".

This is not an opposition to what you are suggesting, just a call for  
not structuring the work that way until it becomes accepted that  
that's how we are, in fact, going to work.

>
> I'm probably being thick, but this looks more like working around the
> results of some accidents of history rather than a logical
> segmentation of work. Happy to be convinced otherwise.
>
> John
>
> On 28 Sep 2009, at 17:32, Michael Korcuska wrote:
>
>> I should explain our intentions for Jira with respect to Sakai 3.
>> We've created two jira projects for the Sakai 3 work:  K2 and  
>> "Sakai 3
>> Core".  K2 is the kernel and will include most server-side work
>> (including the Groups work).  Those working on K2 will determine what
>> components that project needs to keep things organized.
>>
>> "Sakai 3 Core" is intended for non-kernel work and there are two
>> components currently, "3akai" for the general UX framework and
>> "Groups" for UX efforts on group management. We'll add other
>> components as other projects related to creating Sakai 3 need them.  
>> It
>> is arguable that we didn't need to create a separate component for  
>> the
>> Groups project, actually. Note that non-kernel service work (a
>> business logic layer) is likely to be tracked in Sakai 3 core as  
>> well.
>>
>> The goal is to minimize the number of projects and to use components
>> within these two "master" projects to organize the work. The main
>> reason for two separate project is that K2 is likely to have a
>> different release cycle from Sakai 3 and this strongly implies (if  
>> not
>> requires) a separate jira project. When add-ons/extensions to Sakai 3
>> become available (contrib work) they will likely also be separate
>> projects as they will have different release cycles.
>>
>> The Sakai Foundation staff has recently spent some time thinking this
>> through (also Confluence, Mailman, SVN) and I expect Pieter to  
>> produce
>> some documentation for community comment RSN.
>>
>> Michael
>>
>> On Sep 25, 2009, at 03:29, Oszkar Nagy wrote:
>>
>>> Dear All,
>>>
>>> I have made a confluence page with some basic QA information and a
>>> live
>>> list of open JIRA issues (which will be updated to the proper JIRA
>>> component as soon as we have the component set up for this work)
>>> which
>>> is intended to provide information for anybody who is doing QA on
>>> Sakai
>>> 3 front-end.
>>>
>>> The page can be found here:
>>> http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information
>>>
>>> Please feel free to add things, or let me know if I missed out
>>> anything.
>>>
>>> Additionally, the current version on the dev server now displays
>>> debug
>>> information in the title bar, which might help connecting bugs to
>>> specific SVN revisions, deployment dates and pages.
>>>
>>> All the best,
>>> Oszkar
>>> _______________________________________________
>>> sakai-ux mailing list
>>> sakai-ux@...
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>
>>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>>> with a subject of "unsubscribe"
>>
>> --
>> Michael Korcuska
>> Executive Director, Sakai Foundation
>> mkorcuska@...
>> phone: [phone] (google voice)
>> skype: mkorcuska
>>
>>
>>
>>
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>> with a subject of "unsubscribe"
>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>  with a subject of "unsubscribe"

--
Michael Korcuska
Executive Director, Sakai Foundation
mkorcuska@...
phone: [phone] (google voice)
skype: mkorcuska




_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[jrnorman]

On 28 Sep 2009, at 21:27, Michael Korcuska wrote:
> Part of this is driven by logical separations in the software but  
> part of it is also driven by groups of people who are working  
> together on something (and trying to make their work easier). So  
> there are tensions here that are not simply about having it make  
> sense to aliens.

I should not overly labour the point, but this is precisely where I  
disagree. If we want to make it easy for people to find places to join  
in and contribute to projects, I think we do need to have structures  
that reflect some external logic and not have them defined by what a  
group of people decided to work on. The implication is that the work  
of a group of people might cover more than one logical unit of work  
and that a given logical unit of work might not be fully addressed by  
the work of a group of people. It is important in the latter case to  
document the scope of the logical unit of work and describe the  
aspects that are not being addressed. This is a particularly good  
example of providing entry points for newcomers.

John


_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Clay Fenlason-3]

Oszkar:

I feel like I must be missing something simple and obvious, but I'm
having trouble finding this debug information in the title bar. I'm
certainly not seeing it on the screen, and thought it might be in the
page source somewhere, but I'm not seeing it. Pointer for a newb?

Also, am I understanding this right, that newly created issues should
go unassigned, and that people will assign them to themselves when
they pick them up? I also note that you don't appear to be on the list
of available assignees.

~Clay

On Fri, Sep 25, 2009 at 6:29 AM, Oszkar Nagy <oszkar@...> wrote:

> Dear All,
>
> I have made a confluence page with some basic QA information and a live list
> of open JIRA issues (which will be updated to the proper JIRA component as
> soon as we have the component set up for this work) which is intended to
> provide information for anybody who is doing QA on Sakai 3 front-end.
>
> The page can be found here:
> http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information
>
> Please feel free to add things, or let me know if I missed out anything.
>
> Additionally, the current version on the dev server now displays debug
> information in the title bar, which might help connecting bugs to specific
> SVN revisions, deployment dates and pages.
>
> All the best,
> Oszkar
>

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Oszkar Nagy]

Dear Clay,

The debug information is displayed next to the page title in your
browser (ie. the actual page title will contain the debug info), when
you navigate to:

http://3akai.sakaiproject.org/dev/

This way it doesn't affect anything on the actual interface and it is
constantly there to see. Please see the image attached as an example,
and/or let me know if you need any help on this.

As for the JIRA issues, I think you understand it right (at least that's
how I understand it as well), so issues go in unassigned and people
assign to themselves when they are actually working on it. At the moment
I can't assign issues to myself (nor anyone), but I emailed Anthony
White about this and hopefully should be fixed soon.

Oszkar


On 30/09/2009 15:40, Clay Fenlason wrote:

> Oszkar:
>
> I feel like I must be missing something simple and obvious, but I'm
> having trouble finding this debug information in the title bar. I'm
> certainly not seeing it on the screen, and thought it might be in the
> page source somewhere, but I'm not seeing it. Pointer for a newb?
>
> Also, am I understanding this right, that newly created issues should
> go unassigned, and that people will assign them to themselves when
> they pick them up? I also note that you don't appear to be on the list
> of available assignees.
>
> ~Clay
>
> On Fri, Sep 25, 2009 at 6:29 AM, Oszkar Nagy<oszkar@...>  wrote:
>    
>> Dear All,
>>
>> I have made a confluence page with some basic QA information and a live list
>> of open JIRA issues (which will be updated to the proper JIRA component as
>> soon as we have the component set up for this work) which is intended to
>> provide information for anybody who is doing QA on Sakai 3 front-end.
>>
>> The page can be found here:
>> http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information
>>
>> Please feel free to add things, or let me know if I missed out anything.
>>
>> Additionally, the current version on the dev server now displays debug
>> information in the title bar, which might help connecting bugs to specific
>> SVN revisions, deployment dates and pages.
>>
>> All the best,
>> Oszkar
>>
>>      
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"
>    

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[clayf]

Ah, that was the simple thing - I took title bar to refer to that
header bar in the interface. Sorry.

Also, the script that accomplishes this has created problems for at
least one of our platforms running Safari 3. But I havea a JIRA in
about that.

~Clay

On Wed, Sep 30, 2009 at 11:21 AM, Oszkar Nagy <oszkar@...> wrote:

> Dear Clay,
>
> The debug information is displayed next to the page title in your browser
> (ie. the actual page title will contain the debug info), when you navigate
> to:
>
> http://3akai.sakaiproject.org/dev/
>
> This way it doesn't affect anything on the actual interface and it is
> constantly there to see. Please see the image attached as an example, and/or
> let me know if you need any help on this.
>
> As for the JIRA issues, I think you understand it right (at least that's how
> I understand it as well), so issues go in unassigned and people assign to
> themselves when they are actually working on it. At the moment I can't
> assign issues to myself (nor anyone), but I emailed Anthony White about this
> and hopefully should be fixed soon.
>
> Oszkar
>
>
> On 30/09/2009 15:40, Clay Fenlason wrote:
>>
>> Oszkar:
>>
>> I feel like I must be missing something simple and obvious, but I'm
>> having trouble finding this debug information in the title bar. I'm
>> certainly not seeing it on the screen, and thought it might be in the
>> page source somewhere, but I'm not seeing it. Pointer for a newb?
>>
>> Also, am I understanding this right, that newly created issues should
>> go unassigned, and that people will assign them to themselves when
>> they pick them up? I also note that you don't appear to be on the list
>> of available assignees.
>>
>> ~Clay
>>
>> On Fri, Sep 25, 2009 at 6:29 AM, Oszkar Nagy<oszkar@...>
>>  wrote:
>>
>>>
>>> Dear All,
>>>
>>> I have made a confluence page with some basic QA information and a live
>>> list
>>> of open JIRA issues (which will be updated to the proper JIRA component
>>> as
>>> soon as we have the component set up for this work) which is intended to
>>> provide information for anybody who is doing QA on Sakai 3 front-end.
>>>
>>> The page can be found here:
>>> http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information
>>>
>>> Please feel free to add things, or let me know if I missed out anything.
>>>
>>> Additionally, the current version on the dev server now displays debug
>>> information in the title bar, which might help connecting bugs to
>>> specific
>>> SVN revisions, deployment dates and pages.
>>>
>>> All the best,
>>> Oszkar
>>>
>>>
>>
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>> with a subject of "unsubscribe"
>>
>
>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
> with a subject of "unsubscribe"
>

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[nato]

Wondering if it wouldn't make more sense to put debug info at the  
bottom of the output, right above the </body> tag. I see other systems  
do that to avoid interface disruption (might also make access to debug  
role-based, which allows it to be turned on even in production  
environments, but only run for the people who need to see it.

--
Nate Angell
Client Evangelist
http://www.rsmart.com

On Sep 30, 2009, at 8:21 AM, Oszkar Nagy wrote:

> Dear Clay,
>
> The debug information is displayed next to the page title in your  
> browser (ie. the actual page title will contain the debug info),  
> when you navigate to:
>
> http://3akai.sakaiproject.org/dev/
>
> This way it doesn't affect anything on the actual interface and it  
> is constantly there to see. Please see the image attached as an  
> example, and/or let me know if you need any help on this.
>
> As for the JIRA issues, I think you understand it right (at least  
> that's how I understand it as well), so issues go in unassigned and  
> people assign to themselves when they are actually working on it. At  
> the moment I can't assign issues to myself (nor anyone), but I  
> emailed Anthony White about this and hopefully should be fixed soon.
>
> Oszkar
>
>
> On 30/09/2009 15:40, Clay Fenlason wrote:
>> Oszkar:
>>
>> I feel like I must be missing something simple and obvious, but I'm
>> having trouble finding this debug information in the title bar. I'm
>> certainly not seeing it on the screen, and thought it might be in the
>> page source somewhere, but I'm not seeing it. Pointer for a newb?
>>
>> Also, am I understanding this right, that newly created issues should
>> go unassigned, and that people will assign them to themselves when
>> they pick them up? I also note that you don't appear to be on the  
>> list
>> of available assignees.
>>
>> ~Clay
>>
>> On Fri, Sep 25, 2009 at 6:29 AM, Oszkar  
>> Nagy<oszkar@...>  wrote:
>>
>>> Dear All,
>>>
>>> I have made a confluence page with some basic QA information and a  
>>> live list
>>> of open JIRA issues (which will be updated to the proper JIRA  
>>> component as
>>> soon as we have the component set up for this work) which is  
>>> intended to
>>> provide information for anybody who is doing QA on Sakai 3 front-
>>> end.
>>>
>>> The page can be found here:
>>> http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information
>>>
>>> Please feel free to add things, or let me know if I missed out  
>>> anything.
>>>
>>> Additionally, the current version on the dev server now displays  
>>> debug
>>> information in the title bar, which might help connecting bugs to  
>>> specific
>>> SVN revisions, deployment dates and pages.
>>>
>>> All the best,
>>> Oszkar
>>>
>>>
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>>  with a subject of "unsubscribe"
>>
>
> <Picture 1.png>_______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>  with a subject of "unsubscribe"

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[John Bush-2]

Or put it inside a HTML comment viewable only from source view

Sent from my commodore 64

On Sep 30, 2009, at 9:26 AM, Nate Angell <nate.angell@...> wrote:

> Wondering if it wouldn't make more sense to put debug info at the
> bottom of the output, right above the </body> tag. I see other systems
> do that to avoid interface disruption (might also make access to debug
> role-based, which allows it to be turned on even in production
> environments, but only run for the people who need to see it.
>
> --
> Nate Angell
> Client Evangelist
> http://www.rsmart.com
>
> On Sep 30, 2009, at 8:21 AM, Oszkar Nagy wrote:
>
>> Dear Clay,
>>
>> The debug information is displayed next to the page title in your
>> browser (ie. the actual page title will contain the debug info),
>> when you navigate to:
>>
>> http://3akai.sakaiproject.org/dev/
>>
>> This way it doesn't affect anything on the actual interface and it
>> is constantly there to see. Please see the image attached as an
>> example, and/or let me know if you need any help on this.
>>
>> As for the JIRA issues, I think you understand it right (at least
>> that's how I understand it as well), so issues go in unassigned and
>> people assign to themselves when they are actually working on it. At
>> the moment I can't assign issues to myself (nor anyone), but I
>> emailed Anthony White about this and hopefully should be fixed soon.
>>
>> Oszkar
>>
>>
>> On 30/09/2009 15:40, Clay Fenlason wrote:
>>> Oszkar:
>>>
>>> I feel like I must be missing something simple and obvious, but I'm
>>> having trouble finding this debug information in the title bar. I'm
>>> certainly not seeing it on the screen, and thought it might be in  
>>> the
>>> page source somewhere, but I'm not seeing it. Pointer for a newb?
>>>
>>> Also, am I understanding this right, that newly created issues  
>>> should
>>> go unassigned, and that people will assign them to themselves when
>>> they pick them up? I also note that you don't appear to be on the
>>> list
>>> of available assignees.
>>>
>>> ~Clay
>>>
>>> On Fri, Sep 25, 2009 at 6:29 AM, Oszkar
>>> Nagy<oszkar@...>  wrote:
>>>
>>>> Dear All,
>>>>
>>>> I have made a confluence page with some basic QA information and a
>>>> live list
>>>> of open JIRA issues (which will be updated to the proper JIRA
>>>> component as
>>>> soon as we have the component set up for this work) which is
>>>> intended to
>>>> provide information for anybody who is doing QA on Sakai 3 front-
>>>> end.
>>>>
>>>> The page can be found here:
>>>> http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information
>>>>
>>>> Please feel free to add things, or let me know if I missed out
>>>> anything.
>>>>
>>>> Additionally, the current version on the dev server now displays
>>>> debug
>>>> information in the title bar, which might help connecting bugs to
>>>> specific
>>>> SVN revisions, deployment dates and pages.
>>>>
>>>> All the best,
>>>> Oszkar
>>>>
>>>>
>>> _______________________________________________
>>> sakai-ux mailing list
>>> sakai-ux@...
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>
>>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>>> with a subject of "unsubscribe"
>>>
>>
>> <Picture 1.png>_______________________________________________
>> sakai-ux mailing list
>> sakai-ux@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>> with a subject of "unsubscribe"
>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>  with a subject of "unsubscribe"

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Oszkar Nagy]

I believe the debug info should be easily viewable for any
(non-technical) person doing testing, without looking at source or doing
any extra work.
Hence IMHO the title bar is the most readily accessible place, it is
there constantly, and took about 10 mins to implement the change.

Oszkar


On 30/09/2009 17:29, john.bush@... wrote:

> Or put it inside a HTML comment viewable only from source view
>
> Sent from my commodore 64
>
> On Sep 30, 2009, at 9:26 AM, Nate Angell <nate.angell@...> wrote:
>
>> Wondering if it wouldn't make more sense to put debug info at the
>> bottom of the output, right above the </body> tag. I see other systems
>> do that to avoid interface disruption (might also make access to debug
>> role-based, which allows it to be turned on even in production
>> environments, but only run for the people who need to see it.
>>
>> --
>> Nate Angell
>> Client Evangelist
>> http://www.rsmart.com
>>
>> On Sep 30, 2009, at 8:21 AM, Oszkar Nagy wrote:
>>
>>> Dear Clay,
>>>
>>> The debug information is displayed next to the page title in your
>>> browser (ie. the actual page title will contain the debug info),
>>> when you navigate to:
>>>
>>> http://3akai.sakaiproject.org/dev/
>>>
>>> This way it doesn't affect anything on the actual interface and it
>>> is constantly there to see. Please see the image attached as an
>>> example, and/or let me know if you need any help on this.
>>>
>>> As for the JIRA issues, I think you understand it right (at least
>>> that's how I understand it as well), so issues go in unassigned and
>>> people assign to themselves when they are actually working on it. At
>>> the moment I can't assign issues to myself (nor anyone), but I
>>> emailed Anthony White about this and hopefully should be fixed soon.
>>>
>>> Oszkar
>>>
>>>
>>> On 30/09/2009 15:40, Clay Fenlason wrote:
>>>> Oszkar:
>>>>
>>>> I feel like I must be missing something simple and obvious, but I'm
>>>> having trouble finding this debug information in the title bar. I'm
>>>> certainly not seeing it on the screen, and thought it might be in the
>>>> page source somewhere, but I'm not seeing it. Pointer for a newb?
>>>>
>>>> Also, am I understanding this right, that newly created issues should
>>>> go unassigned, and that people will assign them to themselves when
>>>> they pick them up? I also note that you don't appear to be on the
>>>> list
>>>> of available assignees.
>>>>
>>>> ~Clay
>>>>
>>>> On Fri, Sep 25, 2009 at 6:29 AM, Oszkar
>>>> Nagy<oszkar@...>  wrote:
>>>>
>>>>> Dear All,
>>>>>
>>>>> I have made a confluence page with some basic QA information and a
>>>>> live list
>>>>> of open JIRA issues (which will be updated to the proper JIRA
>>>>> component as
>>>>> soon as we have the component set up for this work) which is
>>>>> intended to
>>>>> provide information for anybody who is doing QA on Sakai 3 front-
>>>>> end.
>>>>>
>>>>> The page can be found here:
>>>>> http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information 
>>>>>
>>>>>
>>>>> Please feel free to add things, or let me know if I missed out
>>>>> anything.
>>>>>
>>>>> Additionally, the current version on the dev server now displays
>>>>> debug
>>>>> information in the title bar, which might help connecting bugs to
>>>>> specific
>>>>> SVN revisions, deployment dates and pages.
>>>>>
>>>>> All the best,
>>>>> Oszkar
>>>>>
>>>>>
>>>> _______________________________________________
>>>> sakai-ux mailing list
>>>> sakai-ux@...
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>>
>>>> TO UNSUBSCRIBE: send email to
>>>> sakai-ux-unsubscribe@...
>>>> with a subject of "unsubscribe"
>>>>
>>>
>>> <Picture 1.png>_______________________________________________
>>> sakai-ux mailing list
>>> sakai-ux@...
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-ux-unsubscribe@...
>>> with a subject of "unsubscribe"
>>
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-ux-unsubscribe@... with a subject of
>> "unsubscribe"

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Oliver Heyer]

I suggest we consider broad product domains prefixed to the names of the
widgets/workflows/components the UI is composed of. I think it would be
possible to define the product domains up front in the abstract, and
limit the widgets/workflows/components listed to those under active
design and development, allowing for the gradual expansion of the list.
For example:

Administration -- Space layout
Administration -- Membership list

Assessments -- Question builder
Assessments -- Grade release
Assessments -- Date picker

Content -- Text Editor
Content -- File Sharing Selector
Content -- Syllabus builder

Communication -- Email People Picker
Communication -- Discussion thread builder

Search --

This would hardly result in a set of perfect classifications, given the
inherent complexities of the software and project we're trying to model,
and the stated goal of moving away from "tools" and "tool owners." I'm
not sure how friendly any such organization will or can be to "aliens."
What we can aim for is some compromise that allows for consistency in
our terminology across project contexts.

Oliver

John Norman wrote:

> On 28 Sep 2009, at 21:27, Michael Korcuska wrote:
>  
>> Part of this is driven by logical separations in the software but  
>> part of it is also driven by groups of people who are working  
>> together on something (and trying to make their work easier). So  
>> there are tensions here that are not simply about having it make  
>> sense to aliens.
>>    
>
> I should not overly labour the point, but this is precisely where I  
> disagree. If we want to make it easy for people to find places to join  
> in and contribute to projects, I think we do need to have structures  
> that reflect some external logic and not have them defined by what a  
> group of people decided to work on. The implication is that the work  
> of a group of people might cover more than one logical unit of work  
> and that a given logical unit of work might not be fully addressed by  
> the work of a group of people. It is important in the latter case to  
> document the scope of the logical unit of work and describe the  
> aspects that are not being addressed. This is a particularly good  
> example of providing entry points for newcomers.
>
> John
>
>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"
>  

--
Oliver Heyer
Manager, Learning Systems Group
Educational Technology Services
U.C. Berkeley
[phone]

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[elicochran]

While I agree with Oszkar that this information should be easy to find  
without digging in source code, I have one major issue with putting it  
in the title bar: I can't copy and paste the data easily from the  
titlebar into JIRA (or anywhere else that I might want to reference it).

So another vote for putting it in plain text in the footer.

- Eli

On Sep 30, 2009, at 9:38 AM, Oszkar Nagy wrote:

> I believe the debug info should be easily viewable for any
> (non-technical) person doing testing, without looking at source or  
> doing
> any extra work.
> Hence IMHO the title bar is the most readily accessible place, it is
> there constantly, and took about 10 mins to implement the change.
>
> Oszkar
>
>
> On 30/09/2009 17:29, john.bush@... wrote:
>> Or put it inside a HTML comment viewable only from source view
>>
>> Sent from my commodore 64
>>
>> On Sep 30, 2009, at 9:26 AM, Nate Angell <nate.angell@...>  
>> wrote:
>>
>>> Wondering if it wouldn't make more sense to put debug info at the
>>> bottom of the output, right above the </body> tag. I see other  
>>> systems
>>> do that to avoid interface disruption (might also make access to  
>>> debug
>>> role-based, which allows it to be turned on even in production
>>> environments, but only run for the people who need to see it.
>>>
>>> --
>>> Nate Angell
>>> Client Evangelist
>>> http://www.rsmart.com
>>>
>>> On Sep 30, 2009, at 8:21 AM, Oszkar Nagy wrote:
>>>
>>>> Dear Clay,
>>>>
>>>> The debug information is displayed next to the page title in your
>>>> browser (ie. the actual page title will contain the debug info),
>>>> when you navigate to:
>>>>
>>>> http://3akai.sakaiproject.org/dev/
>>>>
>>>> This way it doesn't affect anything on the actual interface and it
>>>> is constantly there to see. Please see the image attached as an
>>>> example, and/or let me know if you need any help on this.
>>>>
>>>> As for the JIRA issues, I think you understand it right (at least
>>>> that's how I understand it as well), so issues go in unassigned and
>>>> people assign to themselves when they are actually working on it.  
>>>> At
>>>> the moment I can't assign issues to myself (nor anyone), but I
>>>> emailed Anthony White about this and hopefully should be fixed  
>>>> soon.
>>>>
>>>> Oszkar
>>>>
>>>>
>>>> On 30/09/2009 15:40, Clay Fenlason wrote:
>>>>> Oszkar:
>>>>>
>>>>> I feel like I must be missing something simple and obvious, but  
>>>>> I'm
>>>>> having trouble finding this debug information in the title bar.  
>>>>> I'm
>>>>> certainly not seeing it on the screen, and thought it might be  
>>>>> in the
>>>>> page source somewhere, but I'm not seeing it. Pointer for a newb?
>>>>>
>>>>> Also, am I understanding this right, that newly created issues  
>>>>> should
>>>>> go unassigned, and that people will assign them to themselves when
>>>>> they pick them up? I also note that you don't appear to be on the
>>>>> list
>>>>> of available assignees.
>>>>>
>>>>> ~Clay
>>>>>
>>>>> On Fri, Sep 25, 2009 at 6:29 AM, Oszkar
>>>>> Nagy<oszkar@...>  wrote:
>>>>>
>>>>>> Dear All,
>>>>>>
>>>>>> I have made a confluence page with some basic QA information  
>>>>>> and a
>>>>>> live list
>>>>>> of open JIRA issues (which will be updated to the proper JIRA
>>>>>> component as
>>>>>> soon as we have the component set up for this work) which is
>>>>>> intended to
>>>>>> provide information for anybody who is doing QA on Sakai 3 front-
>>>>>> end.
>>>>>>
>>>>>> The page can be found here:
>>>>>> http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information
>>>>>>
>>>>>>
>>>>>> Please feel free to add things, or let me know if I missed out
>>>>>> anything.
>>>>>>
>>>>>> Additionally, the current version on the dev server now displays
>>>>>> debug
>>>>>> information in the title bar, which might help connecting bugs to
>>>>>> specific
>>>>>> SVN revisions, deployment dates and pages.
>>>>>>
>>>>>> All the best,
>>>>>> Oszkar
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> sakai-ux mailing list
>>>>> sakai-ux@...
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>>>
>>>>> TO UNSUBSCRIBE: send email to
>>>>> sakai-ux-unsubscribe@...
>>>>> with a subject of "unsubscribe"
>>>>>
>>>>
>>>> <Picture 1.png>_______________________________________________
>>>> sakai-ux mailing list
>>>> sakai-ux@...
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>>
>>>> TO UNSUBSCRIBE: send email to
>>>> sakai-ux-unsubscribe@...
>>>> with a subject of "unsubscribe"
>>>
>>> _______________________________________________
>>> sakai-ux mailing list
>>> sakai-ux@...
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-ux-unsubscribe@... with a subject of
>>> "unsubscribe"
>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>  with a subject of "unsubscribe"

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley


_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Steve Swinsburg-3]

Another vote for this info in the footer, then it can be switched on and off as previously mentioned and it's how we have Sakai2:

2.5.x on HSQLDB - Built: 09/30/09 00:00 - Sakai sakai_2-5-x - Server sakai-sand.uits.iupui.edu

cheers,
Steve

Eli Cochran wrote:

While I agree with Oszkar that this information should be easy to find  
without digging in source code, I have one major issue with putting it  
in the title bar: I can't copy and paste the data easily from the  
titlebar into JIRA (or anywhere else that I might want to reference it).

So another vote for putting it in plain text in the footer.

- Eli

On Sep 30, 2009, at 9:38 AM, Oszkar Nagy wrote:

  

I believe the debug info should be easily viewable for any
(non-technical) person doing testing, without looking at source or  
doing
any extra work.
Hence IMHO the title bar is the most readily accessible place, it is
there constantly, and took about 10 mins to implement the change.

Oszkar


On 30/09/2009 17:29, john.bush@... wrote:
    

Or put it inside a HTML comment viewable only from source view

Sent from my commodore 64

On Sep 30, 2009, at 9:26 AM, Nate Angell nate.angell@...  
wrote:

      

Wondering if it wouldn't make more sense to put debug info at the
bottom of the output, right above the </body> tag. I see other  
systems
do that to avoid interface disruption (might also make access to  
debug
role-based, which allows it to be turned on even in production
environments, but only run for the people who need to see it.

-- 
Nate Angell
Client Evangelist
http://www.rsmart.com

On Sep 30, 2009, at 8:21 AM, Oszkar Nagy wrote:

        

Dear Clay,

The debug information is displayed next to the page title in your
browser (ie. the actual page title will contain the debug info),
when you navigate to:

http://3akai.sakaiproject.org/dev/

This way it doesn't affect anything on the actual interface and it
is constantly there to see. Please see the image attached as an
example, and/or let me know if you need any help on this.

As for the JIRA issues, I think you understand it right (at least
that's how I understand it as well), so issues go in unassigned and
people assign to themselves when they are actually working on it.  
At
the moment I can't assign issues to myself (nor anyone), but I
emailed Anthony White about this and hopefully should be fixed  
soon.

Oszkar


On 30/09/2009 15:40, Clay Fenlason wrote:
          

Oszkar:

I feel like I must be missing something simple and obvious, but  
I'm
having trouble finding this debug information in the title bar.  
I'm
certainly not seeing it on the screen, and thought it might be  
in the
page source somewhere, but I'm not seeing it. Pointer for a newb?

Also, am I understanding this right, that newly created issues  
should
go unassigned, and that people will assign them to themselves when
they pick them up? I also note that you don't appear to be on the
list
of available assignees.

~Clay

On Fri, Sep 25, 2009 at 6:29 AM, Oszkar
Nagyoszkar@...  wrote:

            

Dear All,

I have made a confluence page with some basic QA information  
and a
live list
of open JIRA issues (which will be updated to the proper JIRA
component as
soon as we have the component set up for this work) which is
intended to
provide information for anybody who is doing QA on Sakai 3 front-
end.

The page can be found here:
http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information


Please feel free to add things, or let me know if I missed out
anything.

Additionally, the current version on the dev server now displays
debug
information in the title bar, which might help connecting bugs to
specific
SVN revisions, deployment dates and pages.

All the best,
Oszkar


              

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to
sakai-ux-unsubscribe@...
with a subject of "unsubscribe"

            

<Picture 1.png>_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to
sakai-ux-unsubscribe@...
with a subject of "unsubscribe"
          

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to
sakai-ux-unsubscribe@... with a subject of
"unsubscribe"
        

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... 
 with a subject of "unsubscribe"
    

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley


_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"
  

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Oszkar Nagy]

Eli you are right about the copy/paste issue, that would make it even
more easier.

I will be doing modifications to the way the footer is handled and
displayed in the next days, so the debug information will also be
included there, with the ability to turn it on or off. This will be in
the next server redeployment, when the new version of the kernel is
available too.

Oszkar

On 30/09/2009 23:45, Eli Cochran wrote:

> While I agree with Oszkar that this information should be easy to find
> without digging in source code, I have one major issue with putting it
> in the title bar: I can't copy and paste the data easily from the
> titlebar into JIRA (or anywhere else that I might want to reference it).
>
> So another vote for putting it in plain text in the footer.
>
> - Eli
>
> On Sep 30, 2009, at 9:38 AM, Oszkar Nagy wrote:
>
>> I believe the debug info should be easily viewable for any
>> (non-technical) person doing testing, without looking at source or doing
>> any extra work.
>> Hence IMHO the title bar is the most readily accessible place, it is
>> there constantly, and took about 10 mins to implement the change.
>>
>> Oszkar
>>
>>
>> On 30/09/2009 17:29, john.bush@... wrote:
>>> Or put it inside a HTML comment viewable only from source view
>>>
>>> Sent from my commodore 64
>>>
>>> On Sep 30, 2009, at 9:26 AM, Nate Angell <nate.angell@...>
>>> wrote:
>>>
>>>> Wondering if it wouldn't make more sense to put debug info at the
>>>> bottom of the output, right above the </body> tag. I see other systems
>>>> do that to avoid interface disruption (might also make access to debug
>>>> role-based, which allows it to be turned on even in production
>>>> environments, but only run for the people who need to see it.
>>>>
>>>> --
>>>> Nate Angell
>>>> Client Evangelist
>>>> http://www.rsmart.com
>>>>
>>>> On Sep 30, 2009, at 8:21 AM, Oszkar Nagy wrote:
>>>>
>>>>> Dear Clay,
>>>>>
>>>>> The debug information is displayed next to the page title in your
>>>>> browser (ie. the actual page title will contain the debug info),
>>>>> when you navigate to:
>>>>>
>>>>> http://3akai.sakaiproject.org/dev/
>>>>>
>>>>> This way it doesn't affect anything on the actual interface and it
>>>>> is constantly there to see. Please see the image attached as an
>>>>> example, and/or let me know if you need any help on this.
>>>>>
>>>>> As for the JIRA issues, I think you understand it right (at least
>>>>> that's how I understand it as well), so issues go in unassigned and
>>>>> people assign to themselves when they are actually working on it. At
>>>>> the moment I can't assign issues to myself (nor anyone), but I
>>>>> emailed Anthony White about this and hopefully should be fixed soon.
>>>>>
>>>>> Oszkar
>>>>>
>>>>>
>>>>> On 30/09/2009 15:40, Clay Fenlason wrote:
>>>>>> Oszkar:
>>>>>>
>>>>>> I feel like I must be missing something simple and obvious, but I'm
>>>>>> having trouble finding this debug information in the title bar. I'm
>>>>>> certainly not seeing it on the screen, and thought it might be in
>>>>>> the
>>>>>> page source somewhere, but I'm not seeing it. Pointer for a newb?
>>>>>>
>>>>>> Also, am I understanding this right, that newly created issues
>>>>>> should
>>>>>> go unassigned, and that people will assign them to themselves when
>>>>>> they pick them up? I also note that you don't appear to be on the
>>>>>> list
>>>>>> of available assignees.
>>>>>>
>>>>>> ~Clay
>>>>>>
>>>>>> On Fri, Sep 25, 2009 at 6:29 AM, Oszkar
>>>>>> Nagy<oszkar@...>  wrote:
>>>>>>
>>>>>>> Dear All,
>>>>>>>
>>>>>>> I have made a confluence page with some basic QA information and a
>>>>>>> live list
>>>>>>> of open JIRA issues (which will be updated to the proper JIRA
>>>>>>> component as
>>>>>>> soon as we have the component set up for this work) which is
>>>>>>> intended to
>>>>>>> provide information for anybody who is doing QA on Sakai 3 front-
>>>>>>> end.
>>>>>>>
>>>>>>> The page can be found here:
>>>>>>> http://confluence.sakaiproject.org/display/3AK/Sakai+3+UX+QA+Information 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Please feel free to add things, or let me know if I missed out
>>>>>>> anything.
>>>>>>>
>>>>>>> Additionally, the current version on the dev server now displays
>>>>>>> debug
>>>>>>> information in the title bar, which might help connecting bugs to
>>>>>>> specific
>>>>>>> SVN revisions, deployment dates and pages.
>>>>>>>
>>>>>>> All the best,
>>>>>>> Oszkar
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> sakai-ux mailing list
>>>>>> sakai-ux@...
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>>>>
>>>>>> TO UNSUBSCRIBE: send email to
>>>>>> sakai-ux-unsubscribe@...
>>>>>> with a subject of "unsubscribe"
>>>>>>
>>>>>
>>>>> <Picture 1.png>_______________________________________________
>>>>> sakai-ux mailing list
>>>>> sakai-ux@...
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>>>
>>>>> TO UNSUBSCRIBE: send email to
>>>>> sakai-ux-unsubscribe@...
>>>>> with a subject of "unsubscribe"
>>>>
>>>> _______________________________________________
>>>> sakai-ux mailing list
>>>> sakai-ux@...
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>>
>>>> TO UNSUBSCRIBE: send email to
>>>> sakai-ux-unsubscribe@... with a subject of
>>>> "unsubscribe"
>>
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-ux-unsubscribe@... with a subject of
>> "unsubscribe"
>
> . . . . . . . . . . .  .  .   .    .      .         .              
> .                     .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"