As Shazron said and as I pointed out once before, Apache can enable apps such as Probot, which works nicely for more then just moving issues.
I pointed this feature link before. https://probot.github.io/apps/move/ I think Probot will fit our needs better then the other as it provides more features which we can use anytime. 2018/08/23 18:13、Jan Piotrowski <piotrow...@gmail.com>のメール: >> How do we get apps unlocked for organization access? >> Just request access using the GitHub dialog that pops up, or doe we have to >> file INFRA tickets? > > I don't think anyone has tried that before. > > If the question was directed at the > https://github-issue-mover.appspot.com/ I posted, it doesn't need any > access. Just paste the issue URL in the left input, the target repo in > the right one. Result: > https://github.com/apache/cordova-discuss/issues/109 > https://github.com/apache/cordova/issues/2 > > If not, I am happy to have tried the move functionality anyway ;) >> Am Do., 23. Aug. 2018 um 11:10 Uhr schrieb <raphine...@gmail.com>: >> >> How do we get apps unlocked for organization access? >> Just request access using the GitHub dialog that pops up, or doe we have to >> file INFRA tickets? >> >> While I found it very nice to have some dedicated space for higher level >> design discussions, cordova-discuss >> is heavily unmaintained and feedback to any issues was pretty much >> non-existent anyway. >> So I'm fine with whatever happens to it. >> >> Furthermore, with all decisions having to go through the mailing list, I >> suggest simply using that for any design discussions. >> >> Am Do., 23. Aug. 2018 um 10:59 Uhr schrieb Jan Piotrowski < >> piotrow...@gmail.com>: >> >>> Issues can be moved e.g. with https://github-issue-mover.appspot.com/. >>> As the issues were a thing of keeping track of stuff, I think >>> @raphinesse and @brodybits who created most of those issue should take >>> care of moving their issues to the appropriate repo or close them >>> themselves, so they are aware where they ended up. >>> Then issues in cordova-discuss are taken care of. >>> >>> Looking at the actual `proposals` folder in cordova-discuss, this is >>> pretty outdated anyway. Moving those somewhere else doesn't really >>> make sense as we would not delete cordova-discuss but archive it >>> anyway. >>> The open Pull Requests are more recent and relevant. >>> >>> So the open question is if we want to move the "proposal" process with >>> actual files in a `proposals` folder, or modify it so the proposals >>> are put into the issue description itself. This looses the possibility >>> to comment on specific lines, but you can of course always quote >>> things in your comment. Is there a specific reason we have "proposals >>> as files"? >>> >>> >>> >>> >>>> Am Do., 23. Aug. 2018 um 10:20 Uhr schrieb Shazron <shaz...@gmail.com>: >>>> >>>> It's mainly about discoverability, now that we have `cordova` repo >>>> itself (one stop shop for general issues?). `discuss` repo was there >>>> as you mentioned for historical reasons. Now that we have the >>>> `cordova` repo, and we can discuss in the Issues of that repo, another >>>> repo for discussion is redundant IMO. We could move issues from one >>>> repo to another, if need be (not sure how, without some bot like >>>> Probot) >>>> >>>> In any case if we don't want to move that is fine as well, since all >>>> PRs and Issues are reflected in the commits@ mailing list (which is >>>> the most important record-keeping thing for Apache). >>>> >>>> On Thu, Aug 23, 2018 at 3:52 PM Jan Piotrowski <piotrow...@gmail.com> >>> wrote: >>>>> >>>>> Wasn't `cordova-discuss` for a totally different use case? >>>>> >>>>> From how I understood it, Cordova has/had a formal "proposal" process >>>>> that consisted of someone writing a proposal as a PR for higher level >>>>> topics. Then a discussion was triggered via an email to this list, >>>>> which was had in the comments and reviews of the PR. Text was adapted >>>>> and changed, later the proposal was voted on on the list again. If it >>>>> was accepted, the proposal was merged into the repository and progress >>>>> was kept track via changes to the document again. Correct? >>>>> >>>>> If this process should be abolished, fine. >>>>> If not, it should be documented so knowledge about it isn't just >>> anecdotal. >>>>> But moving it over to apache/cordova doesn't make sense. >>>>> >>>>> What organically happened in the issues of cordova-discuss - it kind >>>>> of became a place for issues without a proposal as well - was just >>>>> because it was one of the only Cordova repositories with issues >>>>> enabled (as it used to live in the `cordova` organisation, not >>>>> "apache", on Github) before. >>>>> Now most of the issues there can just be moved to the correct >>>>> component repository. If an "overview" of those is needed, we got the >>>>> GitHub Apache Cordova project board that could probably be used for >>>>> that (keep track of issues across multiple repositories and even >>>>> categorize them). >>>>> >>>>> If there are issues left after that, those could be placed into >>>>> `apache/cordova` as a "high level cordova discussion" area if we >>>>> define it that way. >>>>> >>>>> J >>>>> >>>>> >>>>> Am Do., 23. Aug. 2018 um 08:01 Uhr schrieb Shazron <shaz...@gmail.com >>>> : >>>>>> >>>>>> I think we should stick to one repo -- >>>>>> https://github.com/apache/cordova and archive the discuss repo. >>>>>> We should point to that one repo for all things Cordova w.r.t to dev. >>>>>> On Thu, Aug 23, 2018 at 4:13 AM Chris Brody <chris.br...@gmail.com> >>> wrote: >>>>>>> >>>>>>> While I personally think it would continue to fill an existing gap >>> (track >>>>>>> discussion of some random and otherwise uncategorized Cordova >>> topics) it >>>>>>> has proven to be unpopular. >>>>>>> >>>>>>> Some alternatives I can think of: >>>>>>> * discuss such discussions in https://github.com/apache/cordova >>>>>>> * discuss elsewhere such as cordova-coho or cordova-contribute >>>>>>> * consider using a solution such as Discourse >>>>>>> >>>>>>> I am a bit concerned that discussions by email and in Slack are >>> easy to >>>>>>> forget and not easy to keep track of. >>>>>>> >>>>>>> P.S. As a side point I am not so happy to see most dev discussions >>> on Slack >>>>>>> in private PMC channel. I would be much happier to see such >>> discussions in >>>>>>> a public channel such as "dev". >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>>> For additional commands, e-mail: dev-h...@cordova.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>> For additional commands, e-mail: dev-h...@cordova.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org >
