Re: JIRA assign & admin permissions

This may have to do with the Jira migration to LDAP. On Wed, May 22, 2019 at 8:30 AM Dmitriy Pavlov wrote: > Hi Training Developers, > > Recently I've observed that I'm not anymore admin in JIRA for the training > project. Could you please assign admin role back? > > Also, I cannot assign

Re: Git branches

+1 to fork & PR. It works great. *From: *Lars Francke *Date: *Wed, May 15, 2019 at 9:58 AM *To: * Hi, > > I'm not sure how other projects do this (well, I do, but not all of them) > but I'd be in favor of keeping the Git branches we have clean (i.e. not > having feature branches in the Apache

Beam Kata / project-specific trainings

Hi Training! Recently Beam received an offer of some training materials called "Beam Kata" [1]. The Beam community is enthusiastic about this, and setting up an area in the Beam repo for it. I certainly don't want to redirect efforts or slow anything down there. So my question is whether there

Re: Linguistics question on the plural of training

Just another data point but I'm a native English speaker (California, USA) and "trainings" sounds totally normal, and I've heard it a lot where I work. Like "I have to do all these mandatory corporate trainings" to refer to the many 10-30 minute fully packaged automated trainings. It is something

Re: [VOTE] Contribution guidelines

+1 On Tue, Apr 2, 2019 at 12:39 PM Lars Francke wrote: > +1 > > On Tue, Apr 2, 2019 at 9:19 PM Mirko Kämpf wrote: > > > +1 > > > > > > > > Dmitriy Pavlov schrieb am Di., 2. Apr. 2019, 21:17: > > > > > +1. Side note: it is probably better to have a short guide instead of > > > too-wordy

Re: Project Bylaws

I think that is right. I think it already fits with what you said before. Trust the committer to decide. Kenn > > Best, > Sönke > > On Mon, Apr 1, 2019 at 6:09 PM Kenneth Knowles wrote: > > > Great summary! One thing I didn't really understand. > > > &g

Re: Project Bylaws

t; > Thank you for sharing, it is a very good topic. I've copy-pasted it at > > least to Ignite > > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-PeerReviewandLGTM > > and > > I agree with this approach for Trainin

Re: Project Bylaws

t for new committers. > > As far as I can tell this is not written down in your Contributors guide. > Do you have it somewhere else or is this "informal"? > > On Fri, Mar 15, 2019 at 5:02 AM Kenneth Knowles wrote: > > > Interesting idea about the 72 hour lazy co

Re: [VOTE] Jira Workflow

+1 On Fri, Mar 15, 2019 at 7:45 AM Dmitriy Pavlov wrote: > +1 > > пт, 15 мар. 2019 г. в 13:15, Mirko Kämpf : > > > +1 > > > > > > > > Am Fr., 15. März 2019 um 08:44 Uhr schrieb Sönke Liebau > > : > > > > > Hi all, > > > > > > as the discussion around the proposed Jira workflow seems to have run

Re: Project Bylaws

; > I understand what you mean but I (others might disagree) would like to > see > > it codified as RTC and have the commit without a review as the exception > > not the other way around. This has been a major pain for me as a "lone" > > non-big-corporate

Re: Google Season of Docs 2019

That's a lot of dev lists on one thread. Adding a couple more... :-) Kenn On Tue, Mar 12, 2019 at 7:17 PM Dave Fisher wrote: > > > > On Mar 12, 2019, at 7:01 PM, Huxing Zhang wrote: > > > > Hi Dave, > > > > On Wed, Mar 13, 2019 at 2:14 AM Dave Fisher > wrote: > >> > >> Hi - > >> > >> Looks

Re: Jira Workflow

t; > > > > > Open->...validate...->Open(triaged)->... actual work..->Patch > > > Available->...review... ->Closed. > > > > > > Patch Available indicates patch is there and it is ready for review, > it is > > > in a sta

Re: [VOTE] Website technology

+1 On Mon, Mar 11, 2019 at 8:26 AM Christofer Dutz wrote: > +1 Chris > > Outlook für Android herunterladen > > > From: Sönke Liebau > Sent: Monday, March 11, 2019 3:29:36 PM > To: dev@training.apache.org > Subject: Re: [VOTE] Website

Re: Jira Workflow

On Wed, Mar 6, 2019 at 3:19 PM Sönke Liebau wrote: > Hey all, > > just to pick this up again, we have a suggestion for a fairly simple > workflow by Kenn, which I'd like to briefly summarize to ensure that I > understood everything correctly :) > > The workflow will have three states: > Open >

Re: Confluence // Wiki

k of which topic is being discussed in which mail track, > > >> which is fine as long as it is discussions, but once we start deciding > > >> on a few things I don't think the mailing list is the right place for > > >> those to be documented. > > >>

Re: Jira // Bug tracker

+1000 to separating issues@. Interesting idea having creation messages show up on dev@. I'd be happy to help administer. I do quite a bit of Jira. Username is kenn. Kenn On Mon, Feb 25, 2019 at 1:27 PM Sharan Foga wrote: > Hi Lars > > I can help with Jira admin too - my JIra login is sharan.

Re: Project Bylaws

On Fri, Feb 22, 2019 at 2:31 PM Lars Francke wrote: > > > > Bylaws have gone out of fashion and it’s generally recommend that > podlings > > (and TLP) don’t have them and use the “default”. > > > > Really? I didn't notice. > > > > As the default is often unclear I've created a default simple set

Re: Website

es for a setup > in > > which the website is generated from asciidoc as part of the maven > build > > And it is also automatically staged and published by git-pub-sub. > > IANAWD (I am not a web designer), and the content definitely needs an >

Re: Jira // Bug tracker

> > One thing I've encountered on GitHub is that you can only assign a PR > > review to a member of the `apache` organization. Is that also true for > > issues? > > Most likely but I don’t know. Because of GitHib's poor granularity of it's > permission system INFRA have locked it down and a lot of

Re: Jira // Bug tracker

One thing I've encountered on GitHub is that you can only assign a PR review to a member of the `apache` organization. Is that also true for issues? Kenn On Fri, Feb 22, 2019 at 3:36 PM Sönke Liebau wrote: > Heyho, > > in the case of jira vs github issues I am in favor of jira. > Github issues

Re: Website

It can all be in one repo. Beam recently moved the site from the apache/beam-site repo to a directory in the main apache/beam repo. It is nice to not have multiple places you have to go looking for bits. And it is published on every commit using gitpubsub. I didn't set that up, but I can ask