[Owasp-leaders] Access management on GitHub

Larry Conklin larry.conklin at owasp.org
Thu Jan 12 17:23:58 UTC 2017


 I sent this email out partly based on this email thread.
Tom, et-all

I want to steal your email thread because it does have a common thread that
I want to explore. We in OWASP proudly keep going down a path we don't want
to with total disregard to reality.

OWASP code project health. I have been involved with others trying to help
with getting our code projects into a healthy state. A hard thing to
accomplish and even much harder than it really should be.

Recently Claudia put out an email asking the community to help validate
OWASP code projects for promotion. First as a community, we drop the ball
in a big way. While everyone seems to have opinions about how projects will
be maintain, be in github under what ownership/account, what constitutes a
healthy project. Reading the feedback from Claudia only two people actually
went thru the process of validating the projects. That is not good for an
active community.

Second, I took the time to add comments to my validation. I made the
comment projects needed to use badges. Please, look at Zap and see how it
Zap project uses badges. Yes, they are the gold standard for other projects
in OWASP to strive too. I also made a comment about ownership in GitHub.  Was
any of my feedback sent to the project managers of these projects? Can my
feedback stop a promotion?

Third, I would like to know what the staffs (Claudia and Matt) roles are
and responsibilities for promotion of a project. I think Claudia email sent
out graduating the projects for promotion was ill advised.  While I am in
total agreement these, are great projects and add value to OWASP I would
like to see things like at what project level should the project owner be
OWASP or for it to be clearly stated for all projects not to be under the
OWASP account in github. At this point, I don’t have a preference other
than to say I am tired of reading the same old arguments again and again on
the OWASP leaders list. We need agree on things and go from there.

All, we seem to confuse progress as a circular path. We need true
benchmarks, that are agreed on than we need to have sure we live up to
these agreements. We need active staff and community involvement.

Right now, the OWASP project health is broken. To fix it needs community
and staff. Matt my assumption is when you took the position on technical
leader this was to be a primary focus for that position. Now is your time
to rise and shine. Good luck!

Community, we all need to get behind this. If ever a topic needed to be
feted at an OWASP summit this is it.

On Tue, Jan 10, 2017 at 10:28 AM, Bjoern Kimminich <
bjoern.kimminich at owasp.org> wrote:

> Hi Sean,
>
> I'm not advocating to delete unmaintained repositories. The ones I want to
> *delete* are empty ones which were created but never (seriously) used. The
> *unmaintained* ones I would either a) _tag_ with banner and deprecation
> note or b) _move_ into an archive/legacy organization. The latter would
> forward the original URL to the new archive location. So continuity is not
> a problem.
>
> Cheers,
> Björn
>
> On Tue, Jan 10, 2017 at 4:05 PM, Sean Auriti <sean.auriti at owasp.org>
> wrote:
>
>> https://tommcfarlin.com/delete-old-repositories/
>>
>> It seems there is some value to having the code around and marked as
>> archived / deprecated / unmaintained.
>>
>>
>>
>> On Tue, Jan 10, 2017 at 4:55 AM Bjoern Kimminich <
>> bjoern.kimminich at owasp.org> wrote:
>>
>>> I do not think that OWASP org on GitHub should be a historical
>>> inventory. Everything on github.com/OWASP should be usable, documented
>>> and - most importantly - responsive to user requests (via Issues) and
>>> contributions (via PRs). Unmaintained projects fail at responsiveness, so
>>> they end up with tons of unanwered issues.
>>>
>>> Prime example from yesterday: In https://github.com/OWASP/rbac/issues/88
>>> a user asks: *"why no new commits in the package from 2015, I need to
>>> use it in large scale app and I'm afraid because of maintained. any help?"*
>>>
>>> This leaves a bad impression on maturity of OWASP's open source
>>> offerings. Even an honest *"Sorry, this project is currently not in
>>> active development!"* would be fine. Not receiving a response is what
>>> frustrates me most when opening an issue or PR. That's why we should at
>>> least make it visible when a project is unmaintained, so they *do not
>>> even ask a question in the first place* and won't be disappointed if
>>> they never get an answer.
>>>
>>> Put the "Inactive Project" banner on top of the README. Adding a "Use
>>> Project X instead" would be great! Alternatively move projects like this to
>>> an "owasp-archive"- or "owasp-legacy"-org if you prefer. Zombies should not
>>> stay in our main GitHub organization and certainly we should not add more.
>>>
>>> Also please note, that *deleting or moving a GitHub repository* is *not*
>>> equivalent to *deleting an OWASP Project*. Furthermore, *unmaintained*
>>> is a pretty blurry term, so I'd make it easier to grasp with some KPIs,
>>> such as:
>>>
>>>    - number of total open issues
>>>    - number of issues without a response/comment/label added by project
>>>    team
>>>    - age of oldest open issue
>>>    - *same as above three for PRs*
>>>    - age of last commit
>>>    - age of last release
>>>
>>> Statistics can give us a good overview here. Part of this we even get
>>> for free for projects we register on OpenHub: https://www.openhub.n
>>> et/orgs/OWASP/projects
>>> They just don't seem to update as regular as they did in the past and I
>>> have no idea how to retrigger an analysis over there.
>>>
>>> Cheers,
>>> Björn
>>>
>>>
>>> On Tue, Jan 10, 2017 at 1:23 AM, Sean Auriti <sean.auriti at owasp.org>
>>> wrote:
>>>
>>> On this note.  I think it would be good that every single OWASP project
>>> be on the OWASP github.  Even if they are not actively maintained.  Also
>>> before we delete any project, it would be good to check in with the project
>>> leaders and confirm that they no longer want that project to be an OWASP
>>> project.
>>>>>>
>>> On Mon, Jan 9, 2017 at 7:18 PM, Chetan Karande <chetan.karande at owasp.org
>>> > wrote:
>>>
>>> +1. Thanks  Bjoern for bringing this up.
>>>
>>> Without proper access rights, there is no way for project leaders to
>>> assign issues to contributors who are not already part of OWASP github
>>> account. It would be really helpful for project leaders to have rights to
>>> create a project team and add members to it.
>>>
>>> Chetan Karande
>>> OWASP NodeGoat project
>>>
>>> On Jan 3, 2017 9:52 AM, "Bev Corwin" <bev.corwin at owasp.org> wrote:
>>>
>>> +1 Yes, please set up a committee meeting to discuss this and how to
>>> best set up. Best wishes.
>>>
>>> Bev
>>>
>>>
>>> On Tue, Jan 3, 2017 at 4:55 AM, johanna curiel curiel <
>>> johanna.curiel at owasp.org> wrote:
>>>
>>> +Bjoern, I agree on this.
>>> If our technical staff also agrees, I think this clean up is surely
>>> necessary
>>>
>>> @Matt: If you also agree or have another suggestions from the technical
>>> point of view, please let us know so Bjorn can continue with the proposed
>>> changes
>>>
>>> On Wed, Dec 28, 2016 at 3:35 PM, Bjoern Kimminich <
>>> bjoern.kimminich at owasp.org> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA512
>>>
>>> Hi all,
>>>
>>> I noticed that the access rights on our GitHub organization are a mess
>>> at the moment. Most repositories have a "team" defined representing the
>>> project team - which is good, especially if a project has multiple repos,
>>> where manually adding individuals to each stops being fun.
>>>
>>> The bad news: Most of these "teams" have been deleted at some point in
>>> time. GitHub unfortunately does not remove those from assigned repos
>>> automatically. So we now have a several zombie teams on GitHub that show a
>>> 404 when trying to view them.
>>>
>>> Then there is this "Owner" team where ~17 people are in, and an "Admin"
>>> team where only I am in, for unknown reason. Neither team membership gives
>>> full access to the org settings, so no idea what they are good for.
>>>
>>> Is there a secret concept behind this? If not, I vote for tabula rasa:
>>>
>>> 1. Delete all teams
>>> 2. Remove all (zombie) teams from all repos
>>> 3. Create a dedicated team per OWASP project that has repos in the org
>>> and assign their members
>>> 4. Assign teams to their repos as "Writer" or "Admin" (depending how
>>> project prefers)
>>> 5. Give at least project leader individual "Admin" prefs on repos of
>>> his/her projects
>>> (6. Create one admin team and assign it as "Admin" to all repos)
>>>
>>> Better ideas? I suggest doing this *after* clearing the trash/empty
>>> repositories to avoid useless effort.
>>>
>>> Cheers,
>>> Bjoern
>>> -----BEGIN PGP SIGNATURE-----
>>>
>>> iQFfBAEBCgBJQhxCasO2cm4gS2ltbWluaWNoIChQcml2YXRlIEVtYWlsYWRyZXNz
>>> ZSkgPGJqb2Vybi5raW1taW5pY2hAZ214LmRlPgUCWGPNngAKCRAGKoWoy/vc2qtI
>>> B/9qLzlJN8WtFlSvfHZVKBAfo+uFAKAz53WNqnRvmJvn/zEhPgbsT7hMgfbwnoLV
>>> UcM01uvOBsVZRZIsyBP1fpcy+1mtPsD6FnYhGZBhglQm2UTuHK3iyrLCEnYX/Glc
>>> i8wVeIUIAcQUac+Jwj4MAuvh64naNKHqQyg9z3pPM1cMEpAmtWFyytUT9eUrVlnn
>>> HElvBxPB8b3oMcj22bpY75WtJDY0uHLs2ylFTNTISSKYVad2NBMLZPGnIZ5AONkq
>>> 3ydSDAoJxnVJx1CIK6kP0beFxm3QyAaGvwlu9pWr19SlWG9btW7soM/Z8flkY+ji
>>> DCm6qOptWAgnW8PzsjmO/TRv
>>> =P6AH
>>> -----END PGP SIGNATURE-----
>>>
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>>
>>>
>>>
>>> --
>>> Johanna Curiel
>>> OWASP Volunteer
>>>
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>>
>>>
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>>
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>>
>>>
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>>
>>>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20170112/4219cb39/attachment-0001.html>


More information about the OWASP-Leaders mailing list