Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting

[Stephen Michel]

On February 2, 2016 12:48:18 PM EST, Aaron Wolf  wrote:
>On 02/02/2016 09:37 AM, Bryan Richter wrote:
>> On Tue, Feb 02, 2016 at 09:13:51AM -0800, Aaron Wolf wrote:
>>>
>>> So, again, moving to Gitit would be ideal
>> 
>> FWIW I think we should try to avoid talking about implementation
>> details when deciding on design and vision questions. Tech is
>> important to design inasmuch as it sets the boundaries of
>possibility,
>> but actual tech decisions should only truly follow design decisions.
>> 
>
>Okay, the design proposal I'm asking for here is that we indeed have a
>Git-backed wiki as integrated in the site as we can.

This is only a decision to make if we decide a wiki is the best form for this 
information. 

>My concern in this case is that I think to avoid extra formalities, and
>the practical existence of the Gitit codebase, I'm pushing toward
>actually accepting the pros/cons/limitations of Gitit for now. In other
>words, I want the decision to be that we work with what's available
>realistically and go with that and adapt it.
>
>So, let's not discuss further here, the issue is to make decisions via
>the new process of user stories and sorting priorities in OpenProject.
>That said, I think sometimes there's value in saying, "let's not spend
>time designing our optimal process, let's use Gitit as an existing base
>and just make the most of it." because sometimes we need to accept a
>path that works and go forward rather than deliberate on every case.
>And
>this is one where I'm proposing a specific path because it seems
>practical enough and adaptable to the overall design vision, even if
>that's not totally finalized. Still, I know that even that path will go
>better when we understand the priorities more clearly.

I agree, let's table the discussion for the moment. I also agree it seems 
reasonable that we would end up using Gitit in some form or another. We can 
figure out the details when we have a better idea of what we want from the 
system, from the user story work in OpenProject. 
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting

[Stephen Michel]

On February 2, 2016 12:09:02 PM EST, Bryan Richter  wrote:
>On Tue, Feb 02, 2016 at 02:36:19PM +, Michel, Stephen J. wrote:
>> >- The top priority user story is someone coming to the site and
>>   understanding what it is.
>> >- Introductory material is still up for discussion -- making sure
>the
>>   introduction is as effective as possible is (now and always) a very
>>   high priority.
>> 
>> I'm currently working on *organizing* the material that's currently
>> on the wiki. My work is currently local but if anyone's interested
>> in helping out I can make it available online. I have some thoughts
>> on how we should organize the material, but I'll wait on hashing
>> them out; there are a couple unresolved questions on my mind.
>
>This sounds great. Maybe to give yourself space to keep working, but
>to not feel like you're keeping people "in the dark", want to plan to
>give a report in X days? A week maybe?


I should be at a reasonable pause point today or tomorrow; I'll send out an 
email then.

>> 
>> Given some sources that suggest a wiki may actually discourage
>> participation (because people feel they're not knowledgeable enough
>> and are afraid to overwrite old content), I'm a fan of providing two
>> ways to edit an informational page:
>> 
>> 1. Pull request to git.gnu.io, or wherever we end up permanently
>>hosting our site code
>> 2. A "suggest edits" button on each page which functions like a
>>wiki-style edit button, but instead creates a pull request from
>>their edits. That way even those unfamiliar with git can
>>contribute and become involved.
>
>I'll leave it to the design team for final decisions, but this sounds
>pretty cool to me. I might suggest against creating literal pull
>requests, though. That would require tossing all the html at the user.
>In the short term, it might be better to let them have a textentry to
>describe suggestions in free-form.

If the backend is markdown, I think that would be ok to show the user.

The interface I would propose would be near-identical to how wikis work right 
now, except change the 'save' button to 'submit change request', etc. It allows 
people who don't yet understand git to submit change requests.

If needed, we could add a written note informing a user that if they don't know 
how to make the changes themselves they can simply write their suggestion in 
the comment field.___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Design] Introductary Materials and the WIki WAS: Some notes from today's meeting

[Michel, Stephen J.]

>- The top priority user story is someone coming to the site and
  understanding what it is.
>- Introductory material is still up for discussion -- making sure the
  introduction is as effective as possible is (now and always) a very
  high priority.

I'm currently working on *organizing* the material that's currently on the 
wiki. My work is currently local but if anyone's interested in helping out I 
can make it available online. I have some thoughts on how we should organize 
the material, but I'll wait on hashing them out; there are a couple unresolved 
questions on my mind.

>- mray's design opinion: we should not use wiki pages to display
>  public info pages (for the general visitor community).
>- yet, the wiki is primarily intended for stuff that's available to
>  the general visitor community -- not as engaged as people who have
>  created accounts, etc.
>- Should there be a wiki on the site?
>- What form should that wiki take?

From this as well as my own work, I'm currently leaning towards NO -- at least 
not in the form of a traditional wiki. Internal docs can move to OpenProject or 
Seafile or whatever organizational tools each team is using (or stay on a wiki 
if that's what the team decides to use). Introductory materials can be moved to 
normal html web pages. However, I think that to maximize involvement we should 
have a way for people to submit changes for those web pages; my own first 
contribution to snowdrift was improving some wording on a wiki page.

Given some sources that suggest a wiki may actually discourage participation 
(because people feel they're not knowledgeable enough and are afraid to 
overwrite old content), I'm a fan of providing two ways to edit an 
informational page:

1. Pull request to git.gnu.io, or wherever we end up permanently hosting our 
site code
2. A "suggest edits" button on each page which functions like a wiki-style edit 
button, but instead creates a pull request from their edits. That way even 
those unfamiliar with git can contribute and become involved.
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting

[Bryan Richter]

On Tue, Feb 02, 2016 at 02:36:19PM +, Michel, Stephen J. wrote:
> >- The top priority user story is someone coming to the site and
>   understanding what it is.
> >- Introductory material is still up for discussion -- making sure the
>   introduction is as effective as possible is (now and always) a very
>   high priority.
> 
> I'm currently working on *organizing* the material that's currently
> on the wiki. My work is currently local but if anyone's interested
> in helping out I can make it available online. I have some thoughts
> on how we should organize the material, but I'll wait on hashing
> them out; there are a couple unresolved questions on my mind.

This sounds great. Maybe to give yourself space to keep working, but
to not feel like you're keeping people "in the dark", want to plan to
give a report in X days? A week maybe?

> 
> Given some sources that suggest a wiki may actually discourage
> participation (because people feel they're not knowledgeable enough
> and are afraid to overwrite old content), I'm a fan of providing two
> ways to edit an informational page:
> 
> 1. Pull request to git.gnu.io, or wherever we end up permanently
>hosting our site code
> 2. A "suggest edits" button on each page which functions like a
>wiki-style edit button, but instead creates a pull request from
>their edits. That way even those unfamiliar with git can
>contribute and become involved.

I'll leave it to the design team for final decisions, but this sounds
pretty cool to me. I might suggest against creating literal pull
requests, though. That would require tossing all the html at the user.
In the short term, it might be better to let them have a textentry to
describe suggestions in free-form.



signature.asc
Description: Digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting

[Bryan Richter]

On Tue, Feb 02, 2016 at 09:13:51AM -0800, Aaron Wolf wrote:
> 
> So, again, moving to Gitit would be ideal

FWIW I think we should try to avoid talking about implementation
details when deciding on design and vision questions. Tech is
important to design inasmuch as it sets the boundaries of possibility,
but actual tech decisions should only truly follow design decisions.



signature.asc
Description: Digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting

[Aaron Wolf]

On 02/02/2016 09:37 AM, Bryan Richter wrote:
> On Tue, Feb 02, 2016 at 09:13:51AM -0800, Aaron Wolf wrote:
>>
>> So, again, moving to Gitit would be ideal
> 
> FWIW I think we should try to avoid talking about implementation
> details when deciding on design and vision questions. Tech is
> important to design inasmuch as it sets the boundaries of possibility,
> but actual tech decisions should only truly follow design decisions.
> 

Okay, the design proposal I'm asking for here is that we indeed have a
Git-backed wiki as integrated in the site as we can.

My concern in this case is that I think to avoid extra formalities, and
the practical existence of the Gitit codebase, I'm pushing toward
actually accepting the pros/cons/limitations of Gitit for now. In other
words, I want the decision to be that we work with what's available
realistically and go with that and adapt it.

So, let's not discuss further here, the issue is to make decisions via
the new process of user stories and sorting priorities in OpenProject.
That said, I think sometimes there's value in saying, "let's not spend
time designing our optimal process, let's use Gitit as an existing base
and just make the most of it." because sometimes we need to accept a
path that works and go forward rather than deliberate on every case. And
this is one where I'm proposing a specific path because it seems
practical enough and adaptable to the overall design vision, even if
that's not totally finalized. Still, I know that even that path will go
better when we understand the priorities more clearly.

___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design