Community
Participate
Working Groups
Mylar's are useful for sharing the structure associated with tasks (e.g. bug reports). For example, if you pair program on a task on one machine, then one of the programmers needs to complete the task on their own machine, it would be nice to send them the context of the task by simply dragging the task or bug report to a person in a buddy list (an XML file). Currently this is cumbersome and requires email and way too many clicks. So Shawn prototyped a Jabber/Smack-based layer very similar to ECF's. But ECF looks more mature, and I wonder if it is better for us to layer any additional collaborative support that we need on top of ECF. Ed: I'm CC'ing you because your interview with Scott was useful, and you showed up in his buddy list I thought that you might have some input on how this should work :) Scott: what we need on the sender's end is to have the buddy list support drag-and-drop, have a drop initiate a file transfer of the XML context, along with the ID of the bug report. On the receiver's end, we need to be able to execute code to add the bug report to the list and write the task context file to the right location in the workspace. How hard would this be to do in ECF?
Some thoughts: Seems like you need the idea of a public task that can be shared between multiple people. A bugzilla/jira entry would be an example of a public task but there might be others. Everybody working on that task should share it, including context (what's interesting) without doing anything special. But it has to be done in an automatic, non-distracting way. If two people are working on the same public task at the same time then they are, by definition, collaborating. It would be the way tasks are actually shared. The collaboration session should be automatic and not require any extra steps on the developer's part. He or she should be able to see who else is working on this bug/task, both right at this moment (presence) or has just signaled interest in it (subscribed to it or added it to their task list or whatever). It shouldn't be limited to two people. The task list should indicate activity in the public task. For example I'd want to know 'somebody is working on it right now', or 'somebody commited a file to cvs under this task'. I could see some kind of aging indicator. Like a green light that gets dimmer over time, and if I hover over it it would say when and what the last activity was. The tasks need some kind of history you can look at. I'd want to be able to put triggers on task events, like some clients let you put them on chat room events. I might want it to play a sound whenever somebody activates the task, or checks in a file under that task, or whatever. Some shared tasks should be gated, so that only one person can work on them at a time. There should be a web interface to query the public/shared tasks so people not working on those tasks (like managers) can check on status. Bugzilla/jira already supports this; is that enough? What about non-bug tasks?
Thanks Ed, that's very useful and lines up with what I had in mind. But I hadn't considered that "triggers" idea, which will be very natural to support since Mylar's contexts are interaction histories, and as such lend themselves very well to describing trigger events (similar pointcuts in AOP speak). Althouh collaborative features currently need to take a back seat to core features and integration, I would like to outline what the simplest support would involve in order to see what overlap there is with what ECF can provide. I think that the baby step is to first support *asynchronous* collaboration: - developer or pair works on a context for a public task (bug report) - wants to transfer that context to another developer by - attaching it to a bugzilla report - or sending it via Jabber/ECF - the other developer can view that context (e.g. in read-only mode) or continue working with it. Fyi supporting context diffs will be easy and I already had a prototype working a while back. The we have the *synchronous* collaboration and awareness, which is really the more interesting one and which Ed has provided a good outline of in comment #2. Scott: do you think that ECF could provide some of this infrastructure? Specifically, for the simple asynchronous case we just need file transfer. For the synchronous case we would need to extend awareness of buddy's states.
(In reply to comment #2) > Thanks Ed, that's very useful and lines up with what I had in mind. But I > hadn't considered that "triggers" idea, which will be very natural to support > since Mylar's contexts are interaction histories, and as such lend themselves > very well to describing trigger events (similar pointcuts in AOP speak). > > Althouh collaborative features currently need to take a back seat to core > features and integration, I would like to outline what the simplest support > would involve in order to see what overlap there is with what ECF can provide. > > I think that the baby step is to first support *asynchronous* collaboration: > - developer or pair works on a context for a public task (bug report) > - wants to transfer that context to another developer by > - attaching it to a bugzilla report > - or sending it via Jabber/ECF > - the other developer can view that context (e.g. in read-only mode) or continue > working with it. Fyi supporting context diffs will be easy and I already had a > prototype working a while back. > > The we have the *synchronous* collaboration and awareness, which is really the > more interesting one and which Ed has provided a good outline of in comment #2. > > Scott: do you think that ECF could provide some of this infrastructure? Yes. We had actually done a (very) little amount of work on modelling, serializing, and distributing a 'task' synchronously among a team. What we did was to describe a task as an EMF model, serialize it using EMF/SDO, and distribute it/publish it to a group of participants (other team members) via ECF's concept of a 'shared object'...which is a replicated component. Shared object replicas can message among one another arbitrarily using the enclosing ECF container. We used this work to build our simple shared graphical shared editor (which gives a GEF-based UI for creating a simple node/link graph model). An ECF shared object was used to a) listen for EMF model changes; b) serialize those changes; c) distribute those changes to group members; d) receive/deserialize and apply changes to local replica of model. We've subsequently worked on this in the guise of a 'datashare' plugin, which is intended to provide a way for applications to replicate and distribute changes dynamically for an arbitrary model...and keep the replicas in synch. The datashare plugin provides extension points for customizing the conflict detection and resolution strategies. We didn't finish developing a model (EMF or not) that was to represent a shared 'task list', although I don't think such a model would be difficult to define/create. It could be very similiar (initially) to the structure of the entities that appear in the Eclipse task list. Mik I think I should try to understand Mylar better, and understand the use of Mylar's 'contexts'. It could be that such contexts could be serialized and shared (as appropriate to the trust relationship between the sharing user and others on team) via ECF and datashare. If this is the right thing to do, I can't imagine it would be very difficult to implement with ECF. The sharing of EMF models via SDO and ECF messaging was quite easy. > Specifically, for the simple asynchronous case we just need file transfer. For > the synchronous case we would need to extend awareness of buddy's states. Yes, one could present shared tasks (hierarchically structured I would imagine) associated with user's as an enhanced presence. For example, it could be added to the ECF collab chat client UI underneath the user's presence entry as a hierarchy of tasks associated (owned) by that user. Another possibility is that the tasks could be presented as associated with an Eclipse 'project' through some modification/customization of the navigator. Or their could be a new UI for creating/adding tasks that would also distribute the changes appropriately via ECF. I think it would be great if we could have some kind of task sharing UI and offer it up as one of the services available via ECF to Eclipse Foundation project teams this fall. I have a feeling that it could be a nice way to help distributed teams do planning and coordinate work.
Thanks Scott, that's very useful info. Shawn (on CC) prototyped the sharing of task lists, but on most projects there already is a shared notion of shared task: the bug report. So to keep things simple for now we are making a distinction between developers' local tasks that are supported directly in the Task List, and the tasks that they collaborate on which are supported via bug report and query integration. Also, the way that developers set up their task list can be very personalized (e.g. different queries, amount of categorization). But for synchronous awareness of context the datashare approach seems perfect. The key thing developers need to be aware if what task their team-mates currently have active. If they're curious about whether they're about to step on each others' toes they might want to know more about the others' current task context. The IMylarContext is a very simple model, and defines what things are interesting to share and which aren't. The model currently serializes to a simple XML form. So I guess I'm saying that to start it could be more simple than sharing a hierarchical structure, but also more interesting since information about the contents of that task will be shared. Over the next few weeks I'm going to take a closer look at ECF and see how we could use it for both the synchronous and asynchronous cases. It would be great if you had a chance too look at Mylar because I think that we could get a lot out of combining some effort here. One particular key area of overlap seems to be this notion of trust. Developers will need to control how much of their context they are willing to export (e.g. just the current task, the task activity history, task with context). Does ECF provide some abstractions for working with trust? I guess there's also Higgins/ETF, but for Mylar I think that we would just need something simple and well integrated with ECF.
I've added Peter Nehrer to watch this bug. He's the lead person for the datashare part of ECF. Peter I hope you don't mind.
Mik, are you going to add this one to sandbox or you too scared to expose this? :-)
Our priorities have been on the Tasks Framework and leading up to 1.0 additional attention needs to go into the Context model, so this is not likely to make the cut for 1.0. Now regarding being scared... there's something to that point. I think that other tools, such as web based issue trackers, have been taking awareness of others' activity a bit too lightly. Knowledge workers like being empowered, not micro monitored. That said, we still need it to be easy to share awareness of our activity in order to avoid having to repeatedly communicate our status via email/IM. When we tackle this we will need to put considerable design effort into ensuring that control of the awareness mechanisms is in the user's hands.
I think if ECF provided a good extensible buddy list UI (going to be in the works soon, I think?), Mylar could add to it a toggle button to show the active task in the presence like Microsoft's MSN Messenger allows you to share what's playing in Windows Media Player. I think the ECF Presence APIs also would allow you to choose whom to share it with. Maybe further interaction (mouse hover?) with the task showed in the buddy list could show the context of the task or other information?
Last time I checked, ECF's buddy list was tightly bound to Jabber/GTalk. You don't even see your buddies when disconnected. No offense, but there is no solid UI in ECF at all. All it provides is bunch of half-baked examples, where each forks its own view per communication type.
Hi All, (In reply to comment #9) > Last time I checked, ECF's buddy list was tightly bound to Jabber/GTalk. No offense, but you clearly haven't checked recently...if at all. This statement is just wrong. ECF's buddy list is not tightly bound to Jabber/GTalk. It's bound to the ECF presence API, which is supported right now by multiple providers, including XMPP, Yahoo, and others under development. > > No offense, but there is no solid UI in ECF at all. All it provides is bunch of > half-baked examples, where each forks its own view per communication type. No offense, but this is also totally wrong...and I would appreciate it if you would stop spreading inaccuracies and obviously biased opinions. ECF is a framework/set of plugins for building messaging applications. We have not emphasized the UI plugins/classes in favor of providing APIs for different kinds of communications (presence/chat/im, data collaboration, dynamic service discovery, remote OSGI services, file transfer, etc.)...partially because of severe resource constraints (i.e. we have no corporate support and are doing this on our own time/on own dime), and partially because the main focus of the ECF project (by charter) is as a *framework*, not an application. Nonetheless, we have created some UI classes (like a buddy list) that can be subclassed and extended for other purposes, and it currently supports multiple im/presence protocols (as it's written to the abstract presence API...not to any given protocol...part of the point of ECF itself). We'e used these classes to create some example applications. Just in case you don't believe me, that class is in the org.eclipse.ecf.ui plugin and called org.eclipse.ecf.ui.views.RosterView for your reference. Like others, we are also not satisfied with the applications as they are, and we intend/desire to do more work on these UI classes to make them even more extensible (e.g. through Eclipse extension points) and complete...and are planning to do so as soon as the current API refactoring effort is complete (anticipated next week). See/comment also on the following ECF wiki page:http://wiki.eclipse.org/index.php/Application_Refactoring I would like to propose that we work together with the Mylar team and others interested to a) figure out what UI requirements are needed to support Mylar's buddy list needs (i.e. original bug posting, #1, #4, #8, etc.) b) work to improve/extend/refactor the RosterView and other classes already in place to meet those needs or simply reimplement (not that big a deal) the desired UI on top of the ECF presence API (org.eclipse.ecf.presence). (e.g. posting #8). So can we do these two things cooperatively rather than wasting time spreading incorrect information, and providing criticism instead of help? I will personally commit to focusing on this after having a chance to finish the API refactoring/clean-up work being done in anticipation of ECF 1.0. I would also appreciate offers of assistance/help in working on the UI changes desired here as unfortunately ECF is *still* all volunteer, with very limited resources (even for me personally as the project lead). That, and I suspect the Mylar team at least has access to a) better/more UI programmers; b) has a better idea of what UI for the buddy list that they actually want. Thanksinadvance, Scott
I second Scott's comments and I'd also be interested in working on this, but not before I complete most of the work left to do with ecf.bulletinboard.
(In reply to comment #10) > > Last time I checked, ECF's buddy list was tightly bound to Jabber/GTalk. > No offense, but you clearly haven't checked recently...if at all. This > statement is just wrong. ECF's buddy list is not tightly bound to > Jabber/GTalk. It's bound to the ECF presence API, which is supported right now > by multiple providers, including XMPP, Yahoo, and others under development. Sorry, my mistake. However that only happens because of the state of existing UI. I wonder if ECF developers even tried to use it on a daily basis? I tried, but found it way far from being ready for the prime time. > > No offense, but there is no solid UI in ECF at all. All it provides is bunch of > > half-baked examples, where each forks its own view per communication type. > No offense, but this is also totally wrong...and I would appreciate it if you > would stop spreading inaccuracies and obviously biased opinions. Too bad you took it personal. The key word is the "solid UI". Are you going to argue that? > ECF is a framework/set of plugins for building messaging applications. We have > not emphasized the UI plugins/classes in favor of providing APIs for different > kinds of communications (presence/chat/im, data collaboration, dynamic service > discovery, remote OSGI services, file transfer, etc.)...partially because of > severe resource constraints (i.e. we have no corporate support and are doing > this on our own time/on own dime), and partially because the main focus of the > ECF project (by charter) is as a *framework*, not an application. I know that all and yet it is not helping nor making ECF a good foundation for building IDE integration layer. You should remember that I've been complaining about UI stuff for very long time and your answer been always like that. So, what I see after installing ECF plugins is the bunch of views: ECF Collaboration, ECF Collab Roster, ECF Dynamic Service Discovery, ECF Roster. All of those has no any actions available and completely obscure from the end user point of view. Should I continue usability evaluation of the *current* UI or you do see my point?
(In reply to comment #10) > Like others, we are also not satisfied with the applications as they are, and > we intend/desire to do more work on these UI classes to make them even more > extensible (e.g. through Eclipse extension points) and complete...and are > planning to do so as soon as the current API refactoring effort is complete > (anticipated next week). See/comment also on the following ECF wiki > page:http://wiki.eclipse.org/index.php/Application_Refactoring It is good to hear that you are starting to see the importance of UI layer. Clearly, you can't build and design an API without really using it in real applications. Mylar actually shows a great evidence of this. You can ask Mik how much repository API had been changed wile adding support for new repositories... > I would like to propose that we work together with the Mylar team and others > interested to > > a) figure out what UI requirements are needed to support Mylar's buddy list > needs (i.e. original bug posting, #1, #4, #8, etc.) > > b) work to improve/extend/refactor the RosterView and other classes already in > place to meet those needs or simply reimplement (not that big a deal) the > desired UI on top of the ECF presence API (org.eclipse.ecf.presence). (e.g. > posting #8). In my opinion there should be two views that would allow 3rd party plugins to contribute actions to. First one should be the Roster/Buddy list, and second one should be the Collaboration view where all the chatting and user interaction would be happening. Buddy list should always show list of buddies (no matter if connected or offline), and should allow add/remove buddies either manually or programmatically (i.e. sync up with remote buddy list like it is now with gtalk). Roster may also allow to group/tag users (i.e. per IM server, or per linked project) and somehow allow other plugins to show additional info (e.g. mylar could show what task user is working on and stuff like that). And of course all the buddy attributes should be available to the plugins, so they could use registered buddies for their own needs (i.e. complete users in Mylar editors and or show if user from CC list is online). Collaboration view should not bring up any popup windows, but may instead use multiple instances (like Console view), nested tabs (I think log viewer plugin does that) or dropdowns (like Console or Team Sync view) to separate different conversations. Personally I think tabs would work best. Then you could add some notification to the Workbench status bar (similar to progress indication for type hierarchy search) that would allow to see new messages without activating Collaboration view and quickly jump into those messages. I could continue, but this is for a start. Hope that helps.
(In reply to comment #12) > (In reply to comment #10) <stuff deleted> > Sorry, my mistake. However that only happens because of the state of existing bunch of >> UI. I wonder if ECF developers even tried to use it on a daily basis? I tried, > but found it way far from being ready for the prime time. I use it all the time (and am using it right now). I can't speak for the other ECF developers. As I think I've made clear, I don't consider the buddy list UI 'feature complete' relative to the commercial applications, but it is usable, and like I said, the UI is a) not the basic purpose of the project b) something we're trying very hard to fix...hopefully with the cooperation of others <stuff deleted> > > would stop spreading inaccuracies and obviously biased opinions. > > Too bad you took it personal. The key word is the "solid UI". Are you going to > argue that? 'solid UI' is subjective, of course. You say 'not solid' after, what, maybe 10 minutes of use and no examination of the code? I say incomplete, usable, and improvable by those willing to participate rather than complain. <stuff deleted> > > I know that all and yet it is not helping nor making ECF a good foundation for > building IDE integration layer. You should remember that I've been complaining > about UI stuff for very long time and your answer been always like that. Key words are 'complaining about UI stuff'. I would prefer that instead of complaining you *did* something about it (perhaps contributed UI work?). I/we would be completely open to contributions from you or anyone else with the ability to do so. Saying 'completely open to contributions' is actually too weak...I would be *thrilled* with contributions from you and others. > > So, what I see after installing ECF plugins is the bunch of views: ECF > Collaboration, ECF Collab Roster, ECF Dynamic Service Discovery, ECF Roster. > All of those has no any actions available and completely obscure from the end > user point of view. Should I continue usability evaluation of the *current* UI > or you do see my point? This isn't correct either Eugene. Each of these view has actions available...e.g. roster view has send IM, etc, add/remove buddies, etc. Also, each of them can/could be extended/improved/patched not by an end user, of course...but rather by a developer like yourself)...ala a framework. Would you rather waste my and your (and everyone's) time arguing about the state of the current UI, or actually improve the situation for yourself and everyone? I will make it very easy for your or anyone interested in seeing more/better UI to checkin code that does exactly that. All you have to do is make a contribution. Please consider joining in and doing so: http://wiki.eclipse.org/index.php/Application_Refactoring If you or others would like to replace the ECF UI classes/plugin completely I say 'please do'. If, on the other hand, you would like to extend/reuse what's there I also say 'please do'. The key words though, are 'please DO'...rather than 'please complain'...especially to a small group that has been working hard for FREE to create something useful. BTW, if you would like to see what I and other contributors have been doing, all you need to do is consult: http://wiki.eclipse.org/index.php/API_Refactoring https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=ECF http://dash.eclipse.org/dash/commits/web-app/active-committers.cgi?project=technology.ecf and/or 'use the source': http://www.eclipse.org/ecf/dev_resources.php Thanks, Scott
(In reply to comment #13) > (In reply to comment #10) <stuff deleted> > > It is good to hear that you are starting to see the importance of UI layer. Thanks...I don't need any more indication of the importance of a UI layer. What I need is more resources to *work* on that layer (other than just myself part time). <stuff deleted> > > In my opinion there should be two views that would allow 3rd party plugins to > contribute actions to. First one should be the Roster/Buddy list, and second > one should be the Collaboration view where all the chatting and user > interaction would be happening. See in org.eclipse.ecf.ui plugin: Buddy List: org.eclipse.ecf.ui.views.RosterView Collaboration View: org.eclipse.ecf.ui.views.ChatRoomManagerView and org.eclipse.ecf.ui.views.ChatRoomView > > Buddy list should always show list of buddies (no matter if connected or > offline), and should allow add/remove buddies either manually or > programmatically (i.e. sync up with remote buddy list like it is now with > gtalk). Roster may also allow to group/tag users (i.e. per IM server, or per > linked project) and somehow allow other plugins to show additional info (e.g. > mylar could show what task user is working on and stuff like that). And of > course all the buddy attributes should be available to the plugins, so they > could use registered buddies for their own needs (i.e. complete users in Mylar > editors and or show if user from CC list is online). > > Collaboration view should not bring up any popup windows, but may instead use > multiple instances (like Console view), nested tabs (I think log viewer plugin > does that) or dropdowns (like Console or Team Sync view) to separate different > conversations. Personally I think tabs would work best. Then you could add some > notification to the Workbench status bar (similar to progress indication for > type hierarchy search) that would allow to see new messages without activating > Collaboration view and quickly jump into those messages. I could continue, but > this is for a start. I've copied these comments over to: http://wiki.eclipse.org/index.php?title=Application_Refactoring Thank you for the ideas
I just wanted to chime in to second Scott's statements about any efforts in this area having a complementary overlap with ECF first being considered as ECF contributions. Any real-time collaboration facilities for Mylar should be built on ECF unless there is overwhelmingly compelling reason not to do so. Yes, some of the UI that ECF provides is more than we need. But in the cases where ECF does not meet our needs I request that Mylar contributors first consider providing patches to ECF to make the bits that we need more usable or reusable. In terms of Mylar priorities, the list of open Mylar bugs has been clearly indicating that users need better integration with task repositories over real time collaboration facilities, which is why this bug has seen little attention from our end. Post Mylar 1.0 I believe that the highest priority point of overlap between Mylar and ECF is getting a buddy list for Mylar that will prevent us from always having to type email addresses (bug 152415), so we could chat further there on how best to share a buddy list.
ECF side bud report is at https://bugs.eclipse.org/bugs/show_bug.cgi?id=195737
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
