What if the Issue Queue informed you that the code you're working on is also being touched by someone else? (Yay!)

Senpai's picture

[EDIT: This idea is temporarily code-named D.I.A.S., the Duplicate Issue Alert System]
So, @sdboyer and I were sitting around talking Git pair-o-dimes and possibilities, and he spouts off with the idea that if a repo were to fork core in order to develop a new initiative, and that forked repo has commits to a certain file at a certain line number, shouldn't it be possible to programmatically find all the other instances of core forks that also touch(ed) or changed that same code? This would keep developers from stepping on each other's toes during reintegration of their initiative back into the main core code.

That idea, while cool in it's own right, sprung forth yet another concept. What if developers who are working in an issue queue could be made aware of all the other projects which might also be working on their "stuff"? Could instant collaboration occur without human intervention, i.e., manually pasting links from other issue(s) into an issue comment?

I'm drawing up a couple of wireframe diagrams to illustrate this concept so that we don't loose it, and so that it can be properly programmed, but in the meantime, I'm sticking this idea into ascii and I'll come back and edit it later.


Enabled comments on this

arianek's picture

Enabled comments on this thread, not sure why they were disabled...

I don't know how this would work technically, but it would be great!

Re: I don't know how this would work technically, but

Senpai's picture

Ariane, it would totally, technically, work. With Git, it's possible, probable, and even theoretically awesome. :) What we'd have to do before coding up such an invention is to figure out how it looks to the developers working an issue queue, and how to keep it out of the hands of people who don't care to see it.

You see, if we simply hide this cross-pollination info from everyone who's never committed code, or who's never committed code to a particular project, people like me would never be able to learn that there are, in fact, seven different projects all focused on shoehorning the admin_menu into core. Or whatever. :)

Joel Farris | my 'certified to rock' score

Really cool idea. It might be

linclark.research's picture

Really cool idea.

It might be necessary to use a more nuanced heuristic than making changes to the same "certain file at a certain line number" in order to determine whether two forks are working on related stuff.

For instance, there may be many projects with different focuses that need to make a change to one function. In these cases, the projects would be shown as working on the same stuff even though they were completely unrelated. However, it's hard to say if this really would be a problem. It might be easiest to implement it to see what really happens and then iterate from there.

Yep, it's doable. The

sdboyer's picture

Yep, it's doable. The question is how complex the operation would be...but I think we could do it in O(n) or less, where n = the number of per-issue repos on a given project.