Re: [O] org-jira.el... and Org conventions (Bastien, Carsten and all)
Allen S. Rout a...@ufl.edu writes: It should be enough to understand 'How org-mode thinks about ticket systems'. Unfortunately, in order to do this, it is necessary for org-mode to have an opinon. :) Which it doesn't, yet. yoda_mode Org Mode does not think about things, it achieves them. /yoda_mode -- Bastien
Re: [O] org-jira.el... and Org conventions (Bastien, Carsten and all)
Bastien b...@altern.org wrote: Allen S. Rout a...@ufl.edu writes: It should be enough to understand 'How org-mode thinks about ticket systems'. Unfortunately, in order to do this, it is necessary for org-mode to have an opinon. :) Which it doesn't, yet. yoda_mode Org Mode does not think about things, it achieves them. /yoda_mode You obviously meant yoda_mode things about Org Mode think does not, achieves them it. /yoda_mode :-)
Re: [O] org-jira.el... and Org conventions (Bastien, Carsten and all)
Hi Bao, Bao Haojun wrote: I have implemented org-jira.el, bringing org-mode and Jira system together. Wrote a Wiki page for it on emacswiki: http://www.emacswiki.org/emacs/OrgJiraMode Hope somebody find it useful, if he/she is also using Jira and loves org-mode. I had never heard of Jira, but your work definitely looks very promising. IMHO, it should be compared with org-x and its extension to Redmine, among others. But this triggers, for me, another concern which is the very wide variety of ways to define the same thing. Let's just take how we represent who's gonna be assigned a task: - In most examples we see on the Net (or in the Org manual), people use tags with person names (or abbreviations). - In your case, you mirror what's done in Jira (I guess) and you introduce a property Assignee. - In Org issues (http://orgmode.org/worg/org-issues.html), some tasks are given a property Who to indicate who has to work on them. - In tasks used for interacting with TaskJuggler, one uses a Resource-Id property. - Still another approach is used by Juan Reyero in his advertised Org-mode tricks for team management (see [1]), using a combination of TODO todo keywords for his own tasks, and TASK keywords for tasks assigned to members of his team. All of this makes it hard to have one independent Org file, and be able to cooperate with external tools (like Jira, Redmine, TaskJuggler and others) on a on demand approach. You want a Gantt chart? You need to add (or rename) Resource-Id properties. Now, you would like a Web-based Bug Tracking system? Too bad: you need to add (or rename) properties Assignee or ... So, my point is: wouldn't it be better if we proposed standard properties in Org (in the manual), and implemented mappings in the Org integration packages (org-jira, org-taskjuggler, org-redmine and the like)? So, say for example that, from now on, it's more standard in Org to use Assignee (or anything else) for representing who's assigned a task, and have every package map the property Assignee to whatever keyword used in external tools for representing that concept? If we do such, - we _do not impose anything_ (everybody is still free to represent this task the way he wants, be it properties or tags) - we ensure an easy transition to use any external tool for those that used the to be defined standard properties. Best regards, Seb Footnotes: [1] http://juanreyero.com/article/emacs/org-teams.html -- Sebastien Vauban
Re: [O] org-jira.el... and Org conventions (Bastien, Carsten and all)
Hi Sebastien, Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Bao, Bao Haojun wrote: I have implemented org-jira.el, bringing org-mode and Jira system together. Wrote a Wiki page for it on emacswiki: http://www.emacswiki.org/emacs/OrgJiraMode Hope somebody find it useful, if he/she is also using Jira and loves org-mode. I had never heard of Jira, but your work definitely looks very promising. IMHO, it should be compared with org-x and its extension to Redmine, among others. Thanks for the praise! Jira is a commercial issue tracker, but it also seems to be OSS friendly (by allowing OSS community to use the software for free; Apache is using it, see http://wiki.apache.org/general/ApacheJira). Likewise I had not heard of org-x and Redmine, thanks for letting me know. But this triggers, for me, another concern which is the very wide variety of ways to define the same thing. ... So, my point is: wouldn't it be better if we proposed standard properties in Org (in the manual), and implemented mappings in the Org integration packages (org-jira, org-taskjuggler, org-redmine and the like)? So, say for example that, from now on, it's more standard in Org to use Assignee (or anything else) for representing who's assigned a task, and have every package map the property Assignee to whatever keyword used in external tools for representing that concept? I can see your point, that standard thing is good, if it's already here, I will definitely try comply to them. But your worrying people need to transition from one system such as org-jira to another such as org-x, I think they are not very often. Because if it happens, it would mean that the COMPANY/COMMUNITY has decided to switch from Jira to Redmine, can you imagine how often that can be? Besides, even if that really happens, it would also mean the COMPANY/COMMUNITY has got a way to transition from Jira to Redmine, so there would have already been a way to transit from org-jira to org-x: org-jira - Jira - Redmine - org-x (and vice versa). So my point is, if someone try to make transition easy, they should do it on the company level, such as from Jira to Redmine. Org mode feels kind of personal to me, and I feel good enough to be able to sync between company issue tracking system and my org-mode, no need for it to be able to transit to another issue tracking system's org-mode. Best Regards, Bao Haojun
Re: [O] org-jira.el... and Org conventions (Bastien, Carsten and all)
Hi Bao, Bao Haojun wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Bao Haojun wrote: I have implemented org-jira.el, bringing org-mode and Jira system together. Wrote a Wiki page for it on emacswiki: http://www.emacswiki.org/emacs/OrgJiraMode Hope somebody find it useful, if he/she is also using Jira and loves org-mode. I had never heard of Jira, but your work definitely looks very promising. IMHO, it should be compared with org-x and its extension to Redmine, among others. Thanks for the praise! Jira is a commercial issue tracker, but it also seems to be OSS friendly (by allowing OSS community to use the software for free; Apache is using it, see http://wiki.apache.org/general/ApacheJira). Likewise I had not heard of org-x and Redmine, thanks for letting me know. But this triggers, for me, another concern which is the very wide variety of ways to define the same thing. So, my point is: wouldn't it be better if we proposed standard properties in Org (in the manual), and implemented mappings in the Org integration packages (org-jira, org-taskjuggler, org-redmine and the like)? So, say for example that, from now on, it's more standard in Org to use Assignee (or anything else) for representing who's assigned a task, and have every package map the property Assignee to whatever keyword used in external tools for representing that concept? I can see your point, that standard thing is good, if it's already here, I will definitely try comply to them. Thanks for your proposition. I will let others express their own meaning, but, seeing your answer, I wanted to recalibrate what I expressed. But your worrying people need to transition from one system such as org-jira to another such as org-x, I think they are not very often. Because if it happens, it would mean that the COMPANY/COMMUNITY has decided to switch from Jira to Redmine, can you imagine how often that can be? Besides, even if that really happens, it would also mean the COMPANY/COMMUNITY has got a way to transition from Jira to Redmine, so there would have already been a way to transit from org-jira to org-x: org-jira - Jira - Redmine - org-x (and vice versa). So my point is, if someone try to make transition easy, they should do it on the company level, such as from Jira to Redmine. Org mode feels kind of personal to me, and I feel good enough to be able to sync between company issue tracking system and my org-mode, no need for it to be able to transit to another issue tracking system's org-mode. You're right we could understand my proposition as being an easier way to change between bug tracking systems. But not only that. I gave the example of Task Juggler: wouldn't it be nice to be able -- at any point in time -- to generate a dependency graph through Task Juggler, while being able (at the same time, without touching anything) to get the tasks maintained in, let's say, Redmine (which does not offer a Gantt chart functionality IIRC)? So, the question is not really about switching from one system to another, but more about using 2 (or more) systems in parallel... While the former may be a rare occurrence in a project, I guess the latter is more a common wish. Best regards, Seb -- Sebastien Vauban
Re: [O] org-jira.el... and Org conventions (Bastien, Carsten and all)
On 01/03/2012 10:53 AM, Bao Haojun wrote: So my point is, if someone try to make transition easy, they should do it on the company level, such as from Jira to Redmine. Org mode feels kind of personal to me, and I feel good enough to be able to sync between company issue tracking system and my org-mode, no need for it to be able to transit to another issue tracking system's org-mode. It shouldn't be necessary for the org-mode user to learn 'How Haojun thinks about ticket systems' to use jira, and then also learn 'how [someone] thinks about ticket systems' to then use the (imagined?) TRAC integration. It should be enough to understand 'How org-mode thinks about ticket systems'. Unfortunately, in order to do this, it is necessary for org-mode to have an opinon. :) Which it doesn't, yet. - Allen S. Rout
