Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [iot-pmc] GitHub Issues for Eclipse projects

Hello John,

thanks for replying to the discussion! I think the most important point is, that this topic gets a little bit of attention.

-----

I also do think that fragmentation is an issue, looking at Apache projects it is sometimes really hard to understand where the project related stuff is located (source control, bug tracking, etc...)

But I also have to agree with Kai, the split is already been made by allowing GitHub hosted projects. And now the split/fragmentation is not only between projects, but also inside a project. Source code "here", issues "there". Which is harder to explain than to explain "this project does it this way, the other in another way".

Also with Eclipse projects, I sometimes find it hard to locate the relevant entry points looking at each projects home page. And Eclipse SCADA is no difference ;-)

Although I guess this far exceeds the "IoT" space, it think one possible solution would be:
1) Create a simple "fact sheet" for each project containing Bug Tracker, Source Control, Downloads
2) Require all project home pages to include a well defined badge/button to link to this fact sheet (like the incubation logo)

I think that the "fact sheet" already is available, although in too much detail, in the project overview screen [1]. I guess it is not much more than simply streamlining the layout so that all information can be put on one screen. Remove all the project descriptive texts and you are good to go. Think of it as a page were people which already know the project can look at to get in deeper (as a transition from user to contributor).

The second point is a simple requirement to let people actually find this page. Right now the project pages are filled with data and I guess most people (users) are not aware these pages exist.

-----

I have to admit, as soon as you allow one other system, everybody else will want a different system as well. Jira, Trac .. you name it. Personally I think this it is not a good idea to allow them all. But if you decided to allow GitHub for source control, then there is should also be the choice to go with the GitHub issue tracker. Otherwise the move to allow GitHub was wrong in the first place.

-----

In the end I think it is brings more benefit for each Eclipse project allowing for a consistent project view than to have a global view an all Eclipse projects. Most people working on Eclipse SCADA will never care about bugs in CDT for example. Sometimes this will raise a barrier between Eclipse projects, because easy referencing is not possible. But then maybe each project should decide what is more worth for them.

If the decision is that the global "non-fragmentation" is if more worth to the Eclipse Foundation, I fully understand this as well. But this would mean that projects should not be hosted on GitHub any longer. Which I personally would find ok.

-----

I am sorry I came up with that much text ;-)

Jens

[1] https://projects.eclipse.org/projects/technology.eclipsescada

On 06/18/2015 03:54 AM, John Arthorne wrote:
Hi all,

I am an Eclipse Committer Rep in the Eclipse Board of Directors, and I was asked to comment on this. I don't speak for the whole board or even all the committer reps, but I will give you my thoughts on this based on discussions help in past Board meetings and from speaking with other committers.

I am completely sympathetic to developers wanting to use GitHub Issues instead of Bugzilla. It is super simple to use, integrates well with the pull request model, and is easily searchable.

One of the problems raised is that of course GitHub Issues is a proprietary tool. Should the company go away, change its terms of use, start charging for the feature, etc, it would be disruptive to the Eclipse community. It may be hard to imagine this happening, but think for example of the disaster of SourceForge in recent years [1]. However, GitHub Issues are not very complex, and are reachable via an API, so it is not hard to imagine doing synchronization of the content to a secure location hosted by the Eclipse Foundation to preserve freedom of action in the future. So, in the end this is a concern but not a show-stopper.

The biggest concern I have is fragmentation. An issue tracker is not just a tool for committers, it is one of the primary interfaces between the committers and the wider community. If we allowed GitHub Issues we would have to allow other proprietary but free issue trackers as well (Jira and Trello for example are also very popular with developers). It is an important part of the Eclipse Foundation by-laws and culture that we be vendor-neutral - where vendor specific options are available they need to be open to all vendors equally. If we have three, four, or more different issue trackers across Eclipse projects, it creates friction for communication with the wider community, and across Eclipse projects. Contributors and users need to learn multiple tools to communicate with us, and moving/linking bugs across projects becomes much more difficult. In the end I would rather have a single issue tracker across all Eclipse projects, even if it is a bit clunky compared to some of the proprietary options out there.

John

[1] http://www.infoworld.com/article/2929732/open-source-software/sourceforge-commits-reputational-suicide.html


> If you, as an Eclipse IoT project, are interested using GitHub issues
> for your project, please reply to this E-Mail. Maybe with a _short_
> explanation why.


_______________________________________________
iot-pmc mailing list
iot-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-pmc


-- 
IBH SYSTEMS GmbH
D-85235 Pfaffenhofen an der Glonn
Läutenring 43
Geschäftsführer / CEO: Dr. Thomas Heitzig

Amtsgericht München
Handelsregister Nummer  HRB 197959
USt ID: DE267945175

Office Munich
D 80992 München
Agnes-Pockels-Bogen 1
T +49 89 18 9 17 49 0

The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or pivileged
material. Any review, retransmission, dissemination or other use of,
or taking of any action in reliance upon, this information by persons
or entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the
material from any computer.

Back to the top