Writing directly into the repository was certainly the wrong thing at
the wrong time since I was tasked to maintain the repository. But I
relinquish both the task of personally reviewing and managing the flow
all changes. So now it is a fair thing to be address. Now I would say
what committers do in the repositories is up to the PPMC. I am
completely out of the loop other than as a voting PPMC member.
I think the first question would be: Are the repositories a free-for-all
where anyone with the write bit can do anything they want? Or are their
limitations are what they can and cannot do. I hope that there are
limitations or we are doomed. I understand that the only "punishment"
of disobeying the rules is social, technically, any committer can do
anything they want: git rm -r *?
Assuming that committers don't have carte blanche to do whatever they
want in the repositories, the next question would be: Do committers have
a different work flow than contributors outside of the project? Would
we need document a separate workflow for committers? Or would we
annotate the work flow to indicate the alternative things you can do if
you are one of the chosen?
I would personally prefer that there is only one workflow and that that
all contributors, regardless of of their privilege must follow. Why?
Because we much be in touch with our end users. We must experience
everything exactly as the end-user experiences, and not optimize things
just to make things simpler for ourselves. We are both committers and
members of the same contributing community. We are not special with
regard to contributions. We cannot just optimize the path for the
chosen, we will just lose touch with the users of NuttX. This is often
referred to as "eating your own dogfood" and I think that each of us
should dish ourselves up a healthy portion.
Greg
On 12/22/2019 6:29 AM, David Sidrane wrote:
TLDNR; But you really should. Because I will ask for some discussion and votes
on the subject matter.
We all come from different places in the world. We all have had different
experiences. We all have learned different things. We all have learned in
different ways. We all have different communication styles. We all have
different skills, abilities and deficits.
Therefore I wonder if we have a different understanding of what a software
Community is
Here we are in this new environment, trying to build a community. I spent time
looking at the definition of community. The English dictionary was not much
help when it comes to describing a software community.
I am sure that as, we all have, I have picked up things concepts, tools etc over the
years. I like to share them when they help me. I recently posted a topic of "Are you
failure with the HAM Story?" [0],
Anyways I digress, but I want to give this community some insight into my
thought process and why the hell dyslectic would spend 4.25 hours writing this.
Okay maybe it was the insomnia and expresso :) But I tend to want to understand
the root cause of things, discuss them and get feedback on them. So here goes.
I tend to be very eclectic. This comes from a combination of my skills and limitations. I
best categorize myself as an "LC with an LD" ([1,2] ,[3]) and therefore I am
king of typos - Thank God for Nathan!
Given that this is an Apache Project (podling) and we will be using GitHub I tasked Google with “what is an Apache software community” and “how does GitHub Define community” to provide me a place to start.
For Apache I found this:
“Mission: The Community Development project creates and provides tools,
processes, and advice, to help open source software projects improve their own
community health.”
hmm ok, “Hey Google site:apache.org community health” It lead me to this:
Community Development and Mentoring. It had a link Project Community Health
Tips that required a password - My Apache ID worked Cool!
Results we, well How do I express this? hmmm...Disappointing.
It appears the condition to judge the health of an Apache project is the amount
of email. The number of releases, the number of additions to DLAP and the
number of invitations to new committers.
So from an Apache standpoint based on our email alone - NuttX is rocking it. :)
“Hey Google: how does GitHub Define community” lead me to [4] lead me to
"GitHub Community Guidelines"
Building a strong community
“The primary purpose of the GitHub community is to collaborate on software
projects. We want people to work better together. Although we maintain the
site, this is a community we build together, and we need your help to make it
the best it can be.”
Collaborate!
How do we Collaborate?
Is this endless stream of emails collaboration? Personally I think not. Don't
get me wrong there are some real Gems:Great ideas and thoughts, but because of
the nature of the tools we are using there's not a “lot of babies in this bath
water[6]”.
Is it imperative that we document discussions and decisions for ASF In the
open? Yes.
But since we are all members of GitHub now. We do not need to be receiving
duplicate emails for the purpose of fulfilling the archives requirement of ASF
or project health.
[Needs discussion & a vote] A simple way to fulfill our requirements is to
have github's issues and pull requests forwarded to a set of lists. Issues, pr, and
commits. I think this was already suggested by some of the PPMC.
Personally I will not be subscribing to any of them. I get the emails from
GitHub one copy and the benefit of directed filtering (use the @) is enough.
[Needs discussion & a vote] Do we want to use @NuttxPMC or @<username> to
get attention?
On the github organizations (aka projects) I have been a member of, we
collaborate via github tools and in the repository.
Recently ,I had a long debate with a colleague about using branches in an
organization’s project repository. I was also scolded for doing this. But in my
github experiences it is not wrong, but encouraged to promote collaboration.
I believe that the mindset of how to use Version Control has been influenced by
the evolution of Version Control systems [5], corporate policy and peoples
experience with them in the era they started. using them. I will not start
back at paper tapes nor 8 inch floppy disks being kept in the fireproof file
cabinet. Nor will I address IP protection.
SCCS ->RCS->CVS->perforce->SVN->git
In the Github organizations that I have been involved in, the members of the
community are relatively young (I am not) and started in the git era.
These organizations give admin rights to the core dev team (PPMC) and write
access to committers.
The members do create branches in the repository to share and collaborate on.
There are many reasons to do this: Some of them are social. Some of them are
about trust, Some of them are about how we perceive our community but mostly it
is about collaboration.
Yes it is true that we can all do PR from are own github forks. But why should
act as a collection of outside contributors and do that?
How do we collaborate at the coding level with our fellow PPMC members and
committers?
Comments (even the GH suggested changes) on a PR only get you so far,
discussion and the ability to push commit makes collaboration complete.
This type of collaborative committing is exactly the relationship we had used
with Greg. But it was not community collaboration. It was peer-to-peer and a
lot of times done in private. I was only public for discussion after it hit
master.
I agree with this way of adding value to contributions: Use the subject matter
experts to maximize value, but I feel we should expand on it.
I don't agree with doing this on master. Branches and PRs can only be effectively worked on collaborative in the project repo - otherwise it is a Fork and we will be forced to have N way peer-to-peer. relationships with our PMC and committers. Why force that if we want to collaborate?
I believe we should build an effective efficient and productive workfkow and
our team. Otherwise the project will implode as a result of the amount of
effort required on our parts will exceed our available time to accomplish
quality work. (Hats off to Greg - it is amazing what you have accomplished)
[Needs discussion & a vote] PRs are on branches in the project repo.
[Needs discussion & a vote] branches support a naming convention.
[0] https://lists.apache.org/list.html?dev@nuttx.apache.org:lte=1M:HAM
[1]
[https://www.goodreads.com/quotes/7778966-i-divide-my-officers-into-four-classes-as-follows-the
[2]
https://news.clearancejobs.com/2019/10/08/the-four-classes-of-military-officers-or-office-workers-clever-diligent-stupid-and-lazy/
[3] http://www.ldonline.org/ldbasics/whatisld
[4] https://help.github.com/en/github/site-policy/github-community-guidelines
[5]
https://www.lynda.com/ALMTFS-tutorials/history-version-control/106788/115979-4.html
[6] https://en.wikipedia.org/wiki/Don%27t_throw_the_baby_out_with_the_bathwater
