Re: [eclipse.org-project-leadership] Use of GitHub Issues by Eclipse Pro

[Julien Ponge <julien.ponge@xxxxxxxxxxxx>]

Hi,

I’m late into the game, but I thought I would share the experience of Golo, a GitHub-era project that is now incubating at Eclipse [1].

Short version: no wonder we would go back to GitHub issues if offered the chance.

Long version: we appreciate the fact that we can use GitHub for our day-to-day development. For instance the GitHub pull-request with CLA check hook makes things very very smooth. But the “GitHub experience” is more about flexible workflows that a larger contributors base can be familiar with than just a set of tools that the cool kids love.

When we entered incubation last June we painfully/manually migrated our existing issues to Bugzilla. We can live with the tool. It’s not very fancy, it does not support textual dialects like Markdown, it has a complex UI (browsing issues, unfriendly query URLs, etc), but in the end of the day there are worse tools.

We’ve had a few Bugzilla entries resolved as part of that, a few ones being created, but the reality check is that external reporters don’t like it (they need an Eclipse account), and our team very much preferred GitHub issues because it remains minimalistic.

Of course it is very important for the Foundation to have a referential of issues and discussions, so mirroring to Bugzilla or anything else (DB?) is a must. We never know what could happen of GitHub, and although there is an API for issues, it remains kept behind an "API-wall".

Another thing to consider: pull-requests are just a very special type of issue, so when you need to craft a release GitHub gives you a whole set of issues, pull-requests, and the associated discussions.

It’s our practice to always discuss around pull-requests, never much in Bugzilla issues. Pull requests are more than mere code reviews, they are part of the workflow. If you look at our first release issues [2] it gets crystal clear: we did not even bother creating Bugzilla entries for most of the features and fixes. It’s not that we don’t want to adhere to the Eclipse Development Process. No, it’s really a matter of keeping the workflows simple, and our pre-Eclipse habits where GitHub-biased, so a double bookkeeping between PRs and issues has little perceived value.

Hope it helps :-)

Cheers

[1] https://projects.eclipse.org/projects/technology.golo
[2] https://projects.eclipse.org/projects/technology.golo/releases/3.0.0-incubation/bugs

- Julien

> On 10 Nov 2015, at 04:24, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx> wrote:
> 
> All,
> 
> Several years ago the Eclipse Foundation started allowing its projects to host their day-to-day development at GitHub. As part of that, we implemented several processes to ensure that Eclipse projects could maintain their freedom of action should GitHub ever go away, or dramatically alter their terms of service. A number of the projects which host their development at GitHub subsequently asked if they could also start using GitHub Issues, rather than Bugzilla for tracking issues. 
> 
> I am pleased to announce that at last week's Board meeting, the Eclipse Foundation approved the following two resolutions:
> Resolved, that with PMC approval, the Board approves the use of GitHub Issues for Eclipse projects which are hosted at GitHub. The EMO is instructed to backup GitHub Issues data on eclipse.org server infrastructure to ensure the future freedom of action of these projects.
> 
> Resolved, the EMO is instructed to provide instructions to Eclipse projects hosted on GitHub on how to properly utilize GitHub features (e.g. Release Pages) to remain compliant with the Eclipse project branding requirements, Eclipse Development Process, and the Eclipse IP Policy.
> This does not mean that you can start using GitHub Issues for your project right away. It does mean that the EMO has started working on a plan to enable that, and we hope to do so soon. Please follow bug 481771 if you are interested in progress on this.
> 
> Thanks,
> -- 
> Mike Milinkovich
> mike.milinkovich@xxxxxxxxxxx
> +1.613.220.3223 (mobile)
> 
> _______________________________________________
> eclipse.org-project-leadership mailing list
> eclipse.org-project-leadership@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-project-leadership
> 
> IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.