Home » Archived » EPF » Guidance Attachment
| |
| Re: Guidance Attachment [message #25890 is a reply to message #22162] |
Tue, 19 December 2006 22:28   |
 Rob Robason
Messages: 72
Registered: July 2009 |
Member |
|
|
I can certainly see the logic in providing the attachment capability for
templates. However, there are several situations I've already encountered
where it would be useful to have an attached file or a URL appear in the
Guidance section. In my case, the URL provides more versatility, since I can
store files on a server and use a URL to refer to them.
It's true that a URL would need a label, and that the rich text editor
provides that capability, but this misses the point that the reference is
then buried in the textual description and is missing from the list of
Guidance materials. The benefit of standard document layout is that I can
visually leap to the area of the form where I expect to find what I'm
looking for, but that breaks down if all the guidance isn't in the Guidance
section.
I don't agree that this is only a transient need. In some cases it's
necessary to refer to materials that are not managed by the process
engineer. It may not make sense to import certain information into EPF. For
example, it would be a mistake to try to duplicate controlled content into
an EPF object and then have to maintain synchronization. Some examples I've
run into: references to the CMMI, IEEE standards, and useful web resources -
none of which will ever be imported to EPF.
Adding a URL Guidance subclass, with label and location values, would be
great! By the way, this could then be included in the rich text by
reference, as can other guidance types.
Rob
"Peter Haumer" <phaumer@us.ibm.com> wrote in message
news:eig201$4pp$1@utils.eclipse.org...
> Hello.
> (1) As I mentioned in the email list, you can attach and provide URLs in
> the rich text fields using the Add Link button. The reason why there is
> not separate field is that attachments for these types are not the normal
> case, but rather the exception until you migrated your content in the EPF
> format. For templates an attachment is required as you need to provide the
> attachment for that third party tool the template describes. That's why
> there is a separate field, to remind people.
>
> (2) We could provide another field for templates that manage URLs, but in
> most cases you want to document your URLs, i.e. explain what they point
> to, don't you? So the rich text fields seem to be the best place to put
> these.
>
> --
>
>
> Thanks and best regards,
> Peter Haumer.
>
> ____________________________________________________________ __
>
> PETER HAUMER
> IBM | Eclipse Process Framework Committer
> ____________________________________________________________ __
> "Sarav" <Saravanan.Sankar@cognizant.com> wrote in message
> news:4f104285abc2264b8c1775b2ca3dced8$1@www.eclipse.org...
>> Can some one answer my following EPF queries? 1. Why we are not
>> allowing attachments for all guidance types, currently it's allowed only
>> for Template Guidance type. For organizations which already have a stable
>> process and wants to enhance the system with EPF, it looks to be a bottle
>> neck since it's not allowing me to upload the existing guidance's in the
>> organization. This is more necessary because in larger organizations
>> guidance are off different formats like, doc, excel, e-learning materials
>> etc. 2. Similarly along with attachment option, we should also
>> provide an option to give the URLS for the guidance's. So that the end
>> user will have the freedoms to neither upload the Guidance documents nor
>> give the URL for the same.
>
>
|
|
|
| Re: Guidance Attachment [message #26135 is a reply to message #25890] |
Tue, 09 January 2007 17:46 |
Eclipse User |
|
|
|
Originally posted by: phaumer.xxx.com
Hello Rob.
We are looking into a general reference management mechanism and the need to
provide a summary of references for an element or a group of elements. This
shall be done independently of a field for attachments for guidance, but in
a generic way for all elements.
The solution I have in mind would provide a BibTex like reference management
system and the ability to determine for elements and element types if
summaries shall be published or not for references used within the text
field as well as manually selected references. Anyone interested in writing
code for such a solution?
--
Thanks and best regards,
Peter Haumer.
____________________________________________________________ __
PETER HAUMER
IBM | Eclipse Process Framework Committer
____________________________________________________________ __
"Rob Robason" <rob.robason@windriver.com> wrote in message
news:em9p30$40d$1@utils.eclipse.org...
>I can certainly see the logic in providing the attachment capability for
>templates. However, there are several situations I've already encountered
>where it would be useful to have an attached file or a URL appear in the
>Guidance section. In my case, the URL provides more versatility, since I
>can store files on a server and use a URL to refer to them.
>
> It's true that a URL would need a label, and that the rich text editor
> provides that capability, but this misses the point that the reference is
> then buried in the textual description and is missing from the list of
> Guidance materials. The benefit of standard document layout is that I can
> visually leap to the area of the form where I expect to find what I'm
> looking for, but that breaks down if all the guidance isn't in the
> Guidance section.
>
> I don't agree that this is only a transient need. In some cases it's
> necessary to refer to materials that are not managed by the process
> engineer. It may not make sense to import certain information into EPF.
> For example, it would be a mistake to try to duplicate controlled content
> into an EPF object and then have to maintain synchronization. Some
> examples I've run into: references to the CMMI, IEEE standards, and useful
> web resources - none of which will ever be imported to EPF.
>
> Adding a URL Guidance subclass, with label and location values, would be
> great! By the way, this could then be included in the rich text by
> reference, as can other guidance types.
>
> Rob
>
> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
> news:eig201$4pp$1@utils.eclipse.org...
>> Hello.
>> (1) As I mentioned in the email list, you can attach and provide URLs in
>> the rich text fields using the Add Link button. The reason why there is
>> not separate field is that attachments for these types are not the normal
>> case, but rather the exception until you migrated your content in the EPF
>> format. For templates an attachment is required as you need to provide
>> the attachment for that third party tool the template describes. That's
>> why there is a separate field, to remind people.
>>
>> (2) We could provide another field for templates that manage URLs, but in
>> most cases you want to document your URLs, i.e. explain what they point
>> to, don't you? So the rich text fields seem to be the best place to put
>> these.
>>
>> --
>>
>>
>> Thanks and best regards,
>> Peter Haumer.
>>
>> ____________________________________________________________ __
>>
>> PETER HAUMER
>> IBM | Eclipse Process Framework Committer
>> ____________________________________________________________ __
>> "Sarav" <Saravanan.Sankar@cognizant.com> wrote in message
>> news:4f104285abc2264b8c1775b2ca3dced8$1@www.eclipse.org...
>>> Can some one answer my following EPF queries? 1. Why we are not
>>> allowing attachments for all guidance types, currently it's allowed only
>>> for Template Guidance type. For organizations which already have a
>>> stable process and wants to enhance the system with EPF, it looks to be
>>> a bottle neck since it's not allowing me to upload the existing
>>> guidance's in the organization. This is more necessary because in larger
>>> organizations guidance are off different formats like, doc, excel,
>>> e-learning materials etc. 2. Similarly along with attachment
>>> option, we should also provide an option to give the URLS for the
>>> guidance's. So that the end user will have the freedoms to neither
>>> upload the Guidance documents nor give the URL for the same.
>>
>>
>
>
|
|
|
| Re: Guidance Attachment [message #26819 is a reply to message #22162] |
Thu, 18 January 2007 10:11 |
jan masaryk
Messages: 50
Registered: July 2009 |
Member |
|
|
Hi Peter,
I definitelly agree with you that we should be very carefull in using
attachments in model
but during using EPFC I recognized that it can be very helpful has
option to attach file to Example.
Just let's imagine that we have Template 'project plan' in MS Project plan
format.
We find usefull attach some examples how this template can be use ... and
that's again MS Project file. :-)
all the best,
jan
Hello.
(1) As I mentioned in the email list, you can attach and provide URLs in
the
rich text fields using the Add Link button. The reason why there is not
separate field is that attachments for these types are not the normal case,
but rather the exception until you migrated your content in the EPF format.
For templates an attachment is required as you need to provide the
attachment for that third party tool the template describes. That's why
there is a separate field, to remind people.
(2) We could provide another field for templates that manage URLs, but in
most cases you want to document your URLs, i.e. explain what they point to,
don't you? So the rich text fields seem to be the best place to put these.
On Fri, 03 Nov 2006 19:32:28 +0100, Peter Haumer <phaumer@us.ibm.com>
wrote:
> Hello.
> (1) As I mentioned in the email list, you can attach and provide URLs in
> the
> rich text fields using the Add Link button. The reason why there is not
> separate field is that attachments for these types are not the normal
> case,
> but rather the exception until you migrated your content in the EPF
> format.
> For templates an attachment is required as you need to provide the
> attachment for that third party tool the template describes. That's why
> there is a separate field, to remind people.
>
> (2) We could provide another field for templates that manage URLs, but in
> most cases you want to document your URLs, i.e. explain what they point
> to,
> don't you? So the rich text fields seem to be the best place to put
> these.
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: Guidance Attachment [message #26899 is a reply to message #26819] |
Thu, 18 January 2007 21:18 |
| Eclipse User |
|
|
|
Originally posted by: phaumer.xxx.com
I fully agree and that's why you can embed attachments in every rich text
field in the tool. The separate attachment fields were intended to remind
people not to forget attachments. We are currently updating the forms for
example, reusable asset, report and whitepaper to have such a field as well.
--
Thanks and best regards,
Peter Haumer.
____________________________________________________________ __
PETER HAUMER
IBM | Eclipse Process Framework Committer
____________________________________________________________ __
"Jan Masaryk" <jan.masaryk@asseco.sk> wrote in message
news:op.tmcg80g8clxtfu@masarykj.asset-internal...
> Hi Peter,
>
> I definitelly agree with you that we should be very carefull in using
> attachments in model
> but during using EPFC I recognized that it can be very helpful has
> option to attach file to Example.
>
> Just let's imagine that we have Template 'project plan' in MS Project plan
> format.
> We find usefull attach some examples how this template can be use ... and
> that's again MS Project file. :-)
>
> all the best,
> jan
>
>
> Hello.
> (1) As I mentioned in the email list, you can attach and provide URLs in
> the
> rich text fields using the Add Link button. The reason why there is not
> separate field is that attachments for these types are not the normal
> case,
> but rather the exception until you migrated your content in the EPF
> format.
> For templates an attachment is required as you need to provide the
> attachment for that third party tool the template describes. That's why
> there is a separate field, to remind people.
>
> (2) We could provide another field for templates that manage URLs, but in
> most cases you want to document your URLs, i.e. explain what they point
> to,
> don't you? So the rich text fields seem to be the best place to put these.
>
> On Fri, 03 Nov 2006 19:32:28 +0100, Peter Haumer <phaumer@us.ibm.com>
> wrote:
>
>> Hello.
>> (1) As I mentioned in the email list, you can attach and provide URLs in
>> the
>> rich text fields using the Add Link button. The reason why there is not
>> separate field is that attachments for these types are not the normal
>> case,
>> but rather the exception until you migrated your content in the EPF
>> format.
>> For templates an attachment is required as you need to provide the
>> attachment for that third party tool the template describes. That's why
>> there is a separate field, to remind people.
>>
>> (2) We could provide another field for templates that manage URLs, but in
>> most cases you want to document your URLs, i.e. explain what they point
>> to,
>> don't you? So the rich text fields seem to be the best place to put
>> these.
>>
>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
| |
| Re: Guidance Attachment [message #574302 is a reply to message #22162] |
Tue, 19 December 2006 22:28 |
Rob Robason
Messages: 72
Registered: July 2009 |
Member |
|
|
I can certainly see the logic in providing the attachment capability for
templates. However, there are several situations I've already encountered
where it would be useful to have an attached file or a URL appear in the
Guidance section. In my case, the URL provides more versatility, since I can
store files on a server and use a URL to refer to them.
It's true that a URL would need a label, and that the rich text editor
provides that capability, but this misses the point that the reference is
then buried in the textual description and is missing from the list of
Guidance materials. The benefit of standard document layout is that I can
visually leap to the area of the form where I expect to find what I'm
looking for, but that breaks down if all the guidance isn't in the Guidance
section.
I don't agree that this is only a transient need. In some cases it's
necessary to refer to materials that are not managed by the process
engineer. It may not make sense to import certain information into EPF. For
example, it would be a mistake to try to duplicate controlled content into
an EPF object and then have to maintain synchronization. Some examples I've
run into: references to the CMMI, IEEE standards, and useful web resources -
none of which will ever be imported to EPF.
Adding a URL Guidance subclass, with label and location values, would be
great! By the way, this could then be included in the rich text by
reference, as can other guidance types.
Rob
"Peter Haumer" <phaumer@us.ibm.com> wrote in message
news:eig201$4pp$1@utils.eclipse.org...
> Hello.
> (1) As I mentioned in the email list, you can attach and provide URLs in
> the rich text fields using the Add Link button. The reason why there is
> not separate field is that attachments for these types are not the normal
> case, but rather the exception until you migrated your content in the EPF
> format. For templates an attachment is required as you need to provide the
> attachment for that third party tool the template describes. That's why
> there is a separate field, to remind people.
>
> (2) We could provide another field for templates that manage URLs, but in
> most cases you want to document your URLs, i.e. explain what they point
> to, don't you? So the rich text fields seem to be the best place to put
> these.
>
> --
>
>
> Thanks and best regards,
> Peter Haumer.
>
> ____________________________________________________________ __
>
> PETER HAUMER
> IBM | Eclipse Process Framework Committer
> ____________________________________________________________ __
> "Sarav" <Saravanan.Sankar@cognizant.com> wrote in message
> news:4f104285abc2264b8c1775b2ca3dced8$1@www.eclipse.org...
>> Can some one answer my following EPF queries? 1. Why we are not
>> allowing attachments for all guidance types, currently it's allowed only
>> for Template Guidance type. For organizations which already have a stable
>> process and wants to enhance the system with EPF, it looks to be a bottle
>> neck since it's not allowing me to upload the existing guidance's in the
>> organization. This is more necessary because in larger organizations
>> guidance are off different formats like, doc, excel, e-learning materials
>> etc. 2. Similarly along with attachment option, we should also
>> provide an option to give the URLS for the guidance's. So that the end
>> user will have the freedoms to neither upload the Guidance documents nor
>> give the URL for the same.
>
>
|
|
|
| Re: Guidance Attachment [message #574458 is a reply to message #25890] |
Tue, 09 January 2007 17:46 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Hello Rob.
We are looking into a general reference management mechanism and the need to
provide a summary of references for an element or a group of elements. This
shall be done independently of a field for attachments for guidance, but in
a generic way for all elements.
The solution I have in mind would provide a BibTex like reference management
system and the ability to determine for elements and element types if
summaries shall be published or not for references used within the text
field as well as manually selected references. Anyone interested in writing
code for such a solution?
--
Thanks and best regards,
Peter Haumer.
____________________________________________________________ __
PETER HAUMER
IBM | Eclipse Process Framework Committer
____________________________________________________________ __
"Rob Robason" <rob.robason@windriver.com> wrote in message
news:em9p30$40d$1@utils.eclipse.org...
>I can certainly see the logic in providing the attachment capability for
>templates. However, there are several situations I've already encountered
>where it would be useful to have an attached file or a URL appear in the
>Guidance section. In my case, the URL provides more versatility, since I
>can store files on a server and use a URL to refer to them.
>
> It's true that a URL would need a label, and that the rich text editor
> provides that capability, but this misses the point that the reference is
> then buried in the textual description and is missing from the list of
> Guidance materials. The benefit of standard document layout is that I can
> visually leap to the area of the form where I expect to find what I'm
> looking for, but that breaks down if all the guidance isn't in the
> Guidance section.
>
> I don't agree that this is only a transient need. In some cases it's
> necessary to refer to materials that are not managed by the process
> engineer. It may not make sense to import certain information into EPF.
> For example, it would be a mistake to try to duplicate controlled content
> into an EPF object and then have to maintain synchronization. Some
> examples I've run into: references to the CMMI, IEEE standards, and useful
> web resources - none of which will ever be imported to EPF.
>
> Adding a URL Guidance subclass, with label and location values, would be
> great! By the way, this could then be included in the rich text by
> reference, as can other guidance types.
>
> Rob
>
> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
> news:eig201$4pp$1@utils.eclipse.org...
>> Hello.
>> (1) As I mentioned in the email list, you can attach and provide URLs in
>> the rich text fields using the Add Link button. The reason why there is
>> not separate field is that attachments for these types are not the normal
>> case, but rather the exception until you migrated your content in the EPF
>> format. For templates an attachment is required as you need to provide
>> the attachment for that third party tool the template describes. That's
>> why there is a separate field, to remind people.
>>
>> (2) We could provide another field for templates that manage URLs, but in
>> most cases you want to document your URLs, i.e. explain what they point
>> to, don't you? So the rich text fields seem to be the best place to put
>> these.
>>
>> --
>>
>>
>> Thanks and best regards,
>> Peter Haumer.
>>
>> ____________________________________________________________ __
>>
>> PETER HAUMER
>> IBM | Eclipse Process Framework Committer
>> ____________________________________________________________ __
>> "Sarav" <Saravanan.Sankar@cognizant.com> wrote in message
>> news:4f104285abc2264b8c1775b2ca3dced8$1@www.eclipse.org...
>>> Can some one answer my following EPF queries? 1. Why we are not
>>> allowing attachments for all guidance types, currently it's allowed only
>>> for Template Guidance type. For organizations which already have a
>>> stable process and wants to enhance the system with EPF, it looks to be
>>> a bottle neck since it's not allowing me to upload the existing
>>> guidance's in the organization. This is more necessary because in larger
>>> organizations guidance are off different formats like, doc, excel,
>>> e-learning materials etc. 2. Similarly along with attachment
>>> option, we should also provide an option to give the URLS for the
>>> guidance's. So that the end user will have the freedoms to neither
>>> upload the Guidance documents nor give the URL for the same.
>>
>>
>
>
|
|
|
| Re: Guidance Attachment [message #574966 is a reply to message #22162] |
Thu, 18 January 2007 10:11 |
jan masaryk
Messages: 50
Registered: July 2009 |
Member |
|
|
Hi Peter,
I definitelly agree with you that we should be very carefull in using
attachments in model
but during using EPFC I recognized that it can be very helpful has
option to attach file to Example.
Just let's imagine that we have Template 'project plan' in MS Project plan
format.
We find usefull attach some examples how this template can be use ... and
that's again MS Project file. :-)
all the best,
jan
Hello.
(1) As I mentioned in the email list, you can attach and provide URLs in
the
rich text fields using the Add Link button. The reason why there is not
separate field is that attachments for these types are not the normal case,
but rather the exception until you migrated your content in the EPF format.
For templates an attachment is required as you need to provide the
attachment for that third party tool the template describes. That's why
there is a separate field, to remind people.
(2) We could provide another field for templates that manage URLs, but in
most cases you want to document your URLs, i.e. explain what they point to,
don't you? So the rich text fields seem to be the best place to put these.
On Fri, 03 Nov 2006 19:32:28 +0100, Peter Haumer <phaumer@us.ibm.com>
wrote:
> Hello.
> (1) As I mentioned in the email list, you can attach and provide URLs in
> the
> rich text fields using the Add Link button. The reason why there is not
> separate field is that attachments for these types are not the normal
> case,
> but rather the exception until you migrated your content in the EPF
> format.
> For templates an attachment is required as you need to provide the
> attachment for that third party tool the template describes. That's why
> there is a separate field, to remind people.
>
> (2) We could provide another field for templates that manage URLs, but in
> most cases you want to document your URLs, i.e. explain what they point
> to,
> don't you? So the rich text fields seem to be the best place to put
> these.
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: Guidance Attachment [message #575012 is a reply to message #26819] |
Thu, 18 January 2007 21:18 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
I fully agree and that's why you can embed attachments in every rich text
field in the tool. The separate attachment fields were intended to remind
people not to forget attachments. We are currently updating the forms for
example, reusable asset, report and whitepaper to have such a field as well.
--
Thanks and best regards,
Peter Haumer.
____________________________________________________________ __
PETER HAUMER
IBM | Eclipse Process Framework Committer
____________________________________________________________ __
"Jan Masaryk" <jan.masaryk@asseco.sk> wrote in message
news:op.tmcg80g8clxtfu@masarykj.asset-internal...
> Hi Peter,
>
> I definitelly agree with you that we should be very carefull in using
> attachments in model
> but during using EPFC I recognized that it can be very helpful has
> option to attach file to Example.
>
> Just let's imagine that we have Template 'project plan' in MS Project plan
> format.
> We find usefull attach some examples how this template can be use ... and
> that's again MS Project file. :-)
>
> all the best,
> jan
>
>
> Hello.
> (1) As I mentioned in the email list, you can attach and provide URLs in
> the
> rich text fields using the Add Link button. The reason why there is not
> separate field is that attachments for these types are not the normal
> case,
> but rather the exception until you migrated your content in the EPF
> format.
> For templates an attachment is required as you need to provide the
> attachment for that third party tool the template describes. That's why
> there is a separate field, to remind people.
>
> (2) We could provide another field for templates that manage URLs, but in
> most cases you want to document your URLs, i.e. explain what they point
> to,
> don't you? So the rich text fields seem to be the best place to put these.
>
> On Fri, 03 Nov 2006 19:32:28 +0100, Peter Haumer <phaumer@us.ibm.com>
> wrote:
>
>> Hello.
>> (1) As I mentioned in the email list, you can attach and provide URLs in
>> the
>> rich text fields using the Add Link button. The reason why there is not
>> separate field is that attachments for these types are not the normal
>> case,
>> but rather the exception until you migrated your content in the EPF
>> format.
>> For templates an attachment is required as you need to provide the
>> attachment for that third party tool the template describes. That's why
>> there is a separate field, to remind people.
>>
>> (2) We could provide another field for templates that manage URLs, but in
>> most cases you want to document your URLs, i.e. explain what they point
>> to,
>> don't you? So the rich text fields seem to be the best place to put
>> these.
>>
>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
Goto Forum:
Current Time: Tue Apr 23 08:28:56 GMT 2024
Powered by FUDForum. Page generated in 0.04331 seconds |
] 
Search
Help
Register
Login
Home
