Re: What a modern collaboration toolkit looks like

[Trey Jackson <bigfaceworm@gmail.com>]

 ESR wrote:
 > This started out as part of a longer essay called "On not kissing the pig".
 > But that essay grew into an epic.  Rather than dump it on the list all 
 > at once, I think it will be useful if I start by giving everybody a
 > clear idea of the potential benefits of changing our practices.

IMO, the development environment Emacs provides is very indicative of the
environment used to develop Emacs.  Namely, communication is email, and VCS
is CVS.  Those things work very well inside Emacs.

ESR is pointing out that many folks have moved on to ... more sophisticated
development methodologies (not saying better), and that, in comparison,
Emacs seems antiquated.

My take on the lessons to take from this thread (never saw ESR's promised
lessons rant):

Goal: Make changes in the way Emacs is developed in order to
1) enable more responsive Emacs development/releases
2) make Emacs development (and by extension Emacs) more attractive to new folks

For example, moving to a new VCS would ensure that the Emacs/VCS integration
works properly.  As ESR (?) found out, Emacs' version control interface
didn't map well into the newer VCSs - thereby prompting the recent rewrite.

What else could be done?  One might work on an IDE *framework* that is
useful for Emacs developers as well as other projects?  Components might
include coupling between:

- development system (code, build, run, debug, code browsing)
- version control
- bug tracking
- communication (email, IRC, web)
- task management (todo.el, planner.el)

gud.el and vc.el are examples of similar work.  Perhaps it's time for ide.el?


To be clear, I'm not advocating moving to new VCS, bug tracking system, IRC,
or *anything* just to be "hip" and "cool."  Every change must provide
benefit.  It seems that the VCS discussion has revealed some benefits found
in the newer VCSs that might be (are?) attractive to RMS & others.


So... one possible conclusion is to work on an IDE framework that can be
used by Emacs developers and potentially extended by others.

For example, concrete steps that could be taken by Emacs development team:

1) move to new VCS
   -> ensures Emacs integration with new VCS works well
2) move to bug tracking system
   -> develop IDE hooks to coordinate bug system with VCS
3) integrate communication system with bug system/VCS
   -> IDE hooks auto-communicate check-ins with email/chat
   -> hooks for analyzing communication and interacting with VC/bug tracking


Someone might then see the above framework and decide to add hooks to
integrate with planner.el to assist in task management... 


Again, I'm not advocating making any specific changes (I'm sure I have no
standing in this group as I am unknown).  Just trying to pull together where
I think this thread can lead.


TJ

ps. I think it's always good to reflect on how one approaches their tasks -
even if no changes occur.  It sounds like that's what is happening with Emacs
development.

-- 
Trey Jackson
bigfaceworm@gmail.com

"...all those moments will be lost in time
 like tears in the rain.
 Time to die."
-- Roy Batty