Re: INFRA requests based on the F2F meeting

[Shazron]

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

[Shazron]

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?

[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

Re: [DISCUSS] [Github Issues] Issue and Pull Request labels

[Shazron]

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

Nightly build #828 for cordova has failed

[Apache Jenkins Server]

Nightly build #828 for cordova has failed.

Please check failure details on build details page at 
https://builds.apache.org/job/cordova-nightly/828/
You can also take a look at build console: 
https://builds.apache.org/job/cordova-nightly/828/consoleFull

-
Jenkins for Apache Cordova

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[Cordova dev] Struggling with discussions

[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.

[Cordova dev] Deprecate some more Cordova plugins?

[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.

Can we please keep Cordova dev chat on a public channel?

[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?

Re: Dealing with deprecated repos

[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
>
>

New repository apache/cordova-contribute

[Jan Piotrowski]

Hi,

today I created a new repository https://github.com/apache/cordova-contribute

It is meant to contain all the contributor documentation like general
process, all the "How we do GitHub" documentation that will be written
based on the recent mailing list threads etc.

Content should be added via Pull Requests, the first one is already
open and waiting for comments and reviews:
https://github.com/apache/cordova-contribute/pull/2 "Deprecation and
Archiving"

Future content I am collecting right now:
- Becoming a contributor
- Contributing Code
  - GitHub Pull Requests
- Documentation
- Testing
- Continuous Integration
  - Nightly Builds
- Security
- Versioning
- Releasing packages/software/libraries
- Mailing Lists
- Slack
- GitHub
  - GitHub Issues
  - GitHub Project Boards
- Documentation
- Release Planning
- Deprecation and Archiving
- GitHub Labels
- GitHub Milestones
- GitHub Templates
- Canned Responses
- Automation
(pretty much unordered list, topic will be added or removed)

Theoretically it has big overlap with
https://github.com/apache/cordova-coho/tree/master/docs, but
practically I think it makes sense to clean that up anyway and move
the non-coho stuff to a new place while updating it -
cordova-contribute.

There might also be some overlap with
https://cordova.apache.org/contribute/ (or mainly its subpages, as
/contribute is mainly a list of repos), depending on how
cordova-contribute develops we could decide to replace /contribute
with it and pull in the files like we do for plugin documentation.
We'll see.

Best,
Jan

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Dealing with deprecated repos

[Jan Piotrowski]

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 
> :
> >
> > +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

What to do with cordova-discuss?

[Chris Brody]

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".

Re: Dealing with deprecated repos

[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 :
>
> +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

[GitHub] janpio closed pull request #1: [WIP] Deprecation and Archiving Policy

[GitBox]

janpio closed pull request #1: [WIP] Deprecation and Archiving Policy
URL: https://github.com/apache/cordova-contribute/pull/1
 
 
   


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 #1: [WIP] Deprecation and Archiving Policy

[GitBox]

janpio commented on issue #1: [WIP] Deprecation and Archiving Policy
URL: https://github.com/apache/cordova-contribute/pull/1#issuecomment-415116916
 
 
   Thank you for hijacking this pull request, although I explicitly added 
"[WIP]" to its title and mentioned that I will send an email when this is ready 
for review.


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] brodybits commented on issue #1: [WIP] Deprecation and Archiving Policy

[GitBox]

brodybits commented on issue #1: [WIP] Deprecation and Archiving Policy
URL: https://github.com/apache/cordova-contribute/pull/1#issuecomment-415113793
 
 
   I gotta say that I cannot see what a deprecation policy has to do with a 
project about "contributors". I would also favor putting this information into 
its own document, and adding a pointer somewhere else if appropriate.
   
   I would think the following projects would be a better match for adding this 
info:
   - cordova-coho
   - cordova-docs
   - 


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: [GitHub] janpio opened a new pull request #1: [WIP] Deprecation and Archiving Policy

[Jan Piotrowski]

Sorry for this email, I seem to have misconfigured the new repo. Will
get it changed by INFRA.

J
Am Mi., 22. Aug. 2018 um 19:18 Uhr schrieb GitBox :
>
> janpio opened a new pull request #1: [WIP] Deprecation and Archiving Policy
> URL: https://github.com/apache/cordova-contribute/pull/1
>
>
>Work in Progress PR - will send out email to dev mailing list when read to 
> review (and change title and this description)
>
> 
> 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

[GitHub] janpio opened a new pull request #1: [WIP] Deprecation and Archiving Policy

[GitBox]

janpio opened a new pull request #1: [WIP] Deprecation and Archiving Policy
URL: https://github.com/apache/cordova-contribute/pull/1
 
 
   Work in Progress PR - will send out email to dev mailing list when read to 
review (and change title and this description)


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: [DISCUSS] [Github Issues] Support questions in GitHub issues

[Jan Piotrowski]

Nope, the last few days convinced me that we do not want that ;)

But it gave a nice impression what we should add to the issues
templates so bug reports are actionable.


Am Mi., 22. Aug. 2018 um 01:21 Uhr schrieb julio cesar sanchez
:
>
> I just had a quick look and around 90% of new issues are tagged with
> support label. Do we really want that? Real issues will be buried with this
> volume of support issues.
>
> El sábado, 11 de agosto de 2018, julio cesar sanchez 
> escribió:
>
> > I have always closed the issues that weren’t issues and pointed people to
> > SO or slack. Same for when ask questions on the dev mail list.
> >
> > El sábado, 11 de agosto de 2018, Jan Piotrowski 
> > escribió:
> >
> >> > I think we should make that clear in the issue template
> >> > and direct people to slack or stackoverflow.
> >>
> >> I personally don't really think that's necessary.
> >>
> >> The issue volume for Cordova is very low (at least on JIRA and at
> >> least since Github issues were enabled), so having a few support
> >> requests bring some activity (and in the best case positive outcome
> >> for the users) is actually a good thing.
> >>
> >> Another aspect: The moment you introduce a restrictive policy, the
> >> issues work as a maintainer tends to get very negative - most people
> >> ignore the issue template anyway and post their support requests
> >> anway, which you have to close and post a canned reply.
> >>
> >> Which of course doesn't mean that the "Support Request" issue template
> >> should not direct people to StackOverflow and Slack, and definitely
> >> include some fields to fill out so we have something to work with (OS,
> >> versions etc.). But that's a thing for the other mailing list thread.
> >>
> >> If the volume or benefit of support requests ever gets overwhelming,
> >> we can still change that policy.
> >>
> >> > We might still use a support label as closing reason.
> >>
> >> If the majority of maintainers really wants to disallow support
> >> requests, this would be a nice way to categorize those requests and
> >> enable a discussion in the closed issue anyway.
> >>
> >> -J
> >>
> >>
> >> 2018-08-11 9:30 GMT+02:00  :
> >> > Jan proposed a support label for issues more than once. That fit me
> >> > thinking. Do we really want to allow support questions like this one
> >> [1] in
> >> > the issues?
> >> >
> >> > I'm definitely against it. I think we should make that clear in the
> >> issue
> >> > template and direct people to slack or stackoverflow. We might still
> >> use a
> >> > support label as closing reason.
> >> >
> >> > What do you think?
> >> >
> >> > [1]: https://github.com/apache/cordova-android/issues/474
> >>
> >> -
> >> 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] Delete apache/cordova-fauxton-server repository?

[Jan Piotrowski]

And it's gone. Thanks INFRA!
Am Mi., 22. Aug. 2018 um 15:33 Uhr schrieb Jan Piotrowski
:
>
> INFRA issue created: https://issues.apache.org/jira/browse/INFRA-16938
> Am Di., 7. Aug. 2018 um 00:03 Uhr schrieb :
> >
> > +1
> >
> > Chris Brody  schrieb am Mo., 6. Aug. 2018, 16:38:
> >
> > > +1
> > > On Mon, Aug 6, 2018 at 10:37 AM julio cesar sanchez
> > >  wrote:
> > > >
> > > > +1
> > > >
> > > > El lun., 6 ago. 2018 a las 16:36, Jan Piotrowski ( > > >)
> > > > escribió:
> > > >
> > > > > During enabling of issues and removing of "Mirror of ..." on our
> > > > > Github repos INFRA noticed that we have a repo without any content
> > > > > (issues, history, ...):
> > > > >
> > > > > https://github.com/apache/cordova-fauxton-server
> > > > >
> > > > > I will ask INFRA to remove/delete this repo at the end of the week if
> > > > > there are no objections.
> > > > >
> > > > > -J
> > > > >
> > > > > -
> > > > > 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] Delete apache/cordova-fauxton-server repository?

[Jan Piotrowski]

INFRA issue created: https://issues.apache.org/jira/browse/INFRA-16938
Am Di., 7. Aug. 2018 um 00:03 Uhr schrieb :
>
> +1
>
> Chris Brody  schrieb am Mo., 6. Aug. 2018, 16:38:
>
> > +1
> > On Mon, Aug 6, 2018 at 10:37 AM julio cesar sanchez
> >  wrote:
> > >
> > > +1
> > >
> > > El lun., 6 ago. 2018 a las 16:36, Jan Piotrowski ( > >)
> > > escribió:
> > >
> > > > During enabling of issues and removing of "Mirror of ..." on our
> > > > Github repos INFRA noticed that we have a repo without any content
> > > > (issues, history, ...):
> > > >
> > > > https://github.com/apache/cordova-fauxton-server
> > > >
> > > > I will ask INFRA to remove/delete this repo at the end of the week if
> > > > there are no objections.
> > > >
> > > > -J
> > > >
> > > > -
> > > > 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

[Jan Piotrowski]

Nice!

Seems the project is linked to https://github.com/apache/cordova as
https://github.com/apache/cordova/pull/1 is the only one thing that
shows up when one removes the `is:open` filter when "Only show results
from linked repositories" is checked.

Am Mi., 22. Aug. 2018 um 05:02 Uhr schrieb Shazron :
>
> Forgot to paste the link:
> https://github.com/orgs/apache/projects/2
>
> To grab issues from repos, Add Cards -> uncheck "Only show results
> from linked repositories" then use a query to limit your search
> On Wed, Aug 22, 2018 at 9:37 AM Shazron  wrote:
> >
> > The Org Project Level Board has been created. We can add issues from
> > all repos in the Apache org now.
> > https://issues.apache.org/jira/browse/INFRA-16913
> >
> >
> > On Sat, Aug 18, 2018 at 4:22 PM Shazron  wrote:
> > >
> > > Update: INFRA has fixed the issue. We can make modifications on issues
> > > again. Creation of issues is disabled -- only CB Project Admins can
> > > create new issues.
> > > On Sat, Aug 18, 2018 at 4:02 PM Shazron  wrote:
> > > >
> > > > I'll ask INFRA to revert the change.
> > > > On Fri, Aug 17, 2018 at 3:51 PM Jan Piotrowski  
> > > > wrote:
> > > > >
> > > > > Can confirm, Cordova JIRA seems to be fully read only now. Seems we
> > > > > should roll back and only deactivate after we migrated everything
> > > > > (somehow).
> > > > >
> > > > > 2018-08-17 5:05 GMT+02:00 Shazron :
> > > > > > There might be a side effect on locking down JIRA. I can't comment 
> > > > > > on
> > > > > > existing JIRA issues now.
> > > > > > On Thu, Aug 16, 2018 at 9:40 PM Shazron  wrote:
> > > > > >>
> > > > > >> Not sure how, maybe edit some project settings in JIRA, need to 
> > > > > >> investigate.
> > > > > >>
> > > > > >> 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
> > > > > >
> > > > >
> > > > > -
> > > > > 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