Re: Onboarding Experience, Knowledge Architecture, Events and D

[Justin Mclean]

Hi,

This summary may help [1] with a few things.

Thanks,
Justin

1. https://wiki.apache.org/incubator/DefaultProjectGuidelines

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

Re: Onboarding Experience, Knowledge Architecture, Events and D

[Justin Mclean]

Hi,

> The phrasing at https://www.apache.org/foundation/board/reporting 
>  is "While
> in most cases the chair works with other PMC members to write the report,
> the report is ultimately the chair's responsibility to complete and submit.”

It also needs to reflect the view of the PMC. In one project I’m the chair of 
the PMC does all the work and I add anything they have missed or suggest a few 
changes, in another I generally write the whole thing with occasional input 
from other PMC members. Either is fine, but it makes the chair life a little 
easier if it done as a collaboration, and the chair may miss things. If the 
chair is not available for any reason a PMC member can submit the report. 

Thanks,
Justin

Re: Onboarding Experience, Knowledge Architecture, Events and D

[Justin Mclean]

Hi,

> The PMC doesn't select a chair (it doesn't have the authority), but it 
> motions the board to appoint a specific person as chair, sort of like 
> introducing legislation in a parliament but not being able to vote on it. The 
> board then votes and either ratifies that motion, or it says "we're not going 
> to do that and here's why". A chair is an officer of the foundation, and as 
> such, HAS to be appointoed by the board of directors in the case of top level 
> projects.

Which is what I said, but perhaps select is too strong a word, it’s more 
suggest. I’m not seen the board not accept a suggested chair for a project. I 
have however seen them remove chairs for one reason or another.

Thanks,
Justin

Comments on the ppt deck - Onboarding Experience, Knowledge Architecture, Events and D

[Haoning Y Richter]

Hi, Aizhamal,

Thank you for sharing such a nice presentation draft with us!

I love the neat design of the slides: simple, pleasant, and just-right
amount of colors.

My background is in the areas of strategic advisory, process design and
implementation, risk management, audit, finance, and accounting.  I'm also
new to Apache.

If you don't mind, I'd like to offer some general suggestions for your
consideration from a new Apache member and non-technical perspectives.

*1. Slide # 1 - Cover Page Slide: *
"The Apache Way for Everyone".   Would "The Apache Way" be more flexible
and more accurate?  It reminds me of "HP Way" but HP did not say "HP Way
for Everyone".
I guess your presentation target audience will be the new Apache
contributors?  In fact, your presentation could probably be a "recruiting"
or "introduction of Apache" tool for anyone who may consider joining Apache
in the future.  If your presentation can be widely used beyond just the
newcomers, remove "for everyone" may be more appealing to the non-Apache
audience.

Currently, there is no "Table of Content".  Would you consider adding it as
your new slide # 2?

*2. Slide # 2 "Mission of ASF": *
"...by providing services and support for *like-minded* software
projects..."
If this is indeed Apache mission or belief, I am curious about why
emphasize "like-minded"?  I feel it might be helpful to provide some
context.   I believe creativity and thinking outside of the box are the
critical mindset to technology in general.  If everyone is thinking the
same or if we want everyone to conform, how effectively can we develop
better and new tools, applications, etc.?

*3. Slide # 3: *
This is the Overview slide.  I recommend removing the last bullet point as
it doesn't provide much substanceand it appears self-promoting or
self-recognition without providing any achievement or evidence.  If my
understanding of Apache is correct, it has become the most respected
technology community globally.  Talented developers around the world take
the pride in contributing their own time and energy in developing Apache
projects and/or initiatives.  Most of them (if not all) are not paid to do
so.  With this said, I feel perhaps we can beef up this slide to add some
international facts so that the new members won't feel it is U.S. Centric
because it is not.

*4. Slide # 4 "Legal Structure of ASF": *
I'm not sure this slide shall be labeled as a legal structure.  It appears
to be an organizational chart. or decision maker organization chart.  What
kind of legal services or legal decisions will each of the roles play on
this slide?

*5. Slide # 5 "The Apache Way": *
This is an introduction slide.  If "THe Apache Way" is driven by the "Six
Principles", then I'd suggest we move slide # 20 "The Six Principles" to be
slide # 6 to support slide # 5.

*6. Slide # 7 through Slide # 12: *
Those slides, in theory, shall be the explanatory slides to explain each of
the Six Principles.

*7. Slide # 8:  *
"If it didn't happen on the mailing list, it didn't happen."  I understand
the importance of putting everything (all communication) on emails.
However, it may not capture another or other expectations where perhaps
Apache organization has some form of record keeping methodology or
initiative where email correspondences are no longer the only way to keep
track of projects, comments, revisions, etc.  Some people's contributions
may not be captured by sending to a mailing list due to various reasons.
 From risk management perspectives, record retention is actually one of the
hot topics in protecting the company and minimizing legal exposure...

*8. Slide # 9: *
Assuming the sequence of the actions is correct, the numbering is a bit
confusing.  Would you consider adding (or moving) the numbers to their
corresponding action?
Example: 1. Consensus2. Preparing for a Vote . 3. Casting your Vote
 4. Calling a Vote

Additionally, I feel we missed a step here.  Conducting a Vote isn't the
objective.  The objective is to get the votes in order to make a decision.
With this said, would you think perhaps we shall add the following two
steps after "4. Calling a Vote":  5. Consolidating Votes6. Sharing and
Evaluating Votes   7. Making the Decision

*9. Slide # 12:  *
"Responsibilities and Expectations".  Given the volunteering nature of
Apache, it is very hard to hold each person accountable the same way as we
normally would do in a profit organization...Most volunteers have their
busy full-time jobs.  Hence, sometimes, I can imagine some contributors may
wear different hats and some volunteers may not be able to commit to a
tight deadline given some circumstances.  I would suggest not to put the
responsibilities in such a detailed way.  Perhaps a more general conceptual
description of each role would be sufficient?

*10. Slide # 13 through Slide # 16: "Apache Citizenship for Everyone".*
I'd like to suggest we say "Apache Citizenship" (remove "for everyone")
No matter how good a process 

Re: Onboarding Experience, Knowledge Architecture, Events and D

[Daniel Gruno]

On 12/20/18 3:14 AM, Kenneth Knowles wrote:

On Wed, Dec 19, 2018 at 8:19 PM Justin Mclean 
wrote:



Slide 4
- While the chair is responsible for making sure teh report is submitted
to the board, it's the PMC who writes and contrite to it. "The report is
technically single-author written by the PMC chair.” is sometimes teh case
but in some project its more of a collaborative effort.



The phrasing at https://www.apache.org/foundation/board/reporting is "While
in most cases the chair works with other PMC members to write the report,
the report is ultimately the chair's responsibility to complete and submit."

I've been coached that the report is, ultimately:

  - from: the chair
  - to: the Board
  - about: Beam

In practice, it is collaboratively drafted on dev@beam. I think there's
subtlety here that I probably don't understand fully. Sort of like how the
PMC selects a chair but the board appoints the person.

Can you help me understand this better?

Kenn



The PMC doesn't select a chair (it doesn't have the authority), but it 
motions the board to appoint a specific person as chair, sort of like 
introducing legislation in a parliament but not being able to vote on 
it. The board then votes and either ratifies that motion, or it says 
"we're not going to do that and here's why". A chair is an officer of 
the foundation, and as such, HAS to be appointed by the board of 
directors in the case of top level projects.


The chair is basically a glorified secretary (with certain additional 
day-to-day operational powers that I'll not go into detail about), and 
while the report can be and often is made as a collaborative effort, 
it's the chair responsibility to send that report - whether it be a team 
effort or a single person writing it - to the board.


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

Re: Onboarding Experience, Knowledge Architecture, Events and D

[Kenneth Knowles]

On Wed, Dec 19, 2018 at 8:19 PM Justin Mclean 
wrote:

>
> Slide 4
> - While the chair is responsible for making sure teh report is submitted
> to the board, it's the PMC who writes and contrite to it. "The report is
> technically single-author written by the PMC chair.” is sometimes teh case
> but in some project its more of a collaborative effort.
>

The phrasing at https://www.apache.org/foundation/board/reporting is "While
in most cases the chair works with other PMC members to write the report,
the report is ultimately the chair's responsibility to complete and submit."

I've been coached that the report is, ultimately:

 - from: the chair
 - to: the Board
 - about: Beam

In practice, it is collaboratively drafted on dev@beam. I think there's
subtlety here that I probably don't understand fully. Sort of like how the
PMC selects a chair but the board appoints the person.

Can you help me understand this better?

Kenn


Slide 9
> - Voting on contentious issues can cause division and split the community,
> so care needs to be taken to build consensus before a vote of this nature.
> - Voting on releases is different, -1 is not a veto
>
> Slide 10
> - CTR is much more common on ASF projects
>
> Slide 12
> - The tick and crosses are misleading, committer can be involved in
> everything but don’t have binding votes including on releases.
>
> Slide 15
> - Quick to review PRs need not apply with CTR and committer can mentor
> contributors as well in fact they may do that more than PMC members.
>
> I;’ll give some more feedback when I get a chance.
>
> Thanks,
> Justin
>
> 1. https://whimsy.apache.org/roster/
> 2. https://www.apache.org/foundation/policies/conduct.html
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Onboarding Experience, Knowledge Architecture, Events and D

[Justin Mclean]

Hi,

Also another missed point that in some projects (and more common in
incubating projects) is that committees = PMC

Thanks
Justin

On Thu., 20 Dec. 2018, 12:19 pm Justin Mclean  HI,
>
> Nice presentation.
>
> Here my feedback on this some of this is more opinion (there’s many Apache
> ways) and some is just how things tends to be done in projects I’ve worked
> with.
>
> Slide 3:
> - We’re 6679 committers, 730 members, 199 top level PLCs, 52 podlings
> currently. [1] May be good to mention teh incubator and prodding projects.
>
> Slide 4
> - While the chair is responsible for making sure teh report is submitted
> to the board, it's the PMC who writes and contrite to it. "The report is
> technically single-author written by the PMC chair.” is sometimes teh case
> but in some project its more of a collaborative effort.
> - While only the board can appoint the chair, the chair is usually
> selected by the PMC.
>
> Slide 6
> - Rather than “Avoid toxic behaviours” I say “Discourage any toxic
> behaviour”
> - I’d be more explicit "Contributors represent themselves not the company
> they work for”
> - Code of conduct [2] should be mentioned here? in “Community > code”?
>
> Slide 7
> - include “merit doesn’t expire” concept here
> - I think the toxic stuff needs some work
>
> Slide 8
> - https://lists.apache.org is a better archive / search link
>
> Slide 9
> - Voting on contentious issues can cause division and split the community,
> so care needs to be taken to build consensus before a vote of this nature.
> - Voting on releases is different, -1 is not a veto
>
> Slide 10
> - CTR is much more common on ASF projects
>
> Slide 12
> - The tick and crosses are misleading, committer can be involved in
> everything but don’t have binding votes including on releases.
>
> Slide 15
> - Quick to review PRs need not apply with CTR and committer can mentor
> contributors as well in fact they may do that more than PMC members.
>
> I;’ll give some more feedback when I get a chance.
>
> Thanks,
> Justin
>
> 1. https://whimsy.apache.org/roster/
> 2. https://www.apache.org/foundation/policies/conduct.html
>
>
>

Re: Onboarding Experience, Knowledge Architecture, Events and D

[Aizhamal Nurmamat kyzy]

Thank you Phil for taking time to review the slides and providing such a
thorough feedback!

This is incredibly insightful -- I can definitely see the room for
improvement and clarifications. I will try and improve the slides and
speaker notes based on your feedback.

I have a few questions, which I've left inline:

On Wed, Dec 19, 2018 at 3:18 PM Phil Steitz  wrote:

> Page 6 - the term "peer-based" seems a little odd to me and it looks
> like it is conflating two different things, both of which are
> important to us:  first - volunteers are *individuals* and second we
> have a flat org structure.  Related to the first is the idea of
> project independence, which is also important (we can't have
> projects dominated or controlled by external entities).  Missing at
> the top-level and usually included is *transparency* - everything
> technical, everything required to follow what is happening to the
> code is public and anyone interested needs to be able to follow what
> is going on via public lists.  This is covered more or less in the
> notes end elsewhere, but I would personally elevate it to a basic
> principle.  Traditionally, we have talked about Community,
> Meritocracy and Transparency as the pillars.
>

Ah thanks! This was the main struggle for me to put together, because I
couldn't come up with a clear list of basic principles. I found The Six
Principles[1] in the ASF website as core beliefs, but not much else was
written about them. Also, the same page refers to meritocracy as a basic
principle[2]. I think Community, Meritocracy and Transparency really
capture the philosophy of the Apache Way. I will change that slide to
include all these as top-level principles.

Perhaps I'll propose an update to the Philosophy section[1] of ASF website,
that presents these three as the basic principles to avoid confusion. Does
that sound fine to everyone?

Page 12 - I don't like the little check boxes limiting what
> committers (or any community member, for that matter) are
> responsible for.  The only real difference between PMC members and
> committers is that PMC members have binding votes on release and
> committer votes.  Committers absolutely do need to think about legal
> / IP and security issues.  And they should be involved in mentoring
> and encouraging contributors.  And all community members should have
> a voice in "rules and customs" for the project.  PMC members are not
> "managers" in the typical sense.  They are ultimately accountable to
> the Board and have binding votes, but they need to serve their
> communities.  And committers are not just coders.
>

I think these are good points. The intention of this slide is not to
present it as a hard truth, but more as a general guideline, and especially
to highlight that the PMC is ultimately accountable to the Board if any
legal/governance issues arise, and they are in charge of discussing private
matters such as new committers, and critical security bugs.

To express that, I think it may be useful to replace the "X"-marks with
"maybe", and give a detailed explanation in the speaker notes. How does
this sound?


> Page 14 - I am not sure I agree with the last item.  People leave
> projects all the time and there is no expectation that they "explain
> why they are leaving."
>

This is true. I agree that explaining why is not necessary. My idea was to
encourage people to set appropriate expectations about their involvement.
Perhaps replace that with "Be considerate: Set appropriate expectations
about your involvement". How does that sound?


> Page 15 - I don't think this is what you mean, but the slide makes
> it looks like the primary responsibility of each group is the thing
> on the right, which it isn't.  I would also be careful with the
> "don't be a bottleneck" idea.  Committers (or PMC members) should
> not feel like they have to quickly review all contributions.  They
> are volunteers.  If PRs go for a long time without getting reviewed,
> more volunteers may be needed or the community may simply not be
> interested in them.
>

That's a good point as well. I was trying to give some tips for
participating and contributing to a project in each role in a day-to-day
basis. I will rephrase the tips, and add some more detailed explanations in
the speaker notes.

Thanks a lot, I appreciate all the feedback! : )
-A

[1] https://www.apache.org/foundation/how-it-works.html#philosophy
[2] https://www.apache.org/foundation/how-it-works.html#meritocracy

-- 

*Aizhamal Nurmamat kyzy*

Open Source Program Manager

646-355-9740 Mobile

601 North 34th Street, Seattle, WA 98103

Re: Onboarding Experience, Knowledge Architecture, Events and D

[Phil Steitz]

On 12/19/18 12:41 AM, Aizhamal Nurmamat kyzy wrote:

Hello everyone!

My name is Aizhamal and I joined the Open Source Strategy team at Google
Cloud. I will work with Gris Cuevas (g...@apache.org) on two main projects:


-

New Contributor Experience - I’ll develop resources that will help
improve the onboarding experience of anyone who wants to contribute to an
Apache project for the first time
-

Open Source Documentation - I’ll develop resources related to best
practices for documentation in Open Source projects


Our team’s objective is to help new contributors become familiar with the
ASF, and help them be good citizens of the projects that they participate
in. With this we hope to support projects to develop a healthy Open Source
culture.

Our first contribution is this slide deck [1]
 with an introduction to The
Apache Way. We are aware it’s not the first presentation on this topic, but
we made it as a visual tool for presentation or self-study, so we’ve made
sure to have complete and detailed speaker notes for anyone to use.

If missed anything important, or misinterpreted some concept, I would
greatly appreciate your feedback.


Thanks so much for doing this, Aizhamal.  This is great content, 
really nicely presented with good speaker notes.  I have a few 
comments / suggestions for improvement.  All are obviously just my 
opinion and others may chime in with different views.  As you know, 
that's how it works...


I am referring to page numbers on the linked google doc as of today 
(12/19).  There may be a way to pull out a revision number, but I 
don't know how to do that.


Page 6 - the term "peer-based" seems a little odd to me and it looks 
like it is conflating two different things, both of which are 
important to us:  first - volunteers are *individuals* and second we 
have a flat org structure.  Related to the first is the idea of 
project independence, which is also important (we can't have 
projects dominated or controlled by external entities).  Missing at 
the top-level and usually included is *transparency* - everything 
technical, everything required to follow what is happening to the 
code is public and anyone interested needs to be able to follow what 
is going on via public lists.  This is covered more or less in the 
notes end elsewhere, but I would personally elevate it to a basic 
principle.  Traditionally, we have talked about Community, 
Meritocracy and Transparency as the pillars.


Page 7 - I don't like the term "toxic people."  I would prefer 
"toxic behaviors".  I especially don't like the "toxic people -> 
toxic communities".  That makes it look like the right strategy is 
to keep "toxic people" out.  We are all toxic sometimes and we count 
on each other to point the bad behaviors out and to demonstrate the 
healthy ones.


Page 10- I disagree that RTC leads to "higher quality and 
governance" and I am pretty sure that I am not alone in that view. I 
especially disagree with the statement that RTC is "usually, the 
recommended method."  I would recommend dropping that slide 
altogether or just stating that different communities, at different 
times, use different ways to collaborate on code.  The whole idea of 
"code review" is actually kind of foreign to us.  The whole point of 
open development with good version control is so that code is 
"reviewed" continuously and developed *collaboratively*.  It is the 
continuous review by a large community that delivers the quality in 
ASF software.


Page 12 - I don't like the little check boxes limiting what 
committers (or any community member, for that matter) are 
responsible for.  The only real difference between PMC members and 
committers is that PMC members have binding votes on release and 
committer votes.  Committers absolutely do need to think about legal 
/ IP and security issues.  And they should be involved in mentoring 
and encouraging contributors.  And all community members should have 
a voice in "rules and customs" for the project.  PMC members are not 
"managers" in the typical sense.  They are ultimately accountable to 
the Board and have binding votes, but they need to serve their 
communities.  And committers are not just coders.


Page 14 - I am not sure I agree with the last item.  People leave 
projects all the time and there is no expectation that they "explain 
why they are leaving."


Page 15 - I don't think this is what you mean, but the slide makes 
it looks like the primary responsibility of each group is the thing 
on the right, which it isn't.  I would also be careful with the 
"don't be a bottleneck" idea.  Committers (or PMC members) should 
not feel like they have to quickly review all contributions.  They 
are volunteers.  If PRs go for a long time without getting reviewed, 
more volunteers may be needed or the community may simply not be 
interested in them.


Thanks again for doing this, Aizhamal.  My comments 

Re: FOSDEM 2019 Stand

[محمد الخيلي]

لما هاده الرسايل ؟
وما دورها وأهميتها؟

في الأربعاء، ١٩ ديسمبر، ٢٠١٨ ١٨:٤٥، كتب Daniel Gruno :

> On 12/19/18 4:09 PM, Maximilian Michels wrote:
> > Daniel, do you think projects will have a screen of some sort to run a
> > presentation or a demo?
>
> It's a possibility. Last time I brought a small zotac machine and a
> monitor for the kibble demo, I might do the same this year, haven't
> thought it out yet :). Rich might bring the foundation chromebook(s) if
> that'll suffice...?
>
> >
> > Thanks,
> > Max
> >
> > On 04.12.18 22:49, Michael Peoni wrote:
> >> I had a Entry https://anewworldage.com but can't seem to find it 9i
> also
> >> have an Android API i would like to License./
> >>
> >> Thank's Mike
> >>
> >> On Tue, Dec 4, 2018 at 6:14 AM Griselda Cuevas  >
> >> wrote:
> >>
> >>> Thanks for taking care of that Max!
> >>>
> >>>
> >>>
> >>>
> >>> On Tue, 4 Dec 2018 at 03:51, Maximilian Michels 
> wrote:
> >>>
>  Daniel, could you give me access to the Wiki page so I can fill in the
>  information for the Beam stand?
> 
>  @mxm is my account name.
> 
>  Thanks,
>  Max
> 
>  On 04.12.18 12:37, Daniel Gruno wrote:
> > On 11/29/18 11:16 PM, Griselda Cuevas wrote:
> >> Hi Daniel,
> >>
> >> I'm attending the event and happy to help coordinate content/swag
> and
> >> other
> >> needs we have. Could you loop me in when you have a plan or if you
> >>> need
> >> help drafting one?
> >>
> >> G
> >>
> > Sure thing! I expect we'll have more info in the coming weeks, so
> stay
> > tuned :)
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>  For additional commands, e-mail: dev-h...@community.apache.org
> 
> 
> >>>
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: FOSDEM 2019 Stand

[Daniel Gruno]

On 12/19/18 4:09 PM, Maximilian Michels wrote:
Daniel, do you think projects will have a screen of some sort to run a 
presentation or a demo?


It's a possibility. Last time I brought a small zotac machine and a 
monitor for the kibble demo, I might do the same this year, haven't 
thought it out yet :). Rich might bring the foundation chromebook(s) if 
that'll suffice...?




Thanks,
Max

On 04.12.18 22:49, Michael Peoni wrote:

I had a Entry https://anewworldage.com but can't seem to find it 9i also
have an Android API i would like to License./

Thank's Mike

On Tue, Dec 4, 2018 at 6:14 AM Griselda Cuevas 
wrote:


Thanks for taking care of that Max!




On Tue, 4 Dec 2018 at 03:51, Maximilian Michels  wrote:


Daniel, could you give me access to the Wiki page so I can fill in the
information for the Beam stand?

@mxm is my account name.

Thanks,
Max

On 04.12.18 12:37, Daniel Gruno wrote:

On 11/29/18 11:16 PM, Griselda Cuevas wrote:

Hi Daniel,

I'm attending the event and happy to help coordinate content/swag and
other
needs we have. Could you loop me in when you have a plan or if you

need

help drafting one?

G


Sure thing! I expect we'll have more info in the coming weeks, so stay
tuned :)

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



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








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




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

Re: FOSDEM 2019 Stand

[Maximilian Michels]

Daniel, do you think projects will have a screen of some sort to run a 
presentation or a demo?


Thanks,
Max

On 04.12.18 22:49, Michael Peoni wrote:

I had a Entry https://anewworldage.com but can't seem to find it 9i also
have an Android API i would like to License./

Thank's Mike

On Tue, Dec 4, 2018 at 6:14 AM Griselda Cuevas 
wrote:


Thanks for taking care of that Max!




On Tue, 4 Dec 2018 at 03:51, Maximilian Michels  wrote:


Daniel, could you give me access to the Wiki page so I can fill in the
information for the Beam stand?

@mxm is my account name.

Thanks,
Max

On 04.12.18 12:37, Daniel Gruno wrote:

On 11/29/18 11:16 PM, Griselda Cuevas wrote:

Hi Daniel,

I'm attending the event and happy to help coordinate content/swag and
other
needs we have. Could you loop me in when you have a plan or if you

need

help drafting one?

G


Sure thing! I expect we'll have more info in the coming weeks, so stay
tuned :)

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



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








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

[jira] [Updated] (COMDEV-303) Better error handling when fetching DOAPs

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMDEV-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated COMDEV-303:

Attachment: parseprojects.log

> Better error handling when fetching DOAPs
> -
>
> Key: COMDEV-303
> URL: https://issues.apache.org/jira/browse/COMDEV-303
> Project: Community Development
>  Issue Type: Bug
>  Components: Projects Tool
>Reporter: Sebb
>Priority: Major
> Attachments: parseprojects.log
>
>
> If parseprojects.py cannot access a DOAP because of a network error, it 
> should not necessarily treat the file as obsolete.
> Also there appears to be a second exception when handling the first; it's not 
> clear if this is a bug in the Python library or in the script. See attached 
> log.
> Ideally the script should include more info in the e-mail it sends at the end 
> (e.g. it could store the first N failed fetches)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (COMDEV-303) Better error handling when fetching DOAPs

[Sebb (JIRA)]

Sebb created COMDEV-303:
---

 Summary: Better error handling when fetching DOAPs
 Key: COMDEV-303
 URL: https://issues.apache.org/jira/browse/COMDEV-303
 Project: Community Development
  Issue Type: Bug
  Components: Projects Tool
Reporter: Sebb


If parseprojects.py cannot access a DOAP because of a network error, it should 
not necessarily treat the file as obsolete.

Also there appears to be a second exception when handling the first; it's not 
clear if this is a bug in the Python library or in the script. See attached log.

Ideally the script should include more info in the e-mail it sends at the end 
(e.g. it could store the first N failed fetches)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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