Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
Auto-correction sorry! Anyways, I also agree with *Shazron's* point of view on this and will also > go with the consensus. On Fri, Aug 24, 2018 at 12:06 PM Bryan Ellis wrote: > Personally, I am also in favor for the issue bankruptcy. > > > I use the LIFO method more when deciding tickets; so looking at JIRA might > become less over time as GH issues grow. > > > I know that there can be relevant tickets, but someone will have to spend > time determining that. > > > >- > >Sort out tickets that are support vs actually issues/feature related >to our tooling, platforms, plugins. >- > >Close out tickets that actually had PRs submitted and merged but not >closed. Seen a few of these >- > >Test if a report is still valid, and I mean really sit down and try to >reproduce. >- > >… > > > Anyways, I also agree with Sharon point of view on this and will also go > with the consensus. > > > > > On Fri, Aug 24, 2018 at 11:29 AM Shazron wrote: > >> I think we have to take a look at whether we actually *will* look at >> GH Issues *and* JIRA. This assumes that us, with limited time and >> resources will actually do it. >> I don't think I will, tbh. The issues are not lost, they are still in >> JIRA for reference when the user wants to take it up again. >> >> This is just declaring issue bankruptcy (a detached break, Cortés >> burning his ships) and requiring the user to re-file if still relevant >> (they get an email notification), and puts the onus on the user, for >> them to have a stake in issues they have so that they can get >> resolved. They must be part of this and care also, we can't babysit >> everything. We are a technically a volunteer operation here, I think >> it's too much for us to maintain two sources of issues. We already >> have a lot on our plate already, IMO. >> >> That being said, I will go with the consensus on this list (if we >> believe we have consensus), and I will bring it up again in a few >> months time to see where we are with JIRA, and I will do my best with >> bridging the two personally. >> On Thu, Aug 23, 2018 at 5:56 PM julio cesar sanchez >> wrote: >> > >> > Realistically, if they created an issue more than 6 months ago and >> nobody >> > looked at it in that time, they wouldn't bother to recreate. So we would >> > lose ~1700 issues. >> > >> > I agree with Raphael, if options are bulk close and ask for migration or >> > keep them open, I vote for keeping them open. >> > >> > If somebody creates a new issue that is already in JIRA and we notice >> it, >> > we can close the JIRA one as duplicate of the github one. (it has >> already >> > happened in at least one issue that I have noticed) >> > >> > El jue., 23 ago. 2018 a las 11:42, Shazron () >> escribió: >> > >> > > Back of the napkin calculation... if we took 5 mins (which is quite >> > > conservative) to migrate one by one, 1,811*5 = 9,055 minutes (or ~19 >> > > days of 8 hours a day full time). That's about a month of work for one >> > > person (not including weekends), but realistically it will be greater >> > > than this of course, definitely a few months. (of course the work can >> > > be run in parallel with more people...) >> > > On Thu, Aug 23, 2018 at 5:34 PM Shazron wrote: >> > > > >> > > > Realistically doing it one by one will take a very long time, nor is >> > > > it necessary -- as a volunteer or if you were paid by your employer. >> > > > Some of these issues might be not relevant anymore. If it was >> > > > relevant, they can re-file in GH. I really don't want this to drag >> out >> > > > for another year. >> > > > >> > > > In my proposal - nothing will be moved, everything will be closed, >> > > > with a note to re-file in GH if relevant. There will be no >> "dangling" >> > > > issues - it's like what you've seen in some open sourced projects, >> > > > "Closing this stale issue. Re-open if still relevant" (but we say >> > > > re-file). >> > > > On Thu, Aug 23, 2018 at 5:19 PM julio cesar sanchez >> > > > wrote: >> > > > > >> > > > > I wouldn't do a bulk close neither, I think we should migrate >> them one >> > > by >> > > > > one to the respective github repo, even using same JIRA id so they >> > > still >> > > > > get linked, and then manually close as duplicate of the new >> github one. >> > > > > >> > > > > It's going to be a lot of work, but we don't need to do it right >> away, >> > > we >> > > > > can start by the latest ones and migrate a few every day until we >> > > finish. >> > > > > Would be good to actually try to reproduce them before migrating, >> so we >> > > > > make sure it's still an issue, but as this will take even more >> time, >> > > > > wouldn't make it mandatory. >> > > > > >> > > > > >> > > > > >> > > > > El jue., 23 ago. 2018 a las 11:06, Shazron () >> > > escribió: >> > > > > >> > > > > > Thanks Jan - I will hold off until we are ready of course. >> > > > > > >> > > > > > Raphael - close as in there can not be any more comments added >> or
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
Personally, I am also in favor for the issue bankruptcy. I use the LIFO method more when deciding tickets; so looking at JIRA might become less over time as GH issues grow. I know that there can be relevant tickets, but someone will have to spend time determining that. - Sort out tickets that are support vs actually issues/feature related to our tooling, platforms, plugins. - Close out tickets that actually had PRs submitted and merged but not closed. Seen a few of these - Test if a report is still valid, and I mean really sit down and try to reproduce. - … Anyways, I also agree with Sharon point of view on this and will also go with the consensus. On Fri, Aug 24, 2018 at 11:29 AM Shazron wrote: > I think we have to take a look at whether we actually *will* look at > GH Issues *and* JIRA. This assumes that us, with limited time and > resources will actually do it. > I don't think I will, tbh. The issues are not lost, they are still in > JIRA for reference when the user wants to take it up again. > > This is just declaring issue bankruptcy (a detached break, Cortés > burning his ships) and requiring the user to re-file if still relevant > (they get an email notification), and puts the onus on the user, for > them to have a stake in issues they have so that they can get > resolved. They must be part of this and care also, we can't babysit > everything. We are a technically a volunteer operation here, I think > it's too much for us to maintain two sources of issues. We already > have a lot on our plate already, IMO. > > That being said, I will go with the consensus on this list (if we > believe we have consensus), and I will bring it up again in a few > months time to see where we are with JIRA, and I will do my best with > bridging the two personally. > On Thu, Aug 23, 2018 at 5:56 PM julio cesar sanchez > wrote: > > > > Realistically, if they created an issue more than 6 months ago and nobody > > looked at it in that time, they wouldn't bother to recreate. So we would > > lose ~1700 issues. > > > > I agree with Raphael, if options are bulk close and ask for migration or > > keep them open, I vote for keeping them open. > > > > If somebody creates a new issue that is already in JIRA and we notice it, > > we can close the JIRA one as duplicate of the github one. (it has already > > happened in at least one issue that I have noticed) > > > > El jue., 23 ago. 2018 a las 11:42, Shazron () > escribió: > > > > > Back of the napkin calculation... if we took 5 mins (which is quite > > > conservative) to migrate one by one, 1,811*5 = 9,055 minutes (or ~19 > > > days of 8 hours a day full time). That's about a month of work for one > > > person (not including weekends), but realistically it will be greater > > > than this of course, definitely a few months. (of course the work can > > > be run in parallel with more people...) > > > On Thu, Aug 23, 2018 at 5:34 PM Shazron wrote: > > > > > > > > Realistically doing it one by one will take a very long time, nor is > > > > it necessary -- as a volunteer or if you were paid by your employer. > > > > Some of these issues might be not relevant anymore. If it was > > > > relevant, they can re-file in GH. I really don't want this to drag > out > > > > for another year. > > > > > > > > In my proposal - nothing will be moved, everything will be closed, > > > > with a note to re-file in GH if relevant. There will be no "dangling" > > > > issues - it's like what you've seen in some open sourced projects, > > > > "Closing this stale issue. Re-open if still relevant" (but we say > > > > re-file). > > > > On Thu, Aug 23, 2018 at 5:19 PM julio cesar sanchez > > > > wrote: > > > > > > > > > > I wouldn't do a bulk close neither, I think we should migrate them > one > > > by > > > > > one to the respective github repo, even using same JIRA id so they > > > still > > > > > get linked, and then manually close as duplicate of the new github > one. > > > > > > > > > > It's going to be a lot of work, but we don't need to do it right > away, > > > we > > > > > can start by the latest ones and migrate a few every day until we > > > finish. > > > > > Would be good to actually try to reproduce them before migrating, > so we > > > > > make sure it's still an issue, but as this will take even more > time, > > > > > wouldn't make it mandatory. > > > > > > > > > > > > > > > > > > > > El jue., 23 ago. 2018 a las 11:06, Shazron () > > > escribió: > > > > > > > > > > > Thanks Jan - I will hold off until we are ready of course. > > > > > > > > > > > > Raphael - close as in there can not be any more comments added or > > > > > > additions to the issue, not deletion. They will still exist and > be > > > > > > searchable. We definitely can add a label when we close them. > > > > > > On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski < > piotrow...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > > > > Just a note to make sure: Please do not
Nightly build #829 for cordova has failed
Nightly build #829 for cordova has failed. Please check failure details on build details page at https://builds.apache.org/job/cordova-nightly/829/ You can also take a look at build console: https://builds.apache.org/job/cordova-nightly/829/consoleFull - Jenkins for Apache Cordova - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
I think we have to take a look at whether we actually *will* look at GH Issues *and* JIRA. This assumes that us, with limited time and resources will actually do it. I don't think I will, tbh. The issues are not lost, they are still in JIRA for reference when the user wants to take it up again. This is just declaring issue bankruptcy (a detached break, Cortés burning his ships) and requiring the user to re-file if still relevant (they get an email notification), and puts the onus on the user, for them to have a stake in issues they have so that they can get resolved. They must be part of this and care also, we can't babysit everything. We are a technically a volunteer operation here, I think it's too much for us to maintain two sources of issues. We already have a lot on our plate already, IMO. That being said, I will go with the consensus on this list (if we believe we have consensus), and I will bring it up again in a few months time to see where we are with JIRA, and I will do my best with bridging the two personally. On Thu, Aug 23, 2018 at 5:56 PM julio cesar sanchez wrote: > > Realistically, if they created an issue more than 6 months ago and nobody > looked at it in that time, they wouldn't bother to recreate. So we would > lose ~1700 issues. > > I agree with Raphael, if options are bulk close and ask for migration or > keep them open, I vote for keeping them open. > > If somebody creates a new issue that is already in JIRA and we notice it, > we can close the JIRA one as duplicate of the github one. (it has already > happened in at least one issue that I have noticed) > > El jue., 23 ago. 2018 a las 11:42, Shazron () escribió: > > > Back of the napkin calculation... if we took 5 mins (which is quite > > conservative) to migrate one by one, 1,811*5 = 9,055 minutes (or ~19 > > days of 8 hours a day full time). That's about a month of work for one > > person (not including weekends), but realistically it will be greater > > than this of course, definitely a few months. (of course the work can > > be run in parallel with more people...) > > On Thu, Aug 23, 2018 at 5:34 PM Shazron wrote: > > > > > > Realistically doing it one by one will take a very long time, nor is > > > it necessary -- as a volunteer or if you were paid by your employer. > > > Some of these issues might be not relevant anymore. If it was > > > relevant, they can re-file in GH. I really don't want this to drag out > > > for another year. > > > > > > In my proposal - nothing will be moved, everything will be closed, > > > with a note to re-file in GH if relevant. There will be no "dangling" > > > issues - it's like what you've seen in some open sourced projects, > > > "Closing this stale issue. Re-open if still relevant" (but we say > > > re-file). > > > On Thu, Aug 23, 2018 at 5:19 PM julio cesar sanchez > > > wrote: > > > > > > > > I wouldn't do a bulk close neither, I think we should migrate them one > > by > > > > one to the respective github repo, even using same JIRA id so they > > still > > > > get linked, and then manually close as duplicate of the new github one. > > > > > > > > It's going to be a lot of work, but we don't need to do it right away, > > we > > > > can start by the latest ones and migrate a few every day until we > > finish. > > > > Would be good to actually try to reproduce them before migrating, so we > > > > make sure it's still an issue, but as this will take even more time, > > > > wouldn't make it mandatory. > > > > > > > > > > > > > > > > El jue., 23 ago. 2018 a las 11:06, Shazron () > > escribió: > > > > > > > > > Thanks Jan - I will hold off until we are ready of course. > > > > > > > > > > Raphael - close as in there can not be any more comments added or > > > > > additions to the issue, not deletion. They will still exist and be > > > > > searchable. We definitely can add a label when we close them. > > > > > On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski > > > > > > > wrote: > > > > > > > > > > > > Just a note to make sure: Please do not proceed with this before > > issue > > > > > > and PR templates are in place, labels are unified etc - meaning: > > > > > > GitHub repos are ready. > > > > > > (Working on this right now) > > > > > > Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron < > > shaz...@gmail.com>: > > > > > > > > > > > > > > I've done this for our JIRA: > > > > > > > - I've changed "Resolved" issues to "Closed" (about 8000+ of > > them) > > > > > > > - I've changed issues with "No Component" to the relevant > > component > > > > > > > > > > > > > > What's left: > > > > > > > - We have 1881 Open, Reopened or In Progress issues > > > > > > > - 474 were created in the last year (52 weeks) > > > > > > > - thus 1,407 were created more than a year ago > > > > > > > - 199 were created in the last 6 months (26 weeks) > > > > > > > > > > > > > > What's next: > > > > > > > 1. I can Bulk Resolve all issues with a comment so the reporters > > will > > > > > > > know where to
Re: [DISCUSS] [Github Issues] Issue and PR template + Merge Conventions / Protected Branch
Here is the PR on GitHub templates, our usage of them and actual drafts for all templates: https://github.com/apache/cordova-contribute/pull/3 Please keep all further discussion on the issue and pull request template in this Pull Request. Thank you. Am Di., 21. Aug. 2018 um 20:21 Uhr schrieb : > > Sounds pretty good to me. A few thoughts: > > - The support question template should refer people to a proper support > site like Stack Overflow. > - Merge convention should be: if multiple commits make the history more > meaningful, do a merge commit, else squash and rebase. > - the templates will probably require different information to be provided, > depending on the repository. cordova-lib is usually platform independent, > for example. > > Shazron schrieb am Mi., 8. Aug. 2018, 06:52: > > > Agree with all 3 points by Jan. > > > > @Chris Brody I think we should make use of Github Milestones to track > > related issues. > > On Wed, Aug 8, 2018 at 6:59 AM Jan Piotrowski > > wrote: > > > > > > Update to my initial email: > > > > > > I just noticed we actually _do_ have an issue template in use in the > > > cordovs-docs repository: > > > > > https://github.com/apache/cordova-docs/blob/master/.github/ISSUE_TEMPLATE.md > > > > > > J > > > > > > 2018-08-07 23:18 GMT+02:00 julio cesar sanchez : > > > > I think us as committers should decide if the commits make sense to > > keep > > > > all of them or squash them into one. But bug fixes should usually be > > only > > > > one commit, and major refactors are not usually sent by non committers > > > > > > > > El El mar, 7 ago 2018 a las 23:02, Chris Brody > > > > escribió: > > > > > > > >> > > I would favor a place where a contributor can mark if s/he would > > > >> > > recommend the committer should *not* use the squash option. > > > >> > > > > >> > That of course could be defined in the contributor guidelines or PR > > > >> > template (although there it might be a bit confusing to new users > > that > > > >> > don't know what this is talking about). Do you know how other > > project > > > >> > handle that? > > > >> > > > >> Haven't seen anything like this before. > > > >> > > > >> > In the end it is always the decision of the committer how > > contributed > > > >> > code makes it into the code base, so having good guidelines for us > > > >> > would probably be the best solution, right? > > > >> > > > >> Yes. General common sense may prove to be the major principle, as I > > > >> think it has in the past. For example: > > > >> * Someone raises a PR with bug fixes and major refactoring in separate > > > >> commits (should not be squashed) > > > >> * Someone else raises a PR with a single fix, but with extra commits > > > >> to fix issues with the first commit (*should* be squashed) > > > >> > > > >> I wonder if we can track these discussions in a better way, somehow. I > > > >> have no time to help with these things right now. I think better > > > >> tracking could help ensure these important tasks do not get forgotten. > > > >> > > > >> - > > > >> 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
Re: What to do with cordova-discuss?
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 のメール: >> 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 : >> >> 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 : 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 >>> 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
Re: [Cordova dev] Deprecate some more Cordova plugins?
I've just found cordova-plugin-media was voted to be "sunset", but we didn't do it (https://issues.apache.org/jira/browse/CB-13095), so might be a good start. I think it's the only one left, and cordova-plugin-dialogs didn't get a definite decision. I wouldn't deprecate more, as biggest struggle cordova users face is the lack of supported/maintained plugins. The ones we deprecated was because of a "native" (pure html/js) alternative that could replace the plugin and wouldn't need maintenance. (Except contacts, it was the only one without alternative). Deprecating without an alternative and hoping users will fork and maintain them is not likely to happen. I think it would be better to try to find more contributors that can work on core plugins and make them committers after a while (easier said than done) El jue., 23 ago. 2018 a las 9:32, Jan Piotrowski () escribió: > Which plugins do fall in these two categories in your opinion? > Am Do., 23. Aug. 2018 um 01:27 Uhr schrieb Chris Brody < > chris.br...@gmail.com>: > > > > From some other discussions I started to wonder if we should consider > > deprecating some more Cordova plugins that fall into either of these > > categories: > > * not critical to core need or functionality > > * hard to support > > > > My idea is that people in the user community can start to expand and > > support the plugins they care most about, on the npm ecosystem. This > should > > free us Cordova committers to spend more time on the Cordova libraries > and > > platforms that need more of our care. > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
Realistically, if they created an issue more than 6 months ago and nobody looked at it in that time, they wouldn't bother to recreate. So we would lose ~1700 issues. I agree with Raphael, if options are bulk close and ask for migration or keep them open, I vote for keeping them open. If somebody creates a new issue that is already in JIRA and we notice it, we can close the JIRA one as duplicate of the github one. (it has already happened in at least one issue that I have noticed) El jue., 23 ago. 2018 a las 11:42, Shazron () escribió: > Back of the napkin calculation... if we took 5 mins (which is quite > conservative) to migrate one by one, 1,811*5 = 9,055 minutes (or ~19 > days of 8 hours a day full time). That's about a month of work for one > person (not including weekends), but realistically it will be greater > than this of course, definitely a few months. (of course the work can > be run in parallel with more people...) > On Thu, Aug 23, 2018 at 5:34 PM Shazron wrote: > > > > Realistically doing it one by one will take a very long time, nor is > > it necessary -- as a volunteer or if you were paid by your employer. > > Some of these issues might be not relevant anymore. If it was > > relevant, they can re-file in GH. I really don't want this to drag out > > for another year. > > > > In my proposal - nothing will be moved, everything will be closed, > > with a note to re-file in GH if relevant. There will be no "dangling" > > issues - it's like what you've seen in some open sourced projects, > > "Closing this stale issue. Re-open if still relevant" (but we say > > re-file). > > On Thu, Aug 23, 2018 at 5:19 PM julio cesar sanchez > > wrote: > > > > > > I wouldn't do a bulk close neither, I think we should migrate them one > by > > > one to the respective github repo, even using same JIRA id so they > still > > > get linked, and then manually close as duplicate of the new github one. > > > > > > It's going to be a lot of work, but we don't need to do it right away, > we > > > can start by the latest ones and migrate a few every day until we > finish. > > > Would be good to actually try to reproduce them before migrating, so we > > > make sure it's still an issue, but as this will take even more time, > > > wouldn't make it mandatory. > > > > > > > > > > > > El jue., 23 ago. 2018 a las 11:06, Shazron () > escribió: > > > > > > > Thanks Jan - I will hold off until we are ready of course. > > > > > > > > Raphael - close as in there can not be any more comments added or > > > > additions to the issue, not deletion. They will still exist and be > > > > searchable. We definitely can add a label when we close them. > > > > On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski > > > > > wrote: > > > > > > > > > > Just a note to make sure: Please do not proceed with this before > issue > > > > > and PR templates are in place, labels are unified etc - meaning: > > > > > GitHub repos are ready. > > > > > (Working on this right now) > > > > > Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron < > shaz...@gmail.com>: > > > > > > > > > > > > I've done this for our JIRA: > > > > > > - I've changed "Resolved" issues to "Closed" (about 8000+ of > them) > > > > > > - I've changed issues with "No Component" to the relevant > component > > > > > > > > > > > > What's left: > > > > > > - We have 1881 Open, Reopened or In Progress issues > > > > > > - 474 were created in the last year (52 weeks) > > > > > > - thus 1,407 were created more than a year ago > > > > > > - 199 were created in the last 6 months (26 weeks) > > > > > > > > > > > > What's next: > > > > > > 1. I can Bulk Resolve all issues with a comment so the reporters > will > > > > > > know where to re-file, with instructions, and point them to > > > > > > issues.cordova.io [FAST] > > > > > > OR > > > > > > 2. I can Bulk Resolve issues by component, and point them to the > right > > > > > > GH repo to file the new issue [SLOW] > > > > > > > > > > > > Since this is a bulk operation, if we still need to keep some > issues > > > > > > open in JIRA, we need to tag with a label so I can skip those. > > > > > > > > > > > > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski < > piotrow...@gmail.com> > > > > wrote: > > > > > > > > > > > > > > > 1. Should we just disable those then? One other way is to > add in > > > > bold > > > > > > > > big letters about the deprecation in the New Issue template > > > > > > > > > > > > > > We should probably "just" define our deprecation and archival > policy > > > > > > > (see other active thread). Depending on that, we can create > another > > > > > > > INFRA issue to get taken care of that. There is no flood of > Github > > > > > > > issues for these repos right now, so no harm done. > > > > > > > > > > > > > > > 2. These links are super useful. Perhaps they should be on > the > > > > > > > > website, what do you all think? Not sure if the scripting > for the > > > > > > > > second link is server side or it could be client
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
I'm against migrating everything. I would just leave them in JIRA as is and resolve them when resolved. Regarding the "dangling" issues: If we re-file issues in GitHub, we would have to make sure that the corresponding issue in JIRA is properly marked as obsolete. In other words, I as a developer want to get a list of issues without duplicates. Therefore there need to be two issue states in JIRA: - "Closed with request to re-file" - "Re-filed (obsolete)" To make that happen, we have to rely on users to reference the original issue when re-filing, which is unreliable. Therefore I think it's easier to leave the remaining JIRA issues as they are and resolve them as they are resolved. Am Do., 23. Aug. 2018 um 11:35 Uhr schrieb Shazron : > Realistically doing it one by one will take a very long time, nor is > it necessary -- as a volunteer or if you were paid by your employer. > Some of these issues might be not relevant anymore. If it was > relevant, they can re-file in GH. I really don't want this to drag out > for another year. > > In my proposal - nothing will be moved, everything will be closed, > with a note to re-file in GH if relevant. There will be no "dangling" > issues - it's like what you've seen in some open sourced projects, > "Closing this stale issue. Re-open if still relevant" (but we say > re-file). > On Thu, Aug 23, 2018 at 5:19 PM julio cesar sanchez > wrote: > > > > I wouldn't do a bulk close neither, I think we should migrate them one by > > one to the respective github repo, even using same JIRA id so they still > > get linked, and then manually close as duplicate of the new github one. > > > > It's going to be a lot of work, but we don't need to do it right away, we > > can start by the latest ones and migrate a few every day until we finish. > > Would be good to actually try to reproduce them before migrating, so we > > make sure it's still an issue, but as this will take even more time, > > wouldn't make it mandatory. > > > > > > > > El jue., 23 ago. 2018 a las 11:06, Shazron () > escribió: > > > > > Thanks Jan - I will hold off until we are ready of course. > > > > > > Raphael - close as in there can not be any more comments added or > > > additions to the issue, not deletion. They will still exist and be > > > searchable. We definitely can add a label when we close them. > > > On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski > > > wrote: > > > > > > > > Just a note to make sure: Please do not proceed with this before > issue > > > > and PR templates are in place, labels are unified etc - meaning: > > > > GitHub repos are ready. > > > > (Working on this right now) > > > > Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron < > shaz...@gmail.com>: > > > > > > > > > > I've done this for our JIRA: > > > > > - I've changed "Resolved" issues to "Closed" (about 8000+ of them) > > > > > - I've changed issues with "No Component" to the relevant component > > > > > > > > > > What's left: > > > > > - We have 1881 Open, Reopened or In Progress issues > > > > > - 474 were created in the last year (52 weeks) > > > > > - thus 1,407 were created more than a year ago > > > > > - 199 were created in the last 6 months (26 weeks) > > > > > > > > > > What's next: > > > > > 1. I can Bulk Resolve all issues with a comment so the reporters > will > > > > > know where to re-file, with instructions, and point them to > > > > > issues.cordova.io [FAST] > > > > > OR > > > > > 2. I can Bulk Resolve issues by component, and point them to the > right > > > > > GH repo to file the new issue [SLOW] > > > > > > > > > > Since this is a bulk operation, if we still need to keep some > issues > > > > > open in JIRA, we need to tag with a label so I can skip those. > > > > > > > > > > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski < > piotrow...@gmail.com> > > > wrote: > > > > > > > > > > > > > 1. Should we just disable those then? One other way is to add > in > > > bold > > > > > > > big letters about the deprecation in the New Issue template > > > > > > > > > > > > We should probably "just" define our deprecation and archival > policy > > > > > > (see other active thread). Depending on that, we can create > another > > > > > > INFRA issue to get taken care of that. There is no flood of > Github > > > > > > issues for these repos right now, so no harm done. > > > > > > > > > > > > > 2. These links are super useful. Perhaps they should be on the > > > > > > > website, what do you all think? Not sure if the scripting for > the > > > > > > > second link is server side or it could be client side as well > (via > > > > > > > JavaScript). Perhaps on the > https://cordova.apache.org/contribute/ > > > > > > > (contribute.cordova.io) page. That massive github link could > also > > > be > > > > > > > auto-generated as well on that page, somehow. Let me know how > I can > > > > > > > help. > > > > > > > > > > > > Yes, I think those could very well be on the Cordova web site as > > > well. > > > > > >
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
Back of the napkin calculation... if we took 5 mins (which is quite conservative) to migrate one by one, 1,811*5 = 9,055 minutes (or ~19 days of 8 hours a day full time). That's about a month of work for one person (not including weekends), but realistically it will be greater than this of course, definitely a few months. (of course the work can be run in parallel with more people...) On Thu, Aug 23, 2018 at 5:34 PM Shazron wrote: > > Realistically doing it one by one will take a very long time, nor is > it necessary -- as a volunteer or if you were paid by your employer. > Some of these issues might be not relevant anymore. If it was > relevant, they can re-file in GH. I really don't want this to drag out > for another year. > > In my proposal - nothing will be moved, everything will be closed, > with a note to re-file in GH if relevant. There will be no "dangling" > issues - it's like what you've seen in some open sourced projects, > "Closing this stale issue. Re-open if still relevant" (but we say > re-file). > On Thu, Aug 23, 2018 at 5:19 PM julio cesar sanchez > wrote: > > > > I wouldn't do a bulk close neither, I think we should migrate them one by > > one to the respective github repo, even using same JIRA id so they still > > get linked, and then manually close as duplicate of the new github one. > > > > It's going to be a lot of work, but we don't need to do it right away, we > > can start by the latest ones and migrate a few every day until we finish. > > Would be good to actually try to reproduce them before migrating, so we > > make sure it's still an issue, but as this will take even more time, > > wouldn't make it mandatory. > > > > > > > > El jue., 23 ago. 2018 a las 11:06, Shazron () escribió: > > > > > Thanks Jan - I will hold off until we are ready of course. > > > > > > Raphael - close as in there can not be any more comments added or > > > additions to the issue, not deletion. They will still exist and be > > > searchable. We definitely can add a label when we close them. > > > On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski > > > wrote: > > > > > > > > Just a note to make sure: Please do not proceed with this before issue > > > > and PR templates are in place, labels are unified etc - meaning: > > > > GitHub repos are ready. > > > > (Working on this right now) > > > > Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron : > > > > > > > > > > I've done this for our JIRA: > > > > > - I've changed "Resolved" issues to "Closed" (about 8000+ of them) > > > > > - I've changed issues with "No Component" to the relevant component > > > > > > > > > > What's left: > > > > > - We have 1881 Open, Reopened or In Progress issues > > > > > - 474 were created in the last year (52 weeks) > > > > > - thus 1,407 were created more than a year ago > > > > > - 199 were created in the last 6 months (26 weeks) > > > > > > > > > > What's next: > > > > > 1. I can Bulk Resolve all issues with a comment so the reporters will > > > > > know where to re-file, with instructions, and point them to > > > > > issues.cordova.io [FAST] > > > > > OR > > > > > 2. I can Bulk Resolve issues by component, and point them to the right > > > > > GH repo to file the new issue [SLOW] > > > > > > > > > > Since this is a bulk operation, if we still need to keep some issues > > > > > open in JIRA, we need to tag with a label so I can skip those. > > > > > > > > > > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski > > > wrote: > > > > > > > > > > > > > 1. Should we just disable those then? One other way is to add in > > > bold > > > > > > > big letters about the deprecation in the New Issue template > > > > > > > > > > > > We should probably "just" define our deprecation and archival policy > > > > > > (see other active thread). Depending on that, we can create another > > > > > > INFRA issue to get taken care of that. There is no flood of Github > > > > > > issues for these repos right now, so no harm done. > > > > > > > > > > > > > 2. These links are super useful. Perhaps they should be on the > > > > > > > website, what do you all think? Not sure if the scripting for the > > > > > > > second link is server side or it could be client side as well (via > > > > > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > > > > > (contribute.cordova.io) page. That massive github link could also > > > be > > > > > > > auto-generated as well on that page, somehow. Let me know how I > > > > > > > can > > > > > > > help. > > > > > > > > > > > > Yes, I think those could very well be on the Cordova web site as > > > well. > > > > > > http://cordova.betamo.de/ is built with PHP, I will put its source > > > up > > > > > > on Github later so someone can rebuild it with JS if needed/wanted. > > > > > > For now it is just a solution for us committers (and especially > > > > > > myself). > > > > > > > > > > > > -J > > > > > > > > > > > > 2018-08-08 5:34 GMT+02:00 Shazron : > > > > > > > Thanks Jan! > > > > > > > >
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
Realistically doing it one by one will take a very long time, nor is it necessary -- as a volunteer or if you were paid by your employer. Some of these issues might be not relevant anymore. If it was relevant, they can re-file in GH. I really don't want this to drag out for another year. In my proposal - nothing will be moved, everything will be closed, with a note to re-file in GH if relevant. There will be no "dangling" issues - it's like what you've seen in some open sourced projects, "Closing this stale issue. Re-open if still relevant" (but we say re-file). On Thu, Aug 23, 2018 at 5:19 PM julio cesar sanchez wrote: > > I wouldn't do a bulk close neither, I think we should migrate them one by > one to the respective github repo, even using same JIRA id so they still > get linked, and then manually close as duplicate of the new github one. > > It's going to be a lot of work, but we don't need to do it right away, we > can start by the latest ones and migrate a few every day until we finish. > Would be good to actually try to reproduce them before migrating, so we > make sure it's still an issue, but as this will take even more time, > wouldn't make it mandatory. > > > > El jue., 23 ago. 2018 a las 11:06, Shazron () escribió: > > > Thanks Jan - I will hold off until we are ready of course. > > > > Raphael - close as in there can not be any more comments added or > > additions to the issue, not deletion. They will still exist and be > > searchable. We definitely can add a label when we close them. > > On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski > > wrote: > > > > > > Just a note to make sure: Please do not proceed with this before issue > > > and PR templates are in place, labels are unified etc - meaning: > > > GitHub repos are ready. > > > (Working on this right now) > > > Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron : > > > > > > > > I've done this for our JIRA: > > > > - I've changed "Resolved" issues to "Closed" (about 8000+ of them) > > > > - I've changed issues with "No Component" to the relevant component > > > > > > > > What's left: > > > > - We have 1881 Open, Reopened or In Progress issues > > > > - 474 were created in the last year (52 weeks) > > > > - thus 1,407 were created more than a year ago > > > > - 199 were created in the last 6 months (26 weeks) > > > > > > > > What's next: > > > > 1. I can Bulk Resolve all issues with a comment so the reporters will > > > > know where to re-file, with instructions, and point them to > > > > issues.cordova.io [FAST] > > > > OR > > > > 2. I can Bulk Resolve issues by component, and point them to the right > > > > GH repo to file the new issue [SLOW] > > > > > > > > Since this is a bulk operation, if we still need to keep some issues > > > > open in JIRA, we need to tag with a label so I can skip those. > > > > > > > > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski > > wrote: > > > > > > > > > > > 1. Should we just disable those then? One other way is to add in > > bold > > > > > > big letters about the deprecation in the New Issue template > > > > > > > > > > We should probably "just" define our deprecation and archival policy > > > > > (see other active thread). Depending on that, we can create another > > > > > INFRA issue to get taken care of that. There is no flood of Github > > > > > issues for these repos right now, so no harm done. > > > > > > > > > > > 2. These links are super useful. Perhaps they should be on the > > > > > > website, what do you all think? Not sure if the scripting for the > > > > > > second link is server side or it could be client side as well (via > > > > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > > > > (contribute.cordova.io) page. That massive github link could also > > be > > > > > > auto-generated as well on that page, somehow. Let me know how I can > > > > > > help. > > > > > > > > > > Yes, I think those could very well be on the Cordova web site as > > well. > > > > > http://cordova.betamo.de/ is built with PHP, I will put its source > > up > > > > > on Github later so someone can rebuild it with JS if needed/wanted. > > > > > For now it is just a solution for us committers (and especially > > > > > myself). > > > > > > > > > > -J > > > > > > > > > > 2018-08-08 5:34 GMT+02:00 Shazron : > > > > > > Thanks Jan! > > > > > > > > > > > > 1. Should we just disable those then? One other way is to add in > > bold > > > > > > big letters about the deprecation in the New Issue template > > > > > > 2. These links are super useful. Perhaps they should be on the > > > > > > website, what do you all think? Not sure if the scripting for the > > > > > > second link is server side or it could be client side as well (via > > > > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > > > > (contribute.cordova.io) page. That massive github link could also > > be > > > > > > auto-generated as well on that page, somehow. Let me know how I can > > > > > >
Re: What to do with cordova-discuss?
Yes, I was talking about that. I only see a big "Authorize Github" button there. Will try it when I find time. Thanks for testing. Am Do., 23. Aug. 2018 um 11:13 Uhr schrieb 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 : > > > > 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 >: > > > > > > > > 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 > > > > 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
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
I wouldn't do a bulk close neither, I think we should migrate them one by one to the respective github repo, even using same JIRA id so they still get linked, and then manually close as duplicate of the new github one. It's going to be a lot of work, but we don't need to do it right away, we can start by the latest ones and migrate a few every day until we finish. Would be good to actually try to reproduce them before migrating, so we make sure it's still an issue, but as this will take even more time, wouldn't make it mandatory. El jue., 23 ago. 2018 a las 11:06, Shazron () escribió: > Thanks Jan - I will hold off until we are ready of course. > > Raphael - close as in there can not be any more comments added or > additions to the issue, not deletion. They will still exist and be > searchable. We definitely can add a label when we close them. > On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski > wrote: > > > > Just a note to make sure: Please do not proceed with this before issue > > and PR templates are in place, labels are unified etc - meaning: > > GitHub repos are ready. > > (Working on this right now) > > Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron : > > > > > > I've done this for our JIRA: > > > - I've changed "Resolved" issues to "Closed" (about 8000+ of them) > > > - I've changed issues with "No Component" to the relevant component > > > > > > What's left: > > > - We have 1881 Open, Reopened or In Progress issues > > > - 474 were created in the last year (52 weeks) > > > - thus 1,407 were created more than a year ago > > > - 199 were created in the last 6 months (26 weeks) > > > > > > What's next: > > > 1. I can Bulk Resolve all issues with a comment so the reporters will > > > know where to re-file, with instructions, and point them to > > > issues.cordova.io [FAST] > > > OR > > > 2. I can Bulk Resolve issues by component, and point them to the right > > > GH repo to file the new issue [SLOW] > > > > > > Since this is a bulk operation, if we still need to keep some issues > > > open in JIRA, we need to tag with a label so I can skip those. > > > > > > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski > wrote: > > > > > > > > > 1. Should we just disable those then? One other way is to add in > bold > > > > > big letters about the deprecation in the New Issue template > > > > > > > > We should probably "just" define our deprecation and archival policy > > > > (see other active thread). Depending on that, we can create another > > > > INFRA issue to get taken care of that. There is no flood of Github > > > > issues for these repos right now, so no harm done. > > > > > > > > > 2. These links are super useful. Perhaps they should be on the > > > > > website, what do you all think? Not sure if the scripting for the > > > > > second link is server side or it could be client side as well (via > > > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > > > (contribute.cordova.io) page. That massive github link could also > be > > > > > auto-generated as well on that page, somehow. Let me know how I can > > > > > help. > > > > > > > > Yes, I think those could very well be on the Cordova web site as > well. > > > > http://cordova.betamo.de/ is built with PHP, I will put its source > up > > > > on Github later so someone can rebuild it with JS if needed/wanted. > > > > For now it is just a solution for us committers (and especially > > > > myself). > > > > > > > > -J > > > > > > > > 2018-08-08 5:34 GMT+02:00 Shazron : > > > > > Thanks Jan! > > > > > > > > > > 1. Should we just disable those then? One other way is to add in > bold > > > > > big letters about the deprecation in the New Issue template > > > > > 2. These links are super useful. Perhaps they should be on the > > > > > website, what do you all think? Not sure if the scripting for the > > > > > second link is server side or it could be client side as well (via > > > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > > > (contribute.cordova.io) page. That massive github link could also > be > > > > > auto-generated as well on that page, somehow. Let me know how I can > > > > > help. > > > > > On Tue, Aug 7, 2018 at 11:01 PM Jan Piotrowski < > piotrow...@gmail.com> wrote: > > > > >> > > > > >> You may have noticed the first issues coming in on some > repositories. > > > > >> > > > > >> 1. In hindsight enabling issues for deprecated platforms, plugins > etc > > > > >> may not have been the smartest decision. We will have to find out > how > > > > >> to handle this - we should probably write down a "deprecation / > > > > >> archivation policy" anyway. > > > > >> > > > > >> 2. Some people are missing the "all tickets in one view" > interface. I > > > > >> quickly built http://cordova.betamo.de/ as a workaround. > > > > >> The second link on there generates a few prepared Github search > links, > > > > >> including one that is valid for _all_ Cordova repositories: > > > > >> >
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
I thought JIRA was locked anyway. So only PMC Members can make changes. If we just leave them as is, I can simply resolve an issue I fix in JIRA and all is obvious. If we ask people to reopen in GitHub, we will have a dangling seemingly unresolved duplicate in JIRA, so JIRA becomes less useful with every moved issue. I'm not completely against bulk closing, I just don't see the clear benefits. Am Do., 23. Aug. 2018 um 11:06 Uhr schrieb Shazron : > Thanks Jan - I will hold off until we are ready of course. > > Raphael - close as in there can not be any more comments added or > additions to the issue, not deletion. They will still exist and be > searchable. We definitely can add a label when we close them. > On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski > wrote: > > > > Just a note to make sure: Please do not proceed with this before issue > > and PR templates are in place, labels are unified etc - meaning: > > GitHub repos are ready. > > (Working on this right now) > > Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron : > > > > > > I've done this for our JIRA: > > > - I've changed "Resolved" issues to "Closed" (about 8000+ of them) > > > - I've changed issues with "No Component" to the relevant component > > > > > > What's left: > > > - We have 1881 Open, Reopened or In Progress issues > > > - 474 were created in the last year (52 weeks) > > > - thus 1,407 were created more than a year ago > > > - 199 were created in the last 6 months (26 weeks) > > > > > > What's next: > > > 1. I can Bulk Resolve all issues with a comment so the reporters will > > > know where to re-file, with instructions, and point them to > > > issues.cordova.io [FAST] > > > OR > > > 2. I can Bulk Resolve issues by component, and point them to the right > > > GH repo to file the new issue [SLOW] > > > > > > Since this is a bulk operation, if we still need to keep some issues > > > open in JIRA, we need to tag with a label so I can skip those. > > > > > > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski > wrote: > > > > > > > > > 1. Should we just disable those then? One other way is to add in > bold > > > > > big letters about the deprecation in the New Issue template > > > > > > > > We should probably "just" define our deprecation and archival policy > > > > (see other active thread). Depending on that, we can create another > > > > INFRA issue to get taken care of that. There is no flood of Github > > > > issues for these repos right now, so no harm done. > > > > > > > > > 2. These links are super useful. Perhaps they should be on the > > > > > website, what do you all think? Not sure if the scripting for the > > > > > second link is server side or it could be client side as well (via > > > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > > > (contribute.cordova.io) page. That massive github link could also > be > > > > > auto-generated as well on that page, somehow. Let me know how I can > > > > > help. > > > > > > > > Yes, I think those could very well be on the Cordova web site as > well. > > > > http://cordova.betamo.de/ is built with PHP, I will put its source > up > > > > on Github later so someone can rebuild it with JS if needed/wanted. > > > > For now it is just a solution for us committers (and especially > > > > myself). > > > > > > > > -J > > > > > > > > 2018-08-08 5:34 GMT+02:00 Shazron : > > > > > Thanks Jan! > > > > > > > > > > 1. Should we just disable those then? One other way is to add in > bold > > > > > big letters about the deprecation in the New Issue template > > > > > 2. These links are super useful. Perhaps they should be on the > > > > > website, what do you all think? Not sure if the scripting for the > > > > > second link is server side or it could be client side as well (via > > > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > > > (contribute.cordova.io) page. That massive github link could also > be > > > > > auto-generated as well on that page, somehow. Let me know how I can > > > > > help. > > > > > On Tue, Aug 7, 2018 at 11:01 PM Jan Piotrowski < > piotrow...@gmail.com> wrote: > > > > >> > > > > >> You may have noticed the first issues coming in on some > repositories. > > > > >> > > > > >> 1. In hindsight enabling issues for deprecated platforms, plugins > etc > > > > >> may not have been the smartest decision. We will have to find out > how > > > > >> to handle this - we should probably write down a "deprecation / > > > > >> archivation policy" anyway. > > > > >> > > > > >> 2. Some people are missing the "all tickets in one view" > interface. I > > > > >> quickly built http://cordova.betamo.de/ as a workaround. > > > > >> The second link on there generates a few prepared Github search > links, > > > > >> including one that is valid for _all_ Cordova repositories: > > > > >> >
Re: [GitHub] janpio opened a new issue #2: TEst
Seems apache/cordova is misconfiged, I created an INFRA issue to change the notification email from dev@ to commits@: https://issues.apache.org/jira/browse/INFRA-16945 Am Do., 23. Aug. 2018 um 11:11 Uhr schrieb GitBox : > > janpio opened a new issue #2: TEst > URL: https://github.com/apache/cordova/issues/2 > > >_From @janpio on August 23, 2018 9:11_ > >test > >_Copied from original issue: apache/cordova-discuss#109_ > > > This is an automated message from the Apache Git Service. > To respond to the message, please log on GitHub and use the > URL above to go to the specific comment. > > For queries about this service, please contact Infrastructure at: > us...@infra.apache.org > > > With regards, > Apache Git Services > > - > 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
Re: What to do with cordova-discuss?
> 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 : > > 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 : > > > > > > 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 > > 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 > >: > > > > > > > > > > I think we should stick to one repo -- > > > > > https://github.com/apache/cordova
[GitHub] janpio closed issue #2: TEst
janpio closed issue #2: TEst URL: https://github.com/apache/cordova/issues/2 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] janpio commented on issue #2: TEst
janpio commented on issue #2: TEst URL: https://github.com/apache/cordova/issues/2#issuecomment-415347724 Manually closing this now. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] janpio opened a new issue #2: TEst
janpio opened a new issue #2: TEst URL: https://github.com/apache/cordova/issues/2 _From @janpio on August 23, 2018 9:11_ test _Copied from original issue: apache/cordova-discuss#109_ This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: What to do with cordova-discuss?
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 : > > > > 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 > 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 >: > > > > > > > > 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 > 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. > > > > >
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
Thanks Jan - I will hold off until we are ready of course. Raphael - close as in there can not be any more comments added or additions to the issue, not deletion. They will still exist and be searchable. We definitely can add a label when we close them. On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski wrote: > > Just a note to make sure: Please do not proceed with this before issue > and PR templates are in place, labels are unified etc - meaning: > GitHub repos are ready. > (Working on this right now) > Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron : > > > > I've done this for our JIRA: > > - I've changed "Resolved" issues to "Closed" (about 8000+ of them) > > - I've changed issues with "No Component" to the relevant component > > > > What's left: > > - We have 1881 Open, Reopened or In Progress issues > > - 474 were created in the last year (52 weeks) > > - thus 1,407 were created more than a year ago > > - 199 were created in the last 6 months (26 weeks) > > > > What's next: > > 1. I can Bulk Resolve all issues with a comment so the reporters will > > know where to re-file, with instructions, and point them to > > issues.cordova.io [FAST] > > OR > > 2. I can Bulk Resolve issues by component, and point them to the right > > GH repo to file the new issue [SLOW] > > > > Since this is a bulk operation, if we still need to keep some issues > > open in JIRA, we need to tag with a label so I can skip those. > > > > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski wrote: > > > > > > > 1. Should we just disable those then? One other way is to add in bold > > > > big letters about the deprecation in the New Issue template > > > > > > We should probably "just" define our deprecation and archival policy > > > (see other active thread). Depending on that, we can create another > > > INFRA issue to get taken care of that. There is no flood of Github > > > issues for these repos right now, so no harm done. > > > > > > > 2. These links are super useful. Perhaps they should be on the > > > > website, what do you all think? Not sure if the scripting for the > > > > second link is server side or it could be client side as well (via > > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > > (contribute.cordova.io) page. That massive github link could also be > > > > auto-generated as well on that page, somehow. Let me know how I can > > > > help. > > > > > > Yes, I think those could very well be on the Cordova web site as well. > > > http://cordova.betamo.de/ is built with PHP, I will put its source up > > > on Github later so someone can rebuild it with JS if needed/wanted. > > > For now it is just a solution for us committers (and especially > > > myself). > > > > > > -J > > > > > > 2018-08-08 5:34 GMT+02:00 Shazron : > > > > Thanks Jan! > > > > > > > > 1. Should we just disable those then? One other way is to add in bold > > > > big letters about the deprecation in the New Issue template > > > > 2. These links are super useful. Perhaps they should be on the > > > > website, what do you all think? Not sure if the scripting for the > > > > second link is server side or it could be client side as well (via > > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > > (contribute.cordova.io) page. That massive github link could also be > > > > auto-generated as well on that page, somehow. Let me know how I can > > > > help. > > > > On Tue, Aug 7, 2018 at 11:01 PM Jan Piotrowski > > > > wrote: > > > >> > > > >> You may have noticed the first issues coming in on some repositories. > > > >> > > > >> 1. In hindsight enabling issues for deprecated platforms, plugins etc > > > >> may not have been the smartest decision. We will have to find out how > > > >> to handle this - we should probably write down a "deprecation / > > > >> archivation policy" anyway. > > > >> > > > >> 2. Some people are missing the "all tickets in one view" interface. I > > > >> quickly built http://cordova.betamo.de/ as a workaround. > > > >> The second link on there generates a few prepared Github search links, > > > >> including one that is valid for _all_ Cordova repositories: > > > >>
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
Thanks for doing this! I'm not sure about the bulk closing. Last time I checked, at least for our tooling even very old issues were often still valid and provided some valuable insight for me. I'd leave them. If we want to close them, They should definitely get some label that makes them easily distinguishable from actually resolved issues. Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron : > I've done this for our JIRA: > - I've changed "Resolved" issues to "Closed" (about 8000+ of them) > - I've changed issues with "No Component" to the relevant component > > What's left: > - We have 1881 Open, Reopened or In Progress issues > - 474 were created in the last year (52 weeks) > - thus 1,407 were created more than a year ago > - 199 were created in the last 6 months (26 weeks) > > What's next: > 1. I can Bulk Resolve all issues with a comment so the reporters will > know where to re-file, with instructions, and point them to > issues.cordova.io [FAST] > OR > 2. I can Bulk Resolve issues by component, and point them to the right > GH repo to file the new issue [SLOW] > > Since this is a bulk operation, if we still need to keep some issues > open in JIRA, we need to tag with a label so I can skip those. > > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski > wrote: > > > > > 1. Should we just disable those then? One other way is to add in bold > > > big letters about the deprecation in the New Issue template > > > > We should probably "just" define our deprecation and archival policy > > (see other active thread). Depending on that, we can create another > > INFRA issue to get taken care of that. There is no flood of Github > > issues for these repos right now, so no harm done. > > > > > 2. These links are super useful. Perhaps they should be on the > > > website, what do you all think? Not sure if the scripting for the > > > second link is server side or it could be client side as well (via > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > (contribute.cordova.io) page. That massive github link could also be > > > auto-generated as well on that page, somehow. Let me know how I can > > > help. > > > > Yes, I think those could very well be on the Cordova web site as well. > > http://cordova.betamo.de/ is built with PHP, I will put its source up > > on Github later so someone can rebuild it with JS if needed/wanted. > > For now it is just a solution for us committers (and especially > > myself). > > > > -J > > > > 2018-08-08 5:34 GMT+02:00 Shazron : > > > Thanks Jan! > > > > > > 1. Should we just disable those then? One other way is to add in bold > > > big letters about the deprecation in the New Issue template > > > 2. These links are super useful. Perhaps they should be on the > > > website, what do you all think? Not sure if the scripting for the > > > second link is server side or it could be client side as well (via > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > (contribute.cordova.io) page. That massive github link could also be > > > auto-generated as well on that page, somehow. Let me know how I can > > > help. > > > On Tue, Aug 7, 2018 at 11:01 PM Jan Piotrowski > wrote: > > >> > > >> You may have noticed the first issues coming in on some repositories. > > >> > > >> 1. In hindsight enabling issues for deprecated platforms, plugins etc > > >> may not have been the smartest decision. We will have to find out how > > >> to handle this - we should probably write down a "deprecation / > > >> archivation policy" anyway. > > >> > > >> 2. Some people are missing the "all tickets in one view" interface. I > > >> quickly built http://cordova.betamo.de/ as a workaround. > > >> The second link on there generates a few prepared Github search links, > > >> including one that is valid for _all_ Cordova repositories: > > >> >
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
Just a note to make sure: Please do not proceed with this before issue and PR templates are in place, labels are unified etc - meaning: GitHub repos are ready. (Working on this right now) Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron : > > I've done this for our JIRA: > - I've changed "Resolved" issues to "Closed" (about 8000+ of them) > - I've changed issues with "No Component" to the relevant component > > What's left: > - We have 1881 Open, Reopened or In Progress issues > - 474 were created in the last year (52 weeks) > - thus 1,407 were created more than a year ago > - 199 were created in the last 6 months (26 weeks) > > What's next: > 1. I can Bulk Resolve all issues with a comment so the reporters will > know where to re-file, with instructions, and point them to > issues.cordova.io [FAST] > OR > 2. I can Bulk Resolve issues by component, and point them to the right > GH repo to file the new issue [SLOW] > > Since this is a bulk operation, if we still need to keep some issues > open in JIRA, we need to tag with a label so I can skip those. > > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski wrote: > > > > > 1. Should we just disable those then? One other way is to add in bold > > > big letters about the deprecation in the New Issue template > > > > We should probably "just" define our deprecation and archival policy > > (see other active thread). Depending on that, we can create another > > INFRA issue to get taken care of that. There is no flood of Github > > issues for these repos right now, so no harm done. > > > > > 2. These links are super useful. Perhaps they should be on the > > > website, what do you all think? Not sure if the scripting for the > > > second link is server side or it could be client side as well (via > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > (contribute.cordova.io) page. That massive github link could also be > > > auto-generated as well on that page, somehow. Let me know how I can > > > help. > > > > Yes, I think those could very well be on the Cordova web site as well. > > http://cordova.betamo.de/ is built with PHP, I will put its source up > > on Github later so someone can rebuild it with JS if needed/wanted. > > For now it is just a solution for us committers (and especially > > myself). > > > > -J > > > > 2018-08-08 5:34 GMT+02:00 Shazron : > > > Thanks Jan! > > > > > > 1. Should we just disable those then? One other way is to add in bold > > > big letters about the deprecation in the New Issue template > > > 2. These links are super useful. Perhaps they should be on the > > > website, what do you all think? Not sure if the scripting for the > > > second link is server side or it could be client side as well (via > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > > (contribute.cordova.io) page. That massive github link could also be > > > auto-generated as well on that page, somehow. Let me know how I can > > > help. > > > On Tue, Aug 7, 2018 at 11:01 PM Jan Piotrowski > > > wrote: > > >> > > >> You may have noticed the first issues coming in on some repositories. > > >> > > >> 1. In hindsight enabling issues for deprecated platforms, plugins etc > > >> may not have been the smartest decision. We will have to find out how > > >> to handle this - we should probably write down a "deprecation / > > >> archivation policy" anyway. > > >> > > >> 2. Some people are missing the "all tickets in one view" interface. I > > >> quickly built http://cordova.betamo.de/ as a workaround. > > >> The second link on there generates a few prepared Github search links, > > >> including one that is valid for _all_ Cordova repositories: > > >>
Re: What to do with cordova-discuss?
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 : > > 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 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 : > > > > > > 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 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:
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
I've done this for our JIRA: - I've changed "Resolved" issues to "Closed" (about 8000+ of them) - I've changed issues with "No Component" to the relevant component What's left: - We have 1881 Open, Reopened or In Progress issues - 474 were created in the last year (52 weeks) - thus 1,407 were created more than a year ago - 199 were created in the last 6 months (26 weeks) What's next: 1. I can Bulk Resolve all issues with a comment so the reporters will know where to re-file, with instructions, and point them to issues.cordova.io [FAST] OR 2. I can Bulk Resolve issues by component, and point them to the right GH repo to file the new issue [SLOW] Since this is a bulk operation, if we still need to keep some issues open in JIRA, we need to tag with a label so I can skip those. On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski wrote: > > > 1. Should we just disable those then? One other way is to add in bold > > big letters about the deprecation in the New Issue template > > We should probably "just" define our deprecation and archival policy > (see other active thread). Depending on that, we can create another > INFRA issue to get taken care of that. There is no flood of Github > issues for these repos right now, so no harm done. > > > 2. These links are super useful. Perhaps they should be on the > > website, what do you all think? Not sure if the scripting for the > > second link is server side or it could be client side as well (via > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > (contribute.cordova.io) page. That massive github link could also be > > auto-generated as well on that page, somehow. Let me know how I can > > help. > > Yes, I think those could very well be on the Cordova web site as well. > http://cordova.betamo.de/ is built with PHP, I will put its source up > on Github later so someone can rebuild it with JS if needed/wanted. > For now it is just a solution for us committers (and especially > myself). > > -J > > 2018-08-08 5:34 GMT+02:00 Shazron : > > Thanks Jan! > > > > 1. Should we just disable those then? One other way is to add in bold > > big letters about the deprecation in the New Issue template > > 2. These links are super useful. Perhaps they should be on the > > website, what do you all think? Not sure if the scripting for the > > second link is server side or it could be client side as well (via > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/ > > (contribute.cordova.io) page. That massive github link could also be > > auto-generated as well on that page, somehow. Let me know how I can > > help. > > On Tue, Aug 7, 2018 at 11:01 PM Jan Piotrowski wrote: > >> > >> You may have noticed the first issues coming in on some repositories. > >> > >> 1. In hindsight enabling issues for deprecated platforms, plugins etc > >> may not have been the smartest decision. We will have to find out how > >> to handle this - we should probably write down a "deprecation / > >> archivation policy" anyway. > >> > >> 2. Some people are missing the "all tickets in one view" interface. I > >> quickly built http://cordova.betamo.de/ as a workaround. > >> The second link on there generates a few prepared Github search links, > >> including one that is valid for _all_ Cordova repositories: > >>
Re: What to do with cordova-discuss?
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 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 : > > > > 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 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
Re: [DISCUSS] [Github Issues] Issue and Pull Request labels
I wanted to use GitHub's GraphQL to gather some insights about cordova repos. I could not access some organization level information that I could see over the web, without requesting organization (apache) wide privileges for GraphQL. So it's not always that easy. Shazron schrieb am Do., 23. Aug. 2018, 07:56: > I would assume since we (committers) can create a New Label in Github, > we would have the permission to do so via API... > On Wed, Aug 22, 2018 at 2:28 AM wrote: > > > > Labels that I would like to have: > > > > - something to show that you are open to suggestions or want to work out > > how something is supposed to work. Could be "discussion" > > - A "Work in Progress" label > > > > I would have tried to just write a script that creates the labels via GH > > API. But do we have the necessary permissions to do so? > > > > Jan Piotrowski schrieb am Do., 9. Aug. 2018, > 23:07: > > > > > Now that we have Github issues enabled for all our repositories, > > > another new thing we have to talk about are Github Issue and Pull > > > Request labels. > > > > > > > > > If you are not aware of Github labels, here is a nice introduction: > > > https://help.github.com/articles/about-labels/ > > > > > > This also contains a list of the default labels all our repositories > > > got when issues were enabled: > > > > > > > bug, duplicate, good first issue, help wanted, invalid, question, > wontfix > > > > > > https://help.github.com/articles/about-labels/#using-default-labels > > > > > > Issues also have a color, which - when chosen well and used uniform > > > across repositories - make it easier to scan the issue list. > > > > > > > > > As we come from JIRA, it's important to understand the differences. > > > A JIRA ticket has many different fields: Type, Status, Priority, > > > Resolution, Affects Version/s, Fix Version/s, Component/s, Labels, > > > Security Level, Environment, Estimate, Flag, External issue URL, > > > External issue ID, Epic Link, Sprint, Docs Text > > > On Github none of those exist. Most of this information has to be > > > supplied via the description of the issue (and can be requested via > > > the issue or PR template, see previous email), but it can also make > > > sense to map some of those via Github labels. > > > > > > > > > With the first few issues that came in on our repositories, I already > > > created the following two new labels: > > > > > > - `support` - Used for support questions that don't report a bug and > > > don't request a new feature but e.g. want to understand how something > > > works, need help debugging their individual problem etc. (This will > > > probably be the majority of the issue we are getting.) > > > - `platform: android` (ios, browser, windows, osx) - For plugin > > > repositories it makes sense to categorize e.g. a bug report or feature > > > request for its platform > > > > > > > > > Other projects have very structured labels: > > > https://github.com/fastlane/fastlane/labels > > > https://github.com/ionic-team/ionic-cli/labels > > > > > > Or pretty extensive lists of stuff: > > > https://github.com/Microsoft/TypeScript/labels > > > https://github.com/Microsoft/vscode/labels > > > > > > What do we actually need for the beginning? > > > Any other input? > > > > > > > > > Does anyone have an idea how we can "manage" our labels across our ~70 > > > repositories? Are there any scripts out there that can automate the > > > creation/deletion of them via the Github API? > > > > > > > > > Best, > > > Jan > > > > > > - > > > 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 > >
Re: What to do with cordova-discuss?
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 : > > 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 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
Re: [Cordova dev] Struggling with discussions
> track some high-level topics of items that need to be addressed. What would those be? > I think this item is an excellent example of itself. Not really, besides the hazy definition of the actual problem, this is _exactly_ the right place to discuss matters that concern the development of Cordova. You could of course just have responded to the mailing list thread "Better discussion forum?" from three weeks ago that you already started for the same or a similar problem. J Am Do., 23. Aug. 2018 um 02:18 Uhr schrieb Chris Brody : > > I am raising this topic with some hope that we may find a good solution in > the near future. > > As I said numerous times I still do not see a good way to track some > high-level topics of items that need to be addressed. I think this item is > an excellent example of itself. > > I will admit that I have sometimes made off-topic side notes in issues and > email topics. People have called me out in public, which is good due to the > increased chance that such notes will be tracked and not forgotten over > time. I have already asked on a private thread: please do not call me out > privately unless you want to take a bigger risk of such topics becoming > forgotten. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [Cordova dev] Deprecate some more Cordova plugins?
Which plugins do fall in these two categories in your opinion? Am Do., 23. Aug. 2018 um 01:27 Uhr schrieb Chris Brody : > > From some other discussions I started to wonder if we should consider > deprecating some more Cordova plugins that fall into either of these > categories: > * not critical to core need or functionality > * hard to support > > My idea is that people in the user community can start to expand and > support the plugins they care most about, on the npm ecosystem. This should > free us Cordova committers to spend more time on the Cordova libraries and > platforms that need more of our care. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Can we please keep Cordova dev chat on a public channel?
+1 for a public Slack channels that includes development discussion and other non-private contributor matters. Am Do., 23. Aug. 2018 um 01:14 Uhr schrieb Chris Brody : > > I noticed that a lot of important dev chat discussions on private Slack PMC > channel does not really need to be kept private. I am not so happy that > some discussions leading to important decisions are kept on a private > channel. Can we make a public dev channel instead? - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Dealing with deprecated repos
Again you split the discussion in 2 places by repeating here what you already commented on the PR. Please stop doing so and complaining how complicated and scattered everything is in other threads. This is part of the reason. I responded to your PR comment. Am Do., 23. Aug. 2018 um 00:59 Uhr schrieb Chris Brody : > > As I said in the PR I really do not see what this has to do with a project > or repo called "contribute". > > On Wed, Aug 22, 2018 at 6:02 PM Jan Piotrowski wrote: > > > And Part #2: > > Contributor documentation on the process "Deprecation and Archiving" > > of repositories: > > https://github.com/apache/cordova-contribute/pull/2 > > > > J > > Am Mi., 22. Aug. 2018 um 21:07 Uhr schrieb Jan Piotrowski > > : > > > > > > Part #1: > > > A public deprecation policy on the Cordova website: > > > https://github.com/apache/cordova-docs/pull/878 > > > Please keep discussion on the PR and text in the GitHub Pull Request. > > > > > > Part #2 will be the contributor documentation that will include the > > > steps and notice template required to deprecate a repository - and > > > will follow later (and build on the actual policy of course). > > > Am Mi., 8. Aug. 2018 um 13:07 Uhr schrieb Jan Piotrowski < > > piotrow...@gmail.com>: > > > > > > > > +1 > > > > > > > > cordova.apache.org/contribute/deprecation_policy.html maybe? > > > > Should include summary of what was discussed here, and best also the > > deprecation notice template in markdown for copy paste. > > > > > > > > -J > > > > > > > > 2018-08-08 12:55 GMT+02:00 Shazron : > > > >> > > > >> Formal as in this is our policy. From what Julio Cesar Sanchez said > > earlier: > > > >> "This is the deprecation policy from cordova-plugin-contacts > > > >> > > > >> Deprecation Notice > > > >> This plugin is being deprecated. No more work will be done on this > > plugin > > > >> by the Cordova development community. You can continue to use this > > plugin > > > >> and it should work as-is in the future but any more arising issues > > will not > > > >> be fixed by the Cordova community. > > > >> > > > >> All the deprecated repos have a similar deprecation notice." > > > >> > > > >> As to where, we just make a new page, say deprecationpolicy.html or > > > >> something, and link it from the Contribute page (as a suggestion). If > > > >> we run into this again, we point to the policy. > > > >> On Wed, Aug 8, 2018 at 6:33 PM Chris Brody > > wrote: > > > >> > > > > >> > On Wed, Aug 8, 2018 at 6:15 AM Shazron wrote: > > > >> > > > > > >> > > Let's make it formal with what we had in the repo > > > >> > > > > >> > Does this mean make the archiving process formal or make something > > else formal? > > > >> > > > > >> > What kind of repo? > > > >> > > > > >> > > or section in the docs somewhere. > > > >> > > > > >> > The question is always where? > > > >> > > > > >> > On Wed, Aug 8, 2018 at 6:24 AM julio cesar sanchez > > > >> > wrote: > > > >> > > > > > >> > > I wouldn't point to a fork, because that will mean we have to > > search for > > > >> > > the forks and decide which one is better. > > > >> > > > > >> > +1 > > > >> > > > > >> > > If a better fork appears after archiving > > > >> > > we won't be able to change. > > > >> > > > > >> > I think someone else made the point that we can always unarchive in > > > >> > case of need. I suspect (and hope) we should be able to unarchive > > on a > > > >> > temporary basis then re-archive. > > > >> > > > > >> > > I think best option is to point to network tab of github (in case > > people is > > > >> > > > > >> > +1 > > > >> > > > > >> > > > - > > > >> > 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
Re: INFRA requests based on the F2F meeting
Sorry hit send too quick. I added jira.cordova.io as a transition step for us that points to the current JIRA On Thu, Aug 23, 2018 at 2:04 PM Shazron wrote: > > I've changed the redirect issues.cordova.io to point to > https://github.com/apache/cordova and added a pointer in the README on > where to file an issue. It might take some time to propagate > On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski wrote: > > > > Oh wow, you already can't create issues for Cordova in JIRA any more. > > That was quick. > > > > Is there maybe a way to somehow point people into the right direction in > > JIRA? > > We will now of course update issues.cordova.io, but I assume some > > peole have https://issues.apache.org/jira/projects/CB/ or similar URLs > > bookmarked. > > > > -J > > > > 2018-08-16 10:34 GMT+02:00 Shazron : > > > 1. Org Level Project Board > > > https://issues.apache.org/jira/browse/INFRA-16913 > > > 2. Lock down JIRA for creation of new issues > > > https://issues.apache.org/jira/browse/INFRA-16914 > > > > > > - > > > 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
Re: INFRA requests based on the F2F meeting
I've changed the redirect issues.cordova.io to point to https://github.com/apache/cordova and added a pointer in the README on where to file an issue. It might take some time to propagate On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski wrote: > > Oh wow, you already can't create issues for Cordova in JIRA any more. > That was quick. > > Is there maybe a way to somehow point people into the right direction in JIRA? > We will now of course update issues.cordova.io, but I assume some > peole have https://issues.apache.org/jira/projects/CB/ or similar URLs > bookmarked. > > -J > > 2018-08-16 10:34 GMT+02:00 Shazron : > > 1. Org Level Project Board https://issues.apache.org/jira/browse/INFRA-16913 > > 2. Lock down JIRA for creation of new issues > > https://issues.apache.org/jira/browse/INFRA-16914 > > > > - > > 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
Re: What to do with cordova-discuss?
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 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
