Page MenuHomePhabricator

Should Wikimedia have standard policies for managing github mirror repos?
Open, NormalPublic

Description

Apparently we create github mirrors for our gerrit repos (I just learned this today, so forgive my naiveté).

  • Should those mirror repos have issue tracking disabled by default (if such a thing is possible)?
  • Should we have standard practices to ensure that someone is watching the github repo (and issue tracker if it exists), to ensure that we are aware of any external contributions?
  • Should we have standard instructions recommending that potential contributors consider going directly to gerrit/phab?
  • Should we have standardized description snippets? (See T109939, T114616)
  • Should all our repos have some of the files which get special handling on GitHub? (see T136863#3714110, T165540)

Event Timeline

Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJun 2 2016, 6:24 PM
Krenair renamed this task from Should the foundation have standard policies for managing github mirror repos? to Should Wikimedia have standard policies for managing github mirror repos?.Jun 2 2016, 6:27 PM
Krenair added a subscriber: Krenair.
Paladox added a subscriber: Paladox.Jun 2 2016, 6:30 PM

@ksmith I think issue tracker is disabled when Wikimedia create the GitHub mirror but the only not disabled is pull since GitHub dosent allow that to be disabled.

Also I think all the repos are watch by Wikimedia so whoever is in that group on GitHub is watching.

And the description says something like

Github mirror of "reponame" - our actual code is hosted with Gerrit (please see https://www.mediawiki.org/wiki/Developer_access for contributing

But it could be updated to actually link back to the actuall gerrit project and phabricator project.

@Paladox: Ok. Browsing through repos, it does seem like issues are typically disabled. For some reason, they're not in https://github.com/wikimedia/search-highlighter (and search-extra) for example. I don't know why issues are enabled there, nor how many other repos might also have it enabled.

@ksmith I think that may have been because I think developers could choose where they can have bug issues reported but then again I might be wrong.

demon triaged this task as Normal priority.Sep 1 2016, 10:23 PM
demon added a subscriber: demon.
  • Should those mirror repos have issue tracking disabled by default (if such a thing is possible)?

Yes. Unless they're primarily developed on Github itself. We should find which ones don't, and disable them. Same for the wiki feature.

  • Should we have standard practices to ensure that someone is watching the github repo (and issue tracker if it exists), to ensure that we are aware of any external contributions?

Perhaps. Maybe a bot or something? I know I don't ever look at it.

  • Should we have standard instructions recommending that potential contributors consider going directly to gerrit/phab?

Yes. Standard header text points back to Gerrit and mw.org, but these should be standardized. cf: T114616/T109939.

Ideally we could disable pull requests for all repos we don't develop on Github itself, but that's not possible.

Tgr added a subscriber: Tgr.Feb 28 2017, 11:24 PM

How do interested users find their way to Phabricator if issues are disabled?
Maybe we could automatically add a wiki page to all github mirrors with some information about how to get involved with the Wikimedia developer community.

Ideally we could disable pull requests for all repos we don't develop on Github itself, but that's not possible.

See also dear-github #84 which has some examples of PR-autoclosing bots.

Tgr added a comment.Feb 28 2017, 11:25 PM

Also, having CONTRIBUTING.md files could be helpful.

Tgr added a comment.Oct 27 2017, 1:03 AM

A more detailed description of github contribution guidelines: Setting guidelines for repository contributors. So if it's github-specific, it can go into .github/CONTRIBUTING.md, and could contain instructions on how to submit to gerrit instead.

Tgr updated the task description. (Show Details)Oct 31 2017, 9:25 PM
demon added a comment.Feb 5 2018, 11:55 PM

I actually think we shouldn't bother replicating everything....there's a ton of crap.

What I want to do is re-write my old github plugin again (the upstream one I don't like). It'd handle repo creation (as appropriate), along with keeping descriptions in sync.

I'd love to see organization-wide CONTRIBUTORS.md support rather than having to put it on every repo, but good luck :(

Tgr added a comment.Feb 6 2018, 1:43 AM

Github is handy as a fast & nice repo browser (git.wikimedia.org is not a thing anymore, Phabricator is slow and has poor usability). That said, having this huge grab bag of repos (much of them uninteresting to anyone outside WMF deployers) is probably bad for attracting volunteers. Maybe there should be multiple GitHub organizations to group things?

(A similar problem is that the legion of extension repos makes our proper libraries impossible to find by browsing, even though those are probably useful for more people, and extension need their own website anyway. The same problem exists with packagist as well.)

As for CONTRIBUTORS, we could just push it everywhere the same way we did for the code of conduct. (How to do that for new repos is still unsolved but does not seem that hard to solve. And for that matter Github mirror creation is itself unsolved for new repos.)

TerraCodes added a comment.EditedFeb 6 2018, 7:08 AM

Phabricator is slow and has poor usability

Could you please file a task for this? Doesn't seem intended imo.

Tgr added a comment.Feb 6 2018, 6:56 PM

I'm sure no one intends their site/software to be slow and confusing, but those are not easy things to fix, and neither Phacility nor WMF ops can match the resources that go into Github.