Re: OT: mail-based interfaces and web-based interfaces (Re: Extract
Michael G Schwern wrote:
> On 2012.7.25 4:48 PM, Eric Wong wrote:
> > We need to use something. Right now our choice of mailer is the best
> > choice for _existing_ contributors.
>
> I believe this entire discussion can be reduced to that right there.
>
> If your process is optimized for existing contributors, it will work well for
> existing contributors, who will want to optimize it for themselves. Repeat.
> If the main way you evaluate your process is asking "is this more convenient
> for me" then you're probably in that spiral.
>
> This creates a process very well tuned to the existing contributors, and its
> very convenient for them. But the consequence is it becomes more and more
> work for a new contributor to join.
The process is _not_ a lot of work. At least no more than any other
project: observe the regulars -> imitate the regulars
Many/most regular git contributors are not Linux kernel developers, yet
were able to quickly able to get up-to-speed with git. AFAIK, the Linux
kernel gets plenty of new contributors every year, too.
> Before talking about anything else, the existing contributors have to ask
> themselves a simple question: Do we care about getting new contributors?
Yes, if contributors are willing to learn/respect existing conventions.
We do take time to help new contributors out :)
For me, it's certainly "no" if there's any endorsement of
non-Free Software or centralized/commercial services involved.
> The answer can be "no" ("yes, but not if I'm inconvenienced" is a no). Maybe
> you're happy with the people you've got. But there's no point in getting into
> detail until that's settled.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OT: mail-based interfaces and web-based interfaces (Re: Extract
Michael G Schwern wrote: >Do we care about getting new contributors? Not if the cost is too high, no. I personally do think it is important to make life easy for new contributors, not because that will somehow compel them to work for me for free, but because it's a kind thing to do. Does that mean that I'm going to start reviewing patches submitted as virtual pieces of paper in Second Life if that is what is most convenient for potential new contributors? No way. If I felt compelled to do that, I'd become grouchy, and grouchily spending time indulging people out of a perverse sense of obligation is not a kind thing to do. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OT: mail-based interfaces and web-based interfaces (Re: Extract
On 2012.7.25 4:48 PM, Eric Wong wrote:
> We need to use something. Right now our choice of mailer is the best
> choice for _existing_ contributors.
I believe this entire discussion can be reduced to that right there.
If your process is optimized for existing contributors, it will work well for
existing contributors, who will want to optimize it for themselves. Repeat.
If the main way you evaluate your process is asking "is this more convenient
for me" then you're probably in that spiral.
This creates a process very well tuned to the existing contributors, and its
very convenient for them. But the consequence is it becomes more and more
work for a new contributor to join.
Before talking about anything else, the existing contributors have to ask
themselves a simple question: Do we care about getting new contributors?
The answer can be "no" ("yes, but not if I'm inconvenienced" is a no). Maybe
you're happy with the people you've got. But there's no point in getting into
detail until that's settled.
That's mostly a rhetorical question. I want to wrap up the meta-discussion
and focus on getting patches in.
--
100. Claymore mines are not filled with yummy candy, and it is wrong
to tell new soldiers that they are.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OT: mail-based interfaces and web-based interfaces (Re: Extract
Michael G Schwern wrote: > On 2012.7.24 7:55 PM, Eric Wong wrote: > > Except git is also a "new specialized tool". Your examples are exactly > > why I'm saddened many projects only adopted git, but not the workflow > > which _built_ git (and Linux). > > Github also has broad spectrum utility. I learn how to fork and work with a > Github pull request once, and I can repeat that on thousands of different > projects of all different sorts of things. > > This commonality of tools and techniques is very important to easing the on > ramp for new (to-your-project) developers. I agree commonality is important. But to me, it's not worth the cost of reliance on centralized, single-vendor solutions. My distrust and dissatisfaction with centralized/single-vendor solutions is the reason I'm involved with Free Software (and decentralized version control) in the first place. > > Email is integral to Free/Open Source development and remains one of the > > few things on the Internet not (yet) controlled by any central entity. > > Once setup, the same email setup can work across all projects which use > > email. These projects need not be hosted on the same websites/servers > > at all. > > While I hear your concern about being centrally controlled, it is largely > irrelevant to the new user experience. And remaining independent does not > mean you can't use web tools. Be wary of a false dichotomy between Free and > web. Of course, I'd be in favor of shifting development to something less centralized than a mailing list. OStatus may become a good choice one day, but the adoption/tools just aren't there right now. > "We use a mailing list" is by no means an indication of commonality. Every > project of the "send patches to the list" form has their own quirks and ways > of doing it. Usually they're not written down. This is what I've been > struggling with. I've been sending patches to mailing lists for decades and I > can tell you everybody does it differently. "Send a patch to the list" is one > of the steeper project on-ramps. Sure, every project/culture has different norms. It's no big deal, learn them, or avoid them. Projects all have different coding styles, different conventions for writing commit messages, changelogs and so on... I live with that and I'll do my best to adjust my style/editor settings/grammar/vocabulary accordingly for each project I contribute to. I won't send patches to mailing lists of projects which prefer patches/pull-requests on their web tracker, either. If the project is important enough to me, I'll (grudgingly) use whatever tools/formats the maintainers prefer. > > How about we educate users about a proper email setup instead? If > > they're capable of learning git, they're surely capable of setting up an > > email client properly, and perhaps more projects can adopt an > > email-centric workflow. > > SubmittingPatches would be helped by that, particularly with a clear > step-by-step example of using git-send-email and all its numerous command line > switches. It's documented in the gitworkflows(7) manpage. They should probably be linked somehow. > And, finally, the last thing most people want is more email. Seriously. It > sounds like you live in your mailer, but fewer and fewer people do that. Me? > I don't want to join another mailing list. My email management is a > disaster! I live in my mailer/$EDITOR/shell and I'm happy with that. The last thing I want is more cookies, non-Free JavaScript code, logins, user tracking/profiling, memory/CPU usage. I doubt either of us will get what we want, though :< > What it comes down to is this: is it enough to contribute to git.git to know > how to work on git.git? Or do you also need to live in your mailer? Bolt on > that extra requirement and you lose a large swath of contributors. We need to use something. Right now our choice of mailer is the best choice for _existing_ contributors. > > For me, the whole social network followers/timeline thing also has a > > _huge_ creepiness factor to it. How one prioritizes and spends time > > between different different (especially unrelated) projects should be > > nobody else's business. > > > > I don't make it /easy/ for someone (e.g. Junio) to know I'm slacking > > off on my git work to hack on ProjectNoOneUses :) > > You want to know what's creepy? That you'd think people work like that. > > It doesn't work out that way. People have far better things to do than stalk > your Github commits to see how you're spending your time. You're just not > that interesting. Neither am I! > > (If I really wanted to I could just compile your activity from public list > archives and repositories, so you're really not broadcasting any less > information about yourself by staying off Github. But I wouldn't want to, > because you're just not that interesting and I have better things to do with > my time!) There's a big difference between making information easy-to-acc
Re: OT: mail-based interfaces and web-based interfaces (Re: Extract Git classes from git-svn (1/10))
On 2012.7.24 10:54 PM, Jonathan Nieder wrote: >> And again, it *does not have to be zero sum*. It doesn't have to be email VS >> GUI. You can have your cake and eat it too. > > I assume you're talking about web-based interfaces that have gateways > to email, that produce inboxes like this: > > 24 Jul 02:46 GitHub [github] msysgit/msysgit was forked by peters > 23 Jul 10:27 GitHub [msysgit/git] ce8ebc: vcs-svn: rename check_o > 23 Jul 10:01 GitHub [github] Comment created on issue 44 (new git > 23 Jul 09:50 GitHub [github] Comment created on issue 44 (new git > 23 Jul 09:33 GitHub [github] Comment created on issue 44 (new git > 23 Jul 09:39 GitHub [github] Comment created on issue 24 (Long fi > 23 Jul 09:31 GitHub [github] Comment created on issue 44 (new git > 23 Jul 09:30 GitHub [github] Comment created on issue 24 (Long fi > 22 Jul 23:57 GitHub [github] Comment created on issue 44 (new git > > I call that pretending to have my cake, rather than having it. :) That's kind of like pointing at RCS and saying "version control sucks and its pointless to try and make it better!" Mail gateways built by web sites suck because they live in the web browser and email is an after thought. Sound familiar? Here is a much better example of the RT mail gateway that Perl 5 development uses. They're a dev community still centered around email, so it has to integrate well. http://www.nntp.perl.org/group/perl.perl5.porters/2012/07/msg189716.html And the corresponding ticket in the tracker. https://rt.perl.org/rt3/Public/Bug/Display.html?id=113684 The initial report comes in either via the web tracker or via a command line program (perlbug) that sends an email to the list. Replies on either the tracker or the mailing list are mirrored. Duplicates are detected etc... That's the sort of mail gateways I'm used to. > Maybe some day someone will prove me wrong and make a nice web-based > tool that I don't even need to know about that mines project mailing > lists. If I have to tweak my subject lines a little to help it out, > that's fine with me. I think patchwork is supposed to work this way. > > But unless we're talking about splitting the mailing list into a bunch > of mini mailing lists (like some bug trackers do), it doesn't change > anything fundamental, so I'm not sure why we're discussing this. I don't follow the bit about splitting the mailing list. -- emacs -- THAT'S NO EDITOR... IT'S AN OPERATING SYSTEM! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
